-
Notifications
You must be signed in to change notification settings - Fork 32
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 context methods for current trace and span #46
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, just adding my thoughts since these APIs are relevant to my interests. 😄 (Cf. all the talking to myself in #45.)
Just want to add that since upgrading from 0.8, I couldn't find any "official" way of creating a tracing header for propagation, and ended up with this code which is using trace_header = Honeycomb.client.send(:context).current_span.try(&:to_trace_header) So any PR that lets me avoid that would be most welcome 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. Would love to have a little bit more discussion on exposing the non current_span
and current_trace
accessors. We could split that into another PR so we can discuss those features and get current_span
and current_trace
released?
@grncdr the way I was expecting people to use the trace header stuff was that you would have a span wrapping the http request so you would end up with something like the faraday integration https://github.com/honeycombio/beeline-ruby/blob/master/lib/honeycomb/integrations/faraday.rb#L25. |
Big 👍 on that. |
This reverts commit 0a70d1e.
This PR is super simple now. Just exposing the |
Expose the current trace and current span in the top level scope. These properties are useful for doing custom instrumentation.