-
Notifications
You must be signed in to change notification settings - Fork 79
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
Expose child Spans from OpenTracing API to support tracing legacy code? #81
Comments
Mkay, so this can be done.
👍 |
The contents of the map are only meaningful to Natchez, so I would not count on being able to inspect it and pull out usable data. If you have access to your In general this seems bad because as you say it breaks the abstraction, and if you change your tracing back end it will break code that assumes a particular implementation. |
Having a way to surface the current span could be useful in one of maybe a few different ways. |
I have a use-case where we're using http4s to drive legacy code written in Java (which we're not ready to rewrite in the typelevel style).
I would like to be able to share a trace initiated from http4s via natchez (and code written in #5) to pass down a child OpenTracing
Span
to serve as the root span of my legacy Java calls.I realize this breaks the nice abstraction / hiding provided by
natchez
, but there can be reasons for consenting adults to do so from time-to-time.Are we open to adding extension methods to the entrypoint hooks (like in
JaegerTracer
) to construct and return a child span from the OpenTracing API, or would that ruin everything?The text was updated successfully, but these errors were encountered: