-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
fix(otel): spans hierarchy + sampled flags and propagation #10663
Conversation
0f736cd
to
c9e1ce3
Compare
c9e1ce3
to
516a6c1
Compare
addresses span hierarchy for otel, similarly to what Kong/kong-ee#4904 did for dd
address propagation of non-sampled spans, similarly to what Kong/kong-ee#5054 did for dd
516a6c1
to
3719b95
Compare
fe98a81
to
40faabc
Compare
40faabc
to
25e893b
Compare
@@ -500,6 +517,7 @@ local function set(conf_header_type, found_header_type, proxy_span, conf_default | |||
end | |||
|
|||
if conf_header_type == "ot" or found_header_type == "ot" then | |||
to_ot_trace_id = to_ot_trace_id or require "kong.plugins.opentelemetry.otlp".to_ot_trace_id |
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.
moved here otherwise requiring "propagation" from "instrumentation" was resulting in otlp
to be initialized too soon
25e893b
to
a09f69e
Compare
@@ -82,6 +83,15 @@ function _M.balancer(ctx) | |||
local try_count = balancer_data.try_count | |||
local upstream_connect_time = split(var.upstream_connect_time, ", ", "jo") | |||
|
|||
local last_try_balancer_span |
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.
Nice to have those decoupled from the OTEL plugin. Eventually, we will also decouple the creation of root span and "last_try_balancer_span` too.
@samugi This will need to be cherry-picked into EE |
Zipkin manages its spans and calls `finish` on them, and the result is that `finish` is called twice if instrumentations are enabled. Then an assertion error is generated, resulting in the span not being sent correctly. This was an issue introduced with #10663 So my approach is not to store the propagation span if the reuse parameter is not specified, in order to avoid the traces not being generated correctly under that.
* fix(zipkin): do not reuse `propagated_span` by default Zipkin manages its spans and calls `finish` on them, and the result is that `finish` is called twice if instrumentations are enabled. Then an assertion error is generated, resulting in the span not being sent correctly. This was an issue introduced with #10663 So my approach is not to store the propagation span if the reuse parameter is not specified, in order to avoid the traces not being generated correctly under that.
Summary
Continuation of #10583 and #10655 (otel plugin side).
Addresses the following issues:
Checklist
Full changelog
Issue reference
KAG-1108