OM 2.0: Consider relaxing the requirement for counters timeseries to have a _total suffix

[dashpole]

The 1.0 specification for counters reads:

The MetricPoint's Total Value Sample MetricName MUST have the suffix "_total".

I propose this should be changed to SHOULD have the suffix "_total" for 2.0.

It is a best practice in Prometheus to suffix counters with _total, but other libraries, such as OpenTelemetry, include counters without a _total suffix. It is much nicer to be able to query for rate({"my.counter"}[5m]) than rate({"my.counter_total"}[5m]) for a metric defined as "my.counter".

[ArthurSens]

I'm very much in favor for this one :)

I can see another downside to not having the suffix: Prometheus today relies on the suffix to provide query annotations, like "You shouldn't use delta() with counters!!!". We would need to think of another strategy there, but I think we're already covering it somewhere else :)

[beorn7]

I think this needs more changes. OM v1 requires the following:

# TYPE foo counter
# HELP foo A help string.
foo_total 42

By just stating that the _total suffix is optional, we would make the following valid:

# TYPE foo counter
# HELP foo A help string.
foo 42

This is notably different from the old state of things, which was either

# TYPE foo_total counter
# HELP foo_total A help string.
foo_total 42

or

# TYPE foo counter
# HELP foo A help string.
foo 42

I also would like to note that the OM decision to not include the _total suffix in the metadata lines meant that existing established patterns became invalid (e.g. the infamous collision between go_memstats_alloc_bytes and go_memstats_alloc_bytes_total).

• Go metrics go_memstats_alloc_bytes and go_memstats_alloc_bytes_total collide in OpenMetrics and are still both exposed client_golang#829
• Another fallout: Prometheus does not recognize HELP and TYPE for OpenMetrics counters prometheus#13944

I think it would be easiest to go back to having the same nome in the metrics lines and in the metadata lines.

[fstab]

I think it would be easiest to go back to having the same name in the metrics lines and in the metadata lines.

Note that a counter often has two time series with different names

# TYPE foo counter
# HELP foo A help string.
foo_total 42
foo_created 239487

This is worse with histograms or summaries, where we have even more time series.

[beorn7]

If _total is just a normal part of the name, then the created name would be foo_total_created. However, IIRC, we want to get rid of the _created line anyway, don't we?

Classic histograms and summaries will stay as they are, of course. This was also the case with the old text format. Those suffixes also have been mandatory always.

The OM intention was to make _total mandatory, and then all those changes make sense. But if we decide to not make it mandatory, then also those other decisions don't make sense anymore.

[beorn7]

Also, note #283 which solves the suffix problems for summaries and classic histograms.