You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ability to cancel tracing for a specific request from within the handler #893
Is your feature request related to a problem? Please describe.
There is no obvious way to disable tracing (zipkin etc.) for a single request within a finagle-http-server.
My usecase is that I would like to exclude healthcheck requests (that unfortunately cannot be moved to e.g. a separate admin-server for $reasons) from sending any tracing information to zipkin.
Describe the solution you'd like
It would be great if I could call a method like c.t.f.tracing.Trace.cancelSampling() from within my http Service[Request, Response] to conditionally disable/cancel all tracing for a specific request.
Describe alternatives you've considered
Alternatively it could also be useful if I could pass a Request => Boolean function to the http-server that would decide if a request should be traced at all.
The TraceInitializerFilter is responsible for initializing the trace id for the request to be handled. This is placed low in the stack before any other modules that might emit traces.
Ideally this feature would be handled in an opinionated library like Finatra where there's robust per-route configuration. However, you can still do what you want by creating a module placed right above the trace initializer module in the http server stack. The module would apply a filter that unsets the sampling decision under some condition, like the request path. This isn't the best solution but would get you this behavior until thinking through how this would be integrated more naturally into finagle/finatra.
That's good enough for me for now. I think it would still be nice if it was simpler than this but I see that it's not very easy to integrate that into the existing architecture.
Activity
cacoco commentedon Mar 3, 2021
Possibly related to twitter/finatra#271.
hamdiallam commentedon Mar 3, 2021
The TraceInitializerFilter is responsible for initializing the trace id for the request to be handled. This is placed low in the stack before any other modules that might emit traces.
Ideally this feature would be handled in an opinionated library like Finatra where there's robust per-route configuration. However, you can still do what you want by creating a module placed right above the trace initializer module in the http server stack. The module would apply a filter that unsets the sampling decision under some condition, like the request path. This isn't the best solution but would get you this behavior until thinking through how this would be integrated more naturally into finagle/finatra.
dziemba commentedon Mar 4, 2021
Thanks for the pointers!
I believe I got it working now like this:
That's good enough for me for now. I think it would still be nice if it was simpler than this but I see that it's not very easy to integrate that into the existing architecture.
hamdiallam commentedon Mar 4, 2021
That implementation looks correct. Glad it's working. I'll keep this issue open to find some time to design better integration