What it will mean for a vendor to "support OpenTelemetry"

[tsloughter]

OpenTelemetry is much more extendable by vendors than OpenCensus was and this leads me to concern about future vendor support possibly not working with the standard SDK implementation of the OTel API.

Right now the specification defines what is required for an implementation library. My suggestion is to define what it means to "support OpenTelemetry" as a service for receiving/visualizing/analyzing/etc OTel traces and metrics. I think the simplest definition would be for the backend to support the spans and metrics collected by the OTel SDK, not requiring any vendor specific implementation.

This doesn't restrict additional features provided by services or require that they be supported by all OTel libraries, only that without the vendor SDK a user can still use the basic features of any service that "supports OpenTelemetry".

[discostu105]

I can see multiple levels of "supports OpenTelemetry" for vendors:

1. Directly implement Tracer API
   Gives maximum flexibility to tracer-implementer. However, most upfront cost. Needs app code change (or automatic injection).

2. Use default implementation (SDK) and provide an exporter.
   Less flexibility, can still define your own protocol and enrich data if necessary. Still requires app code change (or automatic injection).

3. Use default exporter and receive standard OpenTelemetry data format.
   Least flexibility, but no code changes required.

Of course, there is another dimension of "traces", "metrics", "logs" and which of these are supported. I believe it should be valid for tracer (or backend) to only support only one of those (or all).

[tsloughter]

Yea, I disagree that only supporting (1) should be an option for being considered to "support OpenTelemetry". I think it leads to a situation like OpenTracing. I still don't know what it means when something "supports opentracing"... except to mean that it roughly follows the terminology and "api" of opentracing.

While OpenTelemetry provides a more explicit API, if the service requires specific language implementations of the API to work at all it means a language that has an OpenTelemetry SDK won't work with a "supports OpenTelemetry" service.

It is difficult to impossible to introduce a new language in a company if a vendor is in use that does not provide support for that language. Requiring minimal support for the OTel SDK would greatly reduce this obstacle.

[mtwo]

Perhaps we could describe the first option as "implements OpenTelemetry" versus "supports OpenTelemetry"?

[tsloughter]

Yea, those sound reasonable.

[lizthegrey]

As with OpenCensus, some services may only support metrics, only support tracing, or support both... so we also need to consider that.

[tsloughter]

Yea, it should be that a vendor can list as implementing the OTel API or supporting OTel for any subset. Or even only implement Otel API for tracing but supports OTel for metrics.

[tedsuo]

@tsloughter just following up on this. Do you feel like you could add language to the spec describing the minimal support requirements?

[tsloughter]

@tedsuo I think so. There seems to be some general agreement on what needs to be said.

[pauldraper]

I still don't know what it means when something "supports opentracing"

It means that it can observe libraries instrumented against the OpenTracing API (without changing any of the libraries' code). This statement of course is only made in the context of a particular language.

OpenTracing was a language API spec.

OpenTelemetry....I can't decide if it is an language API spec or a data format spec.

[tsloughter]

@pauldraper that isn't the case. There are multiple "opentracing" libraries for each language and they are not compatible with each other and their internal context propagation.

That is on top of the fact it doesn't define enough to be compatible between language implementations (external context propagation) either.

[pauldraper]

There are multiple "opentracing" libraries for each language

I think we're off-track but there is only one interface per language at https://github.com/opentracing.

And yes, internal context propagation was always a weak spot of OT, as a result of intense Go-influence and Go's insistence on no thread-locals. But that's more a choice of (lack of) API scope, not the choice of language vs protocol standardized (which again, I have trouble telling which one OTel is doing).

[tsloughter]

OpenTelemetry is an API spec, an implementation of both the API and SDK and a protocol for reporting (OTLP), along with the W3C trace context and correlation context standards it covers the end to end specification for a distributed tracing system.

What I plan to put in the spec for minimal requirements (forgot to do this... now trying to decide where to put it, maybe in a new page entirely solely for discussing vendors) is that their vendor works with the default SDK.

What I am hoping can be avoided with OpenTelemetry is the issue of every vendor having their own implementation, resulting in those of us using unsupported languages to have to develop integration ourselves. Why I like OpenTelemetry (and OpenCensus before it) is that part of the project and spec ensures that this is possible -- the common propagation format and protocol/data format for spans.

Preferably vendors would be able to get by with plugging into where Otel is extendable, like span processors, and not have to write their own SDK, but my intention is to cover the case that vendors do have to resort to writing their own SDKs and keeping it from becoming the same ecosystem as existed with OpenTracing where you had to re-implement their SDK to use their service.

[pauldraper]

Yeah, I can't think of a good reason why a vendor would want to write a custom TraceProvider instead of writing a SpanProcessor.

In OpenTracing there was less definition around certain things like span and trace IDs. But OTel mandates that providers support 128-bit trace IDs and 32-bit span IDs....the amount of allowed choice is so low, I can't think of a reason to write anything but a SpanProcessor.

[tsloughter]

Ok, finally got this written up this morning #594

I'll close this so that discussion continues on the pull request.

[Oberon00]

Why was this issue closed? #594 is still not merged. And why was the milestone of this closed-but-not-completed issue changed?

[tsloughter]

@Oberon00 I simply wanted to move the discussion to the PR. It can be reopened if it is preferred to keep it to track instead of just the PR for that.

[Oberon00]

I think the usual workflow is to keep the issue open until it is resolved, which usually means that the implementing PR is merged.

[tsloughter]

Ok, I'll reopen. That is the usual process, just wanted to do something to hopefully keep from conversation continuing here instead of the PR.