Specify the mapping for Prometheus and Statsd exporters

[jmacd]

Resolves open-telemetry/opentelemetry-specification#636
Relates to #117
Resolves open-telemetry/opentelemetry-go#708.

[james-bebbington]

The notes say that LastValue will be exposed as a Gauge. Is the idea that we will throw away the other non-LastValue (Min/Max/Sum/Count) aggregations by default?

I would have thought a more natural default would be for each of these aggregations to be represented as a separate Gauge, otherwise we are aggregating that data just to throw it away - i.e.

metricname_min
metricname_max
metricname_last
metricname_sum
metricname_count

That would obviously have some implications for the mapping from Prometheus -> OT -> Prometheus that I'm not too sure how to address.

[jmacd]

What you propose is a viable export strategy, I just don't believe it's the one most Prometheus users want or expect. This is what the Prometheus "Summary" metric exports, approximately. If we replaced "metricname_last" with just "metricname" that would create less confusion for Prometheus users, but they might not appreciate the cost of indexing new metric names that they never wanted.

It would be more optimal, but much more complex, to try to match the default aggregation to the configured exporter. If an OTLP exporter is configured, then the question becomes recursive. What aggregation should I use to satisfy a downstream exporter? That would create a headache at startup.

The idea of adding an optimization (#117) to store a single value when there is in fact a single value, was meant to address some of the concern about throwing away information. I believe some platforms want to see min/max/sum/count and would not like to force users of those systems to reconfigure the aggregation.

[james-bebbington]

Makes sense. Thanks for the detailed explanation

[MrAlias]

Overall looks good and I think will help unify and clarify.

[MrAlias]

Suggested change

	OpenTelemetry Counter instruments, including the Mnotonic property.
	OpenTelemetry Counter instruments, including the Monotonic property.

[MrAlias]

Suggested change

	| Sum (Monotonic) | Counter | Cumulative | Counter(*), SumObserver(*) | |
	| Sum (Non-Monotonic) | Gauge | Cumulative | UpDownCounter(*), UpDownSumObserver(*) | |
	| LastValue | Gauge | Cumulative | ValueRecorder, ValueObserver, SumObserver, UpDownSumObserver | |
	| MinMaxLastSumCount | Gauge | Delta | ValueRecorder(*), ValueObserver(*) | Expose the LastValue field as the Gauge |
	| Sum (Monotonic) | Counter | Cumulative | Counter(\*), SumObserver(\*) | |
	| Sum (Non-Monotonic) | Gauge | Cumulative | UpDownCounter(\*), UpDownSumObserver(\*) | |
	| LastValue | Gauge | Cumulative | ValueRecorder, ValueObserver, SumObserver, UpDownSumObserver | |
	| MinMaxLastSumCount | Gauge | Delta | ValueRecorder(\*), ValueObserver(\*) | Expose the LastValue field as the Gauge |

[MrAlias]

Suggested change

	Above, (*) denotes the default behavior of an OpenTelemetry
	Above, (\*) denotes the default behavior of an OpenTelemetry

[MrAlias]

I see potentially two different people reading this table: an OpenTelemetry developer writing an exporter for prometheus, and an existing Prometheus instrumentation author looking to migrate to OpenTelemetry instrumentation.

This table seems to serve the the former well, but I'm not sure it is clear for the latter as to what they need to do. Guessing there would like a more explicit mapping between Prometheus type and OTel Instrument. I'm guessing the one-to-many mapping might be a bit overwhelming.

Is this something we can assume Prometheus instrumentation writers can work out (i.e. become familiar with synchronicity, precomputed sums, and additive/grouping)?

Is this something for a different PR?

Could this be added in a subsequent table?

[MrAlias]

I'm not following the meaning here. Maybe?

Suggested change

	Statsd Grouping instruments, which are all except the Statsd Counter
	instrument, are exposed as Gauge by default (e.g., as opposed to
	Statsd Grouping instruments which are all, except the Statsd Counter
	instrument, exposed as Gauges by default (e.g., as opposed to a

[MrAlias]

Suggested change

	| Sum (Monotonic) | Counter | Counter(*), SumObserver(*) | |
	| Sum (Non-Monotonic) | Gauge | UpDownCounter(*), UpDownSumObserver(*) | |
	| LastValue | Gauge | ValueRecorder, ValueObserver, SumObserver, UpDownSumObserver | |
	| MinMaxLastSumCount | Gauge | ValueRecorder(*), ValueObserver(*) | Expose the LastValue field as the Gauge |
	| Histogram | Summary | ValueRecorder, ValueObserver | |
	| Sketch | Summary | ValueRecorder, ValueObserver | |
	| Exact | Summary | ValueRecorder, ValueObserver | |
	Above, (*) denotes the default behavior of an OpenTelemetry
	| Sum (Monotonic) | Counter | Counter(\*), SumObserver(\*) | |
	| Sum (Non-Monotonic) | Gauge | UpDownCounter(\*), UpDownSumObserver(\*) | |
	| LastValue | Gauge | ValueRecorder, ValueObserver, SumObserver, UpDownSumObserver | |
	| MinMaxLastSumCount | Gauge | ValueRecorder(\*), ValueObserver(\*) | Expose the LastValue field as the Gauge |
	| Histogram | Summary | ValueRecorder, ValueObserver | |
	| Sketch | Summary | ValueRecorder, ValueObserver | |
	| Exact | Summary | ValueRecorder, ValueObserver | |
	Above, (\*) denotes the default behavior of an OpenTelemetry

[jmacd]

This is obsolete, I will re-open a new proposal to replace this and open-telemetry/opentelemetry-specification#919

[jmacd]

Related content: open-telemetry/opentelemetry-go#1210