OTLP Exporter only sets min and max for Summary Data Point

[davidwitten]

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

opentelemetry-go/exporters/otlp/internal/transform/metric.go

Lines 327 to 347 in aff7a80

	SummaryDataPoints: []*metricpb.SummaryDataPoint{
	{
	Labels: stringKeyValues(labels.Iter()),
	Count: uint64(count),
	Sum: sum.CoerceToFloat64(numKind),
	PercentileValues: []*metricpb.SummaryDataPoint_ValueAtPercentile{
	{
	Percentile: 0.0,
	Value: min.CoerceToFloat64(numKind),
	},
	{
	Percentile: 100.0,
	Value: max.CoerceToFloat64(numKind),
	},
	},
	StartTimeUnixNano: uint64(record.StartTime().UnixNano()),
	TimeUnixNano: uint64(record.EndTime().UnixNano()),
	},
	},
	}, nil
	}

I noticed that Summary Data Points are only created from MinMaxSumCountAggregators, where there are only two percentiles set: 0% as the minimum, and 100% as the maximum. This seems like it doesn't take full advantage of the utility of the Summary Data Point, which allows for a list of percentiles and their values.

Describe the solution you'd like

Are there plans for an aggregator similar to the HistogramAggregator that will allow for a full Summary data point (e.g. setting the 10th percentile, 30th percentile, 50th percentile, etc.) ?

[MrAlias]

I noticed that Summary Data Points are only created from MinMaxSumCountAggregators, where there are only two percentiles set: 0% as the minimum, and 100% as the maximum. This seems like it doesn't take full advantage of the utility of the Summary Data Point, which allows for a list of percentiles and their values.

This use of the SummaryDataPoint is a work around to the fact that there is no first class support of the MinMaxSumCount aggregation in the OTLP. Something that is in progress to change (open-telemetry/opentelemetry-proto#162), and the new transport fields will be used for this data once a solution is released.

Are there plans for an aggregator similar to the HistogramAggregator that will allow for a full Summary data point (e.g. setting the 10th percentile, 30th percentile, 50th percentile, etc.) ?

There is no plan currently. Precomputed percentiles have a limited use in that they do not support any aggregation and are quite inflexible. Especially when evaluated against Histograms themselves which offer data that arbitrary percentiles can be computed from at a later time (as well as other useful data analysis methods).

That said, we try to value user requests. If you are an end user that has a need for precomputed percentiles we would like to hear about that usecase and why you prefer it.

If ultimately precomputed percentiles don't make it into the standard aggregators, it is expected to build out the extensibility of our aggregator system. It is still in the design stage, but the idea is an end user can provide their own Aggregator, say one that compute percentiles, and integrate it into the telemetry system.

[jmacd]

I think we should support configurable percentiles for OTLP summary data points. The array, sketch, and histogram aggregators can all produce these percentiles, but I don't think these should be included by default (i.e., MMSC is working).

(Now we need a configurable SDK...)

[MadVikingGod]

This was an issue with an alpha version of the metrics. Currently, there isn't a way for the SDK to generate summary data points; they can only be made via a producer.

I am closing this issue, but if anyone feels that there is more work to be done, please reopen.