Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating Spans for SignalR messages sent over Web Sockets #84

Open
js8080 opened this issue Dec 17, 2020 · 5 comments
Open

Creating Spans for SignalR messages sent over Web Sockets #84

js8080 opened this issue Dec 17, 2020 · 5 comments
Labels
question Further information is requested

Comments

@js8080
Copy link

js8080 commented Dec 17, 2020

I'm using opentracing-csharp-netcore in an ASP.NET Core (3.1) application that receives SignalR requests via WebSockets.

In my Startup.ConfigureServices() method I setup OpenTracing as follows:

            services.AddOpenTracingCoreServices(otBuilder =>
            {
                otBuilder.AddAspNetCore()
                    .ConfigureAspNetCore(options =>
                    {
                        var ignoredRequestPaths = tracingOptions.IgnoredRequestPaths;
                        options.Hosting.IgnorePatterns.Add(ctx => (ignoredRequestPaths != null) ? ignoredRequestPaths.Contains(ctx.Request.Path) : false);

                        // options.Hosting.OnError = (span, exception, context) => {} -- this is only thrown when there is an unhandled exception, not when an HTTP error is purposefully returned by a controller

                        // This sets the main-level Span Operation Name which normally has a less than useful value in my experience.
                        options.Hosting.OperationNameResolver = (httpContext) =>
                        {
                            return httpContext.Request.Path.Value;
                        };
                    })
                    .AddCoreFx()
                    .AddEntityFrameworkCore()
                    .AddLoggerProvider();
            });

Unfortunately, what I am finding is that SignalR via WebSockets requests received do not cause a Span to be created. Meanwhile, regular HTTP web requests work fine.

Is there some limitation to DiagnosticListeners that don't support SignalR over Web Sockets or does opentracing-csharp-netcore just not support listening for Web Socket events?

Sorry I am not an expert in the terminology for SignalR over Web Sockets or the inner workings of opentracing-charp-netcore but hopefully I got my question across despite that.

@cwe1ss
Copy link
Collaborator

cwe1ss commented Dec 17, 2020

Hi. I don't have any experience with SignalR so I don't know if & how it can be instrumented. Could you point me to some instrumentaion-code in the SignalR code?

@cwe1ss cwe1ss added the question Further information is requested label Dec 17, 2020
@js8080
Copy link
Author

js8080 commented Dec 17, 2020

That's an excellent question and I'm in the process of digging up info on how to instrument SignalR. I will follow-up with what I find.

@js8080
Copy link
Author

js8080 commented Dec 18, 2020

@cwe1ss - check out Add EventSource/EventCounter tracing and metrics for SignalR and WebSockets #2461 (aspnetcore github). Sounds like there is no DiagnosticSource in the ASP.NET Core SignalR code so a different approach would be needed. Unfortunately, I am not sure if there is another approach.

@cwe1ss
Copy link
Collaborator

cwe1ss commented Dec 21, 2020

Thank you for the link!

I've done some quick research as well and I've seen that they introduced "Hub filters" with ASP.NET Core 5.0. This seems to be the same concept as "action filters" for MVC and gives you a nice hook.

So, if you're on ASP.NET Core 5.0, you could write a global hub filter that creates OpenTracing spans via the regular OpenTracing API.

@js8080
Copy link
Author

js8080 commented Dec 21, 2020

@cwe1ss thanks! I will look into that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants