Joshua MacDonald

I propose to close this issue in favor of https://github.com/open-telemetry/opentelemetry-specification/issues/2746 and https://github.com/open-telemetry/opentelemetry-specification/issues/2810.

We discussed this in the Prometheus working group today because we feel it is important for OTel and Prometheus to align on how we handle cardinality explosions. We placed our...

The OTC Prometheus receiver has effectively replaced the need for this project by now.

FWIW https://github.com/open-telemetry/opentelemetry-collector/pull/8111#issuecomment-1654148294 I recommend we lean on the OTel global providers instead of supporting a different way to inject those dependencies.

For what it's worth, we are happy with https://github.com/lightstep/otel-launcher-go/tree/main/lightstep/instrumentation/runtime and are happy to help return that code, which was forked, to this repository. One thing is we are still missing...

Independently, I wonder if we've considered putting some information such as `telemetry.sdk.{name,version}` into HTTP or gRPC headers, which would allow us to route traffic based on OTLP version in case...

:tada: @PeterF778 this is looking great!

Please add a description to this PR and refer to issues where this was discussed. I believe we had decided not to do this. Sampling SIG has discussed creating semantic...

I think this is the status: https://github.com/open-telemetry/opentelemetry-specification/pull/3825#issuecomment-2066466968

@utpilla I agree with your reasoning -- there can be disagreement over how the behavior is implemented, but the attribute meaning is well defined either way, I think, and I...