Clarify placement of exporter implementation

[tigrannajaryan]

There was unnecessarily suggestive wording that implied that vendor
exporters should be part of language libraries.

Added a clarification regarding vendor-specific exporters,
OpenTelemetry protocol exporter and standard output exporter.

[jkwatson]

To my reading, this still implies that support would be added to the open telemetry projects, not hosted by the vendors themselves. I think it should be made very clear that open telemetry will not be hosting vendor-specific exporters, but that vendors will need to provide those themselves, hosted outside of the OT project.

[Oberon00]

So do Jaeger and Prometheus not count as vendors?

Also, Python currently has a MS Azure exporter.

EDIT: Maybe we should distinguish between repositories and packages here, e.g. while the Azure exporter in Python is in the same repository as the core OTel library, it has to be installed explicitly & separately.

[reyang]

Probably off topic a little bit, besides exporters there are also propagators - currently have Zipkin specific correlation (a.k.a. B3 headers) in OT Python - and it is part of the core SDK (the same repo, and the same package) https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-sdk/src/opentelemetry/sdk/context/propagation/b3_format.py.

[bogdandrutu]

@tigrannajaryan please make it very clear that we do not allow any vendor specific code in the repos.

[carlosalberto]

IIRC we were supposed to host Jaeger/Zipkin/Prometheus exporters, both as reference and also because of their open source nature (as compared to, say, the Azure one, which will have to be moved out eventually).

That means we should prepare for putting the aforementioned exporters in their own repo?

[tigrannajaryan]

I added further clarification as discussed in spec SIG meeting today. See requirement 5.

[c24t]

Vendor-specific exporters (exporters that implement vendor protocols) should not be included in language libraries and should be placed elsewhere (the exact approach for storing and maintaining vendor-specific exporters will be defined in the future).

Right now we keep some vendor-specific exporters in the OT python repo, but publish separate distribution packages for each. So e.g. to export traces to azure monitor, a user would have to install opentelemetry-ext-azure-monitor.

It's not clear from the text, but from the SIG call this morning it sounds like these exporters should also be in separate repos from the main project?

[tigrannajaryan]

IMO, vendor-specific exporters do not belong neither in the Otel repo, nor in the distrubution.

The reason for not including in the repo is to avoid additional maintanance burden for core maintainers.

The reason for not including in the distribution is to avoid bloating packaging and runtime dependency applications must use.

Now, if a particular language SIG decides they want to have batteries-included SDK I do not see a big harm if they provide 2 packages: a bare "sdk" which does not include vendor-specific exporters and an "sdk-full" which includes them. Just make sure to have enough transparency and avoid vendor-influenced decision when doing so.

[c24t]

That sounds reasonable to me, but this is likely to mean more maintenance work for us, not less. Even still, it might be worth making this change to avoid privileging the exporters we maintain over others.

[elskwid]

@c24t we are having a similar discussion on the ruby-side in regards to auto-instrumentation, and it will be part of our discussion for exporters. The thinking being it may be advantageous in the short-term to have them in the same repo, especially while the api/sdk libs are still forming. The privileging aspect is something I hadn't considered.

[c24t]

Telemetry exporters must contain minimal functionality, thus enabling vendors to easily add support for their specific protocol.

What's the motivation for putting an extensible exporter class in the SDK instead of an interface in the API? As I understand it, we've got three personas to consider:

• library devs who use OT to generate telemetry data for their library, only depend on the API.
• application owners who use the API (and maybe SDK) in application code, depend on a particular SDK.
• vendors who may ship their own SDK or exporter library to be used by in applications.

Library devs shouldn't use exporters, so from their perspective it makes sense to leave them out of the API. But then vendors are forced to depend on the SDK, even if they're just using it to type-check their exporter implementation.

I know this has been covered before, but I don't see a good source in this repo. Please let me know if there's a discussion in a comment or doc somewhere.

Motivated by a question on python metrics exporters.

[tigrannajaryan]

What's the motivation for putting an extensible exporter class in the SDK instead of an interface in the API? As I understand it, we've got three personas to consider:

* **library devs** who use OT to generate telemetry data for their library, only depend on the API.

* **application owners** who use the API (and maybe SDK) in application code, depend on a particular SDK.

* **vendors** who may ship their own SDK or exporter library to be used by in applications.

Library devs shouldn't use exporters, so from their perspective it makes sense to leave them out of the API.

I agree. There is no need to make exporters and exporter API a dependency for library devs.

But then vendors are forced to depend on the SDK, even if they're just using it to type-check their exporter implementation.

They only need to depend on Exporter interface (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-tracing.md#span-exporter). The spec does not currently define whether Exporter interface can be a separate package so that vendor-specific exporter have less dependencies. Probably it should, we can clarify this in a separate PR.

[SergeyKanzhelev]

Can we please include Zipkin and/or Jaeger for tracing and Prometheus for metrics as a privileged exporters which are recommended to be implemented for all languages.

[tigrannajaryan]

@SergeyKanzhelev I am happy to make the change in this PR if the Spec SIG / TC makes the decision.

It looks like at least one language library author (@c24t) believes including Zipkin, Jaeger, Prometheus in the SDK is easier from maintenance perspective than keeping it to a separate repo. If we have other voices supporting this position I think we should go ahead with that.

One more related data point: for OpenTelemetry Collector we decided that OpenCensus, Zipkin, Jaeger, Prometheus protocol support will be part of Collector "core" while the rest will be moved to a "contrib" repo. This is because we believed the Collector artifact that we produce needs to be usable in production as-is without requiring end users to build their own (which obviously requires some real-world protocols to be supported). The requirements for SDK are a bit different (end users of SDK are building their own apps anyway) but if we aim for uniformity then we can decide to support the same protocols in core SDKs.

[SergeyKanzhelev]

If you can include the note about exporters that we can recommend as a demo exporters - this PR will close this issue #6

[tigrannajaryan]

If you can include the note about exporters that we can recommend as a demo exporters - this PR will close this issue #6

@SergeyKanzhelev sure, I can add a note. Do you want to make a call as a TC member and post the list of recommended exporters here or in the linked issue and I can make it part of this PR?

[SergeyKanzhelev]

@tigrannajaryan would you please make this change as a separate PR. I'm merging this one

[tigrannajaryan]

@tigrannajaryan would you please make this change as a separate PR. I'm merging this one

Added a separate PR to describe recommended exporters: #284