Joshua MacDonald

Counter is appropriate because the value is monotonic. We are explicitly interested in detecting resets via this metric, which suggests that UpDownCounter is appropriate. Note the expression `rate(uptime)` is definitely...

Although we haven't discussed this concept much before, it's been on my mind. The proposal in https://github.com/open-telemetry/oteps/issues/78 was about API support for preparing a Tracer with static resources, and the...

An even-more tangential remark is that by using the Metric SDK to index SpanInstrument/trace_id/span_id as the primary data store, the problem discussed in https://github.com/open-telemetry/oteps/issues/73 could be solved easily.

@lquerel has pointed out that a prepared span (a.k.a. "Span Instrument") would help SDKs lower the cost of column-oriented encoding and transport.

We will review this PR this week. @smithclay to consider whether we are willing to add this support in all launchers, also to discuss timeline for adopting https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/samplers/probability/consistent in our...

There are now slight upstream changes (e.g., an improved comment). https://github.com/lightstep/go-expohisto

This is a near-duplicate of #3021. Adjusting the title.

Question about go.opentelemetry.io/otel/sdk/metric/aggregator/exponential/mapping (which exists today and should stay _somewhere_). I think it's OK if that package moves.

EDIT: The code in question has been released at github.com/lightstep/go-expohisto ~Please take another look.~ ~This now depends on the latest release of Lightstep's metric SDK as well as an "orphaned"...

This PR has been updated to use a new, separate copy of Lightstep's OTel exponential histogram mapping functions and data structure. Please take another look!