-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Change internal tracing to use otel trace #3567
Conversation
sr := new(oteltest.SpanRecorder) | ||
tp := oteltest.NewTracerProvider(oteltest.WithSpanRecorder(sr)) | ||
otel.SetTracerProvider(tp) | ||
defer otel.SetTracerProvider(trace.NewNoopTracerProvider()) |
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 is now the 5th time the same lines are repeated in tests. Wouldn't it make sense to externalize it?
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.
Great to see this coming.
I am curious how performance of Otel tracing compares to OC tracing? Do we have any benchmarks that measure the impact of tracing on component operations?
// Enable OpenTelemetry observability plugin. | ||
opts = append(opts, grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor())) | ||
opts = append(opts, grpc.WithStreamInterceptor(otelgrpc.StreamClientInterceptor())) | ||
|
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 enables context propagation, right? So, we will propagate context for grpc-based protocols, like OTLP. Is this something we want?
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 is similar with what we had before with opencensus using the stats handler.
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 don't think any propagators are configured in this PR, so no propagation should happen by default. If a custom build (or later PR for this repo/contrib) were to configure a global propagator then it would be used by these interceptors.
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.
Is it not the case that w3c is the default?
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.
No, unfortunately it isn't.
The OpenTelemetry API MUST use no-op propagators unless explicitly configured otherwise.
Based on our loadtests no significant difference, the otel seems actually to be slightly faster. @MrAlias @Aneurysm9 do you have these benchmarks? |
We have some basic tracer benchmarks, starting and stopping spans, ID handling, etc. This should get all the benchmarks in the core repo. |
// Enable OpenTelemetry observability plugin. | ||
opts = append(opts, grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor())) | ||
opts = append(opts, grpc.WithStreamInterceptor(otelgrpc.StreamClientInterceptor())) | ||
|
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 don't think any propagators are configured in this PR, so no propagation should happen by default. If a custom build (or later PR for this repo/contrib) were to configure a global propagator then it would be used by these interceptors.
_, span = rec.tracer.Start(context.Background(), spanName, trace.WithLinks(trace.Link{ | ||
SpanContext: trace.SpanContextFromContext(receiverCtx), | ||
})) |
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.
_, span = rec.tracer.Start(context.Background(), spanName, trace.WithLinks(trace.Link{ | |
SpanContext: trace.SpanContextFromContext(receiverCtx), | |
})) | |
ctx, span = rec.tracer.Start(ctx, spanName, trace.WithLinks(trace.Link{ | |
SpanContext: trace.SpanContextFromContext(receiverCtx), | |
}), trace.WithNewRoot()) |
I believe this does what you're trying to do without needing the later call to ContextWithSpan()
.
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.
Not working per open-telemetry/opentelemetry-go#2071
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.
Please file a PR when that issue is fixed.
For the moment we rely on the global TracerProvider, in a future PR will change that. Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
For the moment we rely on the global TracerProvider, in a future PR will change that.
Signed-off-by: Bogdan Drutu bogdandrutu@gmail.com