Conversation
|
Still draft because I need to fix tests, add tests, and double check the server configuration of middlewares. |
Ref: grafana/dskit#681 Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Yes, I wasn't sure about taking on the reference otel/trace, but it seems ok. The ones I am familiar with, Mimir/Loki/Tempo/Pyroscope all already have it. Are there any other downstream repos we should check, or do you think the impact of taking on this reference is minimal? |
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
This updates dskit to grafana/dskit#681 which supports OTel tracing, but doesn't make any change, so it should still use OpenTracing Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
|
I assume it's inevitable with my task to add the |
| middleware.ClientUserHeaderInterceptor, | ||
| ), | ||
| grpc.WithChainUnaryInterceptor(unaryInterceptors...), | ||
| grpc.WithStatsHandler(otelgrpc.NewClientHandler()), |
There was a problem hiding this comment.
this is not protected with if opentracing.IsGlobalTracerRegistered() , should it be?
There was a problem hiding this comment.
I wasn't going to... but ok, fair enough, let's add a check: c59312f
| } | ||
|
|
||
| func (t Tracer) wrapWithOpenTracing(next http.Handler) http.Handler { | ||
| // Do OpenTracing when it's registered. |
There was a problem hiding this comment.
nit: comment doesn't make much sense here as the if is elsewhere
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
This changes behaviour of tracing.StartSpanFromContext to always start a span, as we did previously, and we decide based on whether opentracing is registered or not. Also added tests, which I had to move to other packages as tracing installation is a global state. Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
|
I'm testing this PR on a local dev environment, to make sure that we didn't break any existing OpenTracing features before merging. |
|
I checked the traces and they still exist. |
| labeler.Add(attribute.String("http.content_type", ct)) | ||
| } | ||
|
|
||
| labeler.Add(attribute.String("headers", fmt.Sprintf("%v", r.Header))) |
There was a problem hiding this comment.
Should we worry about sensitive headers here, e.g. authorization tokens?
See here for instance.
When I added the OTel tracing in #681 I went too far and added headers as tracing attributes. As @bboreham pointed out, this could log potentially sensitive headers like auth tokens. This is a quick fix to remove that from traces, we can add an allowlist or a blocklist in the future as a feature. Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
When I added the OTel tracing in #681 I went too far and added headers as tracing attributes. As @bboreham pointed out, this could log potentially sensitive headers like auth tokens. This is a quick fix to remove that from traces, we can add an allowlist or a blocklist in the future as a feature. Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
| return | ||
| } | ||
|
|
||
| return sctx.TraceID().String(), sctx.IsSampled() |
There was a problem hiding this comment.
The previous behavior of ExtractSampledTraceID would return the traceID regardless if it was sampled or not, the new behavior only returns the traceID if it was sampled.
Unfortunately this is a breaking change for Loki where we would use this method to append the log line with additional information if the trace was sampled or not, but we relied on it returning the traceID to use in the log line regardless of being sampled.
) **What this PR does**: This PR fixes an issue where the tracing sampler would not be configured correctly if tracing is being configured from Jaeger environment variables and the `JAEGER_SAMPLER_TYPE` environment variable was set to `probabilistic`. **Which issue(s) this PR fixes**: Related to #681 and #700. **Checklist** - [ ] Tests updated
What this PR does
This adds support for OTel everywhere. It is similar to #385 which migrated to OTel, and takes pieces of code from there, but it does not remove support for OpenTracing.
spanloggerpackage changesThe new
spanlogger.NewOTelwill create a new OTel span, using the tracer provided. We're asking for a tracer instead of using one fromspanloggerbecause that's how Tempo did it with per-package Tracer.spanlogger.FromContextwill find the existing span in the context, either OpenTracing or OTel one, and will return aSpanLoggerthat abstracts both.In order to achieve that
spanlogger.SpanLoggernow contains either anopentelemetry.Spanor antrace.Span(OTel). If there's an OTel one, it will do the operations with it, if not it will fall back to OpenTracing implementation. Some calls that were cheaper before, likeLogFieldsnow are more expensive since we have to translate them to OTel attributes.httpgrpc/serverpackage changesWhen serving an HTTP request, we'll use OpenTracing to start the span if
opentracing.IsGlobalTracerRegistered(). If there's an OTel span in the request context, we'll inject that one to the request.instrument.CollectedRequest()changesThis function is widely used, so I migrated it from using
opentracing.StartSpanFromContexttotracing.StartSpanFromContext: a new wrapper in thetracingpackage that will use the configured tracing library.tracingpackage changesThe new
tracing.StartSpanFromContextcreates an adaptertracing.Spanthat acts like anopentracing.Spanortrace.Spandepending on the library used in the parent span from thecontext.Contextprovided toStartSpanFromContext.This abstraction should disappear once we've migrated our dependencies to OTel. 🤞 (Famous last words)
The
ExtractSampledTraceID,ExtractTraceIDandExtractTraceSpanIDnow support both opentracing and OTel libraries. This should solve #662 as well.Finally, I brought from #385 the
NewOTelFromJaegerEnvfunction that will configure OTel tracing using Jaeger env vars, with Jaeger exporter.serverpackage changesServer now has the
otelgrpc.NewServerHandler()which will inject the OTel Spans to the context.middlewarepackage changesWhen propagating an HTTP or HTTPGRPC requests, we'll use OpenTracing to start the span if
opentracing.IsGlobalTracerRegistered(). If there's an OTel span in the request context, we'll inject that one to the request.Which issue(s) this PR fixes
Ref: grafana/mimir#2708
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]