Skip to content
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

trace: Migrate to open-telemetry for instrumentation. #252

Open
kavirajk opened this issue Aug 15, 2022 · 4 comments
Open

trace: Migrate to open-telemetry for instrumentation. #252

kavirajk opened this issue Aug 15, 2022 · 4 comments

Comments

@kavirajk
Copy link
Contributor

kavirajk commented Aug 15, 2022

Currently Loki is instrumented with opentracing/jaeger client libraries for tracing (I hope, it's same for Mimir and Tempo as well)

This instrumentation comes from weaveworks/common package and dskit's spanlogger package.

Those client libraries(opentracing, jaeger) are deprecated in the favor of opentelemetry client sdk. It's better to migrate.

I hope, It should be completely possible to migrate underlying dependencies without changing any API of those packages.

Example of using otel tracing client libraries for instrumentation in Go is here.

@bboreham
Copy link
Collaborator

It should be completely possible to migrate underlying dependencies without changing any API

Yeah but not without making tracing stop working for everyone until they figure out how to initialize Otel to make it write to their tracing backend.

Can we put in a layer of indirection?

@bboreham
Copy link
Collaborator

This came up in conversation today. Given OpenTelemetry has matured and adoption has increased I'm more OK with a breaking change.

@davidspek
Copy link

@kavirajk Is this something Grafana is going to pick up? It's currently not possible to get spans to propagate to Loki/Mimir/Tempo if OpenTelemetry is used in the stack since it isn't possible to set the JAEGER_PROPAGATION environment variable in the Jaeger Go client.

@ying-jeanne
Copy link

@davidspek Hi, thank you for bring up the topic, and yes we are planning to do the migration on our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants