python-microservices
Support OpenTelemetry for Traces
Is your feature request related to a problem? Please describe. Would be great if there was option to use OpenTelemetry instead of OpenTracing. It seems that it can quickly become the main tracing protocol considering that it's an official merger of OpenTracing and OpenCensus, a sandbox project of CNCF. Both Microsoft and Google are maintaining the opentelemetry-python repo, Lightstep is one of the founding contributors, Sentry has decided to completely drop experimental OpenTracing support and contributed an official exporter to OpenTelemetry instead and so on.
Describe the solution you'd like There is an official Flask integration in OpenTelemetry Python SDK repo.
Describe alternatives you've considered It's possible to stay with just OpenTracing but sooner or later it will be a limiting factor - migration is suggested by OpenTracing maintainers and big projects probably won't add new OpenTracing support anymore (see Sentry example) so it's a dead end.
We can use this issue to track the metrics and the traces or change the scope of this one to traces and create one for metrics.
In the middle-time, there's some work done for metrics, as seen above.
I've created this issue with specifically traces in mind so would rather see separate one for metrics (somehow didn't realize that OpenTelemetry supports metrics).
We might need to join the traces and the metrics services (and the logging in the future). The auto-instrumentation for the metrics seem to be on very early stages, but there's already some work done for the requests module. Still unreleased, but I've test it and it works nicely. What this could mean is that, since the OT api will give one method to activate both metrics and traces, it might make sense to have it all in the same service. It will still be need to be handled differently by the configuration, but on the same service.
As said on the MR I would treat, for now, any integration with OT as a beta feature. So as @Agalin suggests, we could have both services at the same time. So, we could create the telemetry service while maintaining both the metrics (with prometheus_client metrics) and traces service (with opentracing traces). What do you thing @avara1986 ?
Great discussion @alexppg @Agalin , I didn't know OpenTelemetry. As you say, if OpenTelemetry is "the future", it will be better add a service to support that, but, as @alexppg say, if OpenTelemetry is still in beta, could be better support both options for a while
Seems like a good idea especially that it would merge a lot of services into one.
Nice, we'll then leave this issue for traces and I'll work on the one for metrics on the other issue.