Skip to content

Support OpenTelemetry for Traces #181

Description

@Agalin

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.

Activity

alexppg commented on Oct 11, 2020

@alexppg
Member

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.

Agalin commented on Oct 11, 2020

@Agalin
ContributorAuthor

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).

alexppg commented on Oct 11, 2020

@alexppg
Member

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.

alexppg commented on Oct 11, 2020

@alexppg
Member

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 ?

avara1986 commented on Oct 12, 2020

@avara1986
Member

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

Agalin commented on Oct 12, 2020

@Agalin
ContributorAuthor

Seems like a good idea especially that it would merge a lot of services into one.

changed the title [-]Support OpenTelemetry[/-] [+]Support OpenTelemetry for traces[/+] on Oct 14, 2020
changed the title [-]Support OpenTelemetry for traces[/-] [+]Support OpenTelemetry for Traces[/+] on Oct 14, 2020

alexppg commented on Oct 14, 2020

@alexppg
Member

Nice, we'll then leave this issue for traces and I'll work on the one for metrics on the other issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions