Summary Metric Support

[cpheps]

Is your feature request related to a problem? Please describe.

Add support for Legacy Summary metric type. This metric type is listed as use for legacy systems and not recommended for use in new receivers. That being said a lot of older (legacy) Java JMX systems have metrics that fit the Summary metric model.

Apache HBase is such a system. Particularly the ops metrics:

hbase.regionserver.<op>_<measure>
Operation latencies, where is one of Append, Delete, Mutate, Get, Replay, Increment; and where is one of min, max, mean, median, 75th_percentile, 95th_percentile, 99th_percentile

Describe the solution you'd like
Add support for the summary metric type.

Describe alternatives you've considered
Capture each part of the summary metric as its own metric.

Additional context
I see this was discussed in issue #4075 but after some discussion with @jsuereth we felt it was worth readdressing the need for this. He might be able to more context also.

[jkwatson]

Before we would do anything for this, the metrics specification would need to support it. We won't add new features to the API without it being spec approved.

[jsuereth]

@jkwatson One thing I want to mention is that I think the legacy use case here (adapting JMX -> OTel), should that be something the API supports or not?

Specifically:

• We don't want to encourage users to use Summary for new metrics, so we don't want to expose it in the API
• Is adapting JMX -> OTel really an API concern? Should we expose an SDK-extension or hook that allows this use case?

While I've been AFK due to personal reasons, I'd still like to see if we can use this issue to "open" an adapter-like interface for advanced use cases like interfacing with existing metric systems via instrumentation.

Agree this needs a specification discussion. IS there a way we could toy with an SDK-extension to lead that discussion?

[jkwatson]

If this could be accomplished with an SDK extension, I'd definitely be in favor of someone submitting a PR for that.

[asafm]

Seems that Summary is defined in the OT spec as can be seen here and here.

Given that, is it possible to contribute code to support it?

[jkwatson]

Seems that Summary is defined in the OT spec as can be seen here and here.

Given that, is it possible to contribute code to support it?

That is the datamodel, not the API spec. We'd need it to be in the API spec before we would support it as a part of our APIs.

[yingziisme]

so any schedule for summary api?

[jkwatson]

so any schedule for summary api?

no. Since this isn't a part of the standard spec, we're probably not going to build it until it becomes part of it.