Joshua MacDonald

I support closing this issue. I'll make an argument against using the context parameter to the metrics-enabled API. In the Lightstep metrics SDK, we have added a [MeasurementProcessor API](https://github.com/lightstep/otel-launcher-go/blob/main/lightstep/sdk/metric/README.md#measurementprocessor) which...

See also https://github.com/open-telemetry/opentelemetry-specification/issues/2232 CC/ @zeitlinger

I would feel comfortable adjusting this in the specification directly. It seems like a very small change to write a new OTEP.

https://github.com/open-telemetry/opentelemetry-specification/pull/4569/commits/d1890766b1241cbaa39b4da4cf52de98be190f7f

The upstream has to apply this first.

There are some confusing assumptions being made in the thread above. While I agree with @lmolkova there is a larger ssue and potentially room for improvement of the tracing interfaces,...

@MadVikingGod I agree with your analysis, and I also support @oertl's response. We are aware of the potential for errors when using relatively simple formulas. We tried to acknowledge this...

It's still true that there's no statsd spec, although at least one document in the OTel org describes it now: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/master/receiver/statsdreceiver/README.md Most systems that support statsd also support other formats,...

I've referred to my former attempt at this many times in the months since I first opened it, so here it is again. Following feedback from @evan-bradley I changed the...

https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/42573 is an example of an ad-hoc extension mechanism in collector-contrib: it might be valuable to apply these patterns in that repository.