Introduce Mandatory Unique Identifier For Telemetry Sources

[svrnm]

This OTEP aims to introduce a mandatory unique identifier for telemetry sources, which has been service.name implicitly until now and lead to multiple discussions: https://github.com/open-telemetry/opentelemetry-specification/pull/2111, https://github.com/open-telemetry/opentelemetry-specification/pull/2115, https://github.com/open-telemetry/opentelemetry-specification/pull/2192, https://github.com/open-telemetry/opentelemetry-specification/issues/1034

It's important to provide certainty to end-users to know how to identify their telemetry sources and to future spec changes to have this made explicit.

cc: @jkwatson, @tigrannajaryan, @Oberon00, @martinkuba, @yurishkuro, @jsuereth, @jonatan-ivanov, @carlosalberto

[svrnm]

I updated the file with a lot of changes provided by everyone, thank you! I copied some of your wording, I restructured most of the text. Here are some of the major changes:

• I renamed the proposal from text/0000-mandatory-unique-identifier-for-telemetry-sources.md to 0194-mandatory-unique-identifier-for-sdk-based-telemetry-sources.md
• I followed @jsuereth suggestion to pick one approach and moved the other ones into alternatives. I also provided some arguments for the one I picked and against the ones I pushed down
• I updated the wording to "SDK-based telemetry sources" as discussed with @tigrannajaryan and restructured the document accordingly.
• I added a set of questions that came up based on the changes. My proposed approach is close to @martinkuba's PR https://github.com/open-telemetry/opentelemetry-specification/pull/2192, but I added a few changes I tried to outline:
  • using telemetry.sdk.source.* instead of telemetry.source.*
  • adding telemetry.sdk.source.id as suggested at https://github.com/open-telemetry/opentelemetry-specification/issues/1034 by @Oberon00
  • suggesting to adopt @jsuereth's OTEP https://github.com/open-telemetry/oteps/pull/161 as well to allow migration

[jkwatson]

I feel like this discussion is really talking about 2 separate things, and we should probably separate them into 2 separate oteps.

1. A unique identifier for an instance of a telemetry source (which I believe this otep is attempting to solve).
2. A way to identify a telemetry source by name & type, which will include many many instances. A named App running on many devices or a named Service, running in many k8s pods, for example.

If this otep is only concerned with 1), we should create a separate OTEP to cover how to define 2), and provide backends ways to distinguish between different types of source, because the analysis of telemetry from user/client data sources (RUM) will, in many cases, be very different than the analysis of backend service telemetry.

[svrnm]

I feel like this discussion is really talking about 2 separate things, and we should probably separate them into 2 separate oteps.

1. A unique identifier for an instance of a telemetry source (which I believe this otep is attempting to solve).
2. A way to identify a telemetry source by name & type, which will include many many instances. A named App running on many devices or a named Service, running in many k8s pods, for example.

If this otep is only concerned with 1), we should create a separate OTEP to cover how to define 2), and provide backends ways to distinguish between different types of source, because the analysis of telemetry from user/client data sources (RUM) will, in many cases, be very different than the analysis of backend service telemetry.

When I created this OTEP I had the feeling that those 2 things are intertwined, but after the arguments everyone brought up, I agree, that while they are related, they both require their own OTEP.

I can rewrite the proposal doc to only be concerned around (1).

@jkwatson: I am also happy help creating one for (2)