Joshua MacDonald

~Having trouble with build dependencies; this may have to wait until OTel-Go 1.10 is released, which includes the recent boundary-inclusivity change.~ ~The `lightstep/sdk/metric/aggregator/histogram/structure` used in this PR also depends on...

I'm concerned that we're offering an easy way to break the OTel data model instead of fixing a memory leak. Consumers who are concerned with correct rate calculations will suffer...

If this is not a leak, I would still like an explanation for why memory usage is so high in this module. My understanding is that a Prometheus receiver would...

Yeah, fingerprinting is a pretty serious optimization for SDKs to make as well, as it can reduce allocations significantly. I recently applied such an optimization to the Lighstep metrics SDK,...

@skonto I want to address your question above, have filed https://github.com/open-telemetry/opentelemetry-go-contrib/issues/2624

@skonto See also https://github.com/golang/go/issues/47216

In Go-1.19 I used [this code](https://gist.github.com/jmacd/01193890b8e6dd05825b01892d287956) to print the 1.19 runtime metrics. What I like about this approach is that the Go team is able to introduce new metrics without...

We need to do something in the specification about this. Since Prometheus does not support `UpDownSumObserver` semantics, the Prometheus exporter should convert these to Gauge. There is a related OTEP...

Thanks @seankhliao. It looks fairly straightforward to fix this support in the Prometheus exporter. https://github.com/open-telemetry/opentelemetry-go/issues/1210

I have argued for some kind of timing instrument, and Bogdan has always opposed it. https://github.com/open-telemetry/opentelemetry-specification/issues/464 I think without a builtin timing instrument, users are likely to get the units...