-
Notifications
You must be signed in to change notification settings - Fork 423
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
Enhance existing http example to support w3c trace context propagation #727
Conversation
Codecov Report
@@ Coverage Diff @@
## main #727 +/- ##
=======================================
Coverage 94.75% 94.75%
=======================================
Files 217 217
Lines 9923 9923
=======================================
Hits 9403 9403
Misses 520 520
|
…into http-propagate
auto prop = opentelemetry::context::propagation::GlobalTextMapPropagator::GetGlobalPropagator(); | ||
auto current_ctx = opentelemetry::context::RuntimeContext::GetCurrent(); | ||
auto new_context = prop->Extract(carrier, current_ctx); | ||
options.parent = GetSpanFromContext(new_context)->GetContext(); |
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.
I think this shouldn't be strictly necessary, as Extract
sets the span as the currently active span in the context?
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.
@pyohannes - Extract
would return a new context with the span
created with extracted span_context
, and won't make it active. This is as per the specs :
Returns a new Context derived from the Context passed as argument.
#include <cstring> | ||
#include <iostream> | ||
#include <vector> | ||
#include "opentelemetry/ext/http/client/http_client.h" |
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.
I wonder if we can eventually generalize some of this, since the same / similar logic would be necessary for gRPC metadata. I like how it was handled in dapr examples:
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.
Yes, we should eventually reuse part of the code for both HTTP and grpc.
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.
I'm good with this for now. We may need to refactor this to generalize the common parts to be agnostic of whether it's HTTP client headers or gRPC metadata.
Changes
Please provide a brief description of the changes here.
This PR enhances the existing HTTP client/serve example with http propagation. The
trace_id
andparent_span_id
are propagated from client to server.Also nit change on renaming the header file extension as per the convention (
hpp
->h
)CHANGELOG.md
updated for non-trivial changes