This is aimed as an intern project for the LFX Mentorship. Please refer to #4453. Apply here.
Historically, the Jaeger backend used the OpenTracing API, with Jaeger's own Go SDK jaeger-client-go, for instrumenting its own internals for distributed tracing. Since Jaeger's SDKs have been deprecated (#3362), we want to upgrade the Jaeger backend to use the OpenTelemetry tracing API and SDK directly.
Expected Outcome:
- Replace the use of OpenTracing API with OpenTelemetry
- Remove
jaeger-client-go and jaeger-lib as dependencies
- Remove
opentracing-go and opentracing-contrib/* as dependencies
- Switch to standard OpenTelemetry instrumentation libraries where available (e.g. for HTTP, gRPC)
- Rethink/rework
crossdock integration tests to test end-to-end flow with OpenTelemetry data
- Publish a blog post on medium.com/jaegertracing documenting the experience
Proposed approach
I don't think using OTEL-OT Bridge makes sense for this project, since it will create an extra work for adding the bridge, but will not make the actual migration any easier. Instead, I would do this in stages:
- Right now various components of the backend take
opentracing.Tracer as argument. As a first step, we create a wrapper object that will contain that same tracer, and pass the wrapper object to components. This will be one-time large refactoring but without any functional changes.
- Once the first step is done, we can add OTEL Tracer to the same wrapper object.
- Then start changing components one by one by switching them to use OTEL instrumentation.
- When all of them have been migrated, we can remove the OpenTracing part.
Some related issues:
This is aimed as an intern project for the LFX Mentorship. Please refer to #4453. Apply here.
Historically, the Jaeger backend used the OpenTracing API, with Jaeger's own Go SDK
jaeger-client-go, for instrumenting its own internals for distributed tracing. Since Jaeger's SDKs have been deprecated (#3362), we want to upgrade the Jaeger backend to use the OpenTelemetry tracing API and SDK directly.Expected Outcome:
jaeger-client-goandjaeger-libas dependenciesopentracing-goandopentracing-contrib/*as dependenciescrossdockintegration tests to test end-to-end flow with OpenTelemetry dataProposed approach
I don't think using OTEL-OT Bridge makes sense for this project, since it will create an extra work for adding the bridge, but will not make the actual migration any easier. Instead, I would do this in stages:
opentracing.Traceras argument. As a first step, we create a wrapper object that will contain that same tracer, and pass the wrapper object to components. This will be one-time large refactoring but without any functional changes.Some related issues: