Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify the mapping for Prometheus and Statsd exporters #118

Closed
wants to merge 4 commits into from

Conversation

jmacd
Copy link
Contributor

@jmacd jmacd commented Jun 18, 2020

| 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 |
Copy link
Member

@james-bebbington james-bebbington Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Thanks for the detailed explanation

Co-authored-by: Aaron Abbott <aaronabbott@google.com>
@jmacd jmacd requested review from a team July 9, 2020 06:30
Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

#### Prometheus instruments

Prometheus Counter instruments are semantically identical to
OpenTelemetry Counter instruments, including the Mnotonic property.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +142 to +145
| 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 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 |

| Sketch | Summary | Delta | ValueRecorder, ValueObserver | |
| Exact | Summary | Delta | ValueRecorder, ValueObserver | |

Above, (*) denotes the default behavior of an OpenTelemetry
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

applicable OpenTelemetry instruments, for which the Prometheus mapping
is sensible.

| OpenTelemetry aggregator | Default Prometheus data type mapping | Export kind | Typical instruments | Notes |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +174 to +175
Statsd Grouping instruments, which are all except the Statsd Counter
instrument, are exposed as Gauge by default (e.g., as opposed to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +191 to +199
| 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

jmacd commented Sep 18, 2020

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

@jmacd
Copy link
Contributor Author

jmacd commented Sep 28, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metrics Relates to the Metrics API/SDK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ValueRecorder - default aggregation How to model Prometheus Gauge in OpenTelemetry language?
5 participants