Avoid collisions of metric names and “magic” suffixes

[beorn7]

OpenMetrics, with the current state of things, has a bunch of “magic” suffixes:

• _count
• _sum
• _total
• _bucket
• _created

Those suffixes are appended to the metric name. Thus, they collide with other metric names that happen to use the same string at the end of their regular metric name. To avoid those collisions, OpenMetrics has to explicitly disallow metric names ending on those suffixes.

This limitation of the namespace will appear arbitrary to users, it has to be enforced reliably by all implementers of OpenMetrics, and it renders every addition of a new suffix a breaking change of the standard (as we can see right now with _created, which didn't exist in Prometheus, but will be added by OpenMetrics, thereby breaking every existing Prometheus metric that happens to end with _created).

In addition to the practical concerns above, there is also the aspect of “language design”: With the exception of _total, all the suffixes above are essentially encoding “fields” in a “structured” metric. In a programming language, you would only encode structure in a name if the language didn't support structured data types (like struct). It should be noted here that the original Prometheus exposition format had all of the “fields” as actual fields of a protobuf. The encoding as part of the name only happened because the Prometheus server internally had no notion of structured metric values. It was (at least initially) meant as a temporary measure to get an MVP going. The encoding of structure in the metric name later inspired the text format, but back then with the explicit assumption that you would usually not use the text format for structured metric types. What is now being codified as OpenMetrics was back then considered insufficiently robust to serve as the exposition format. At this point, I should also add that dropping the old protobuf format and leaving the text format as the only one the Prometheus server ingests was pushed by individuals without seeking consensus among the Prometheus developers as a whole.

_total is a bit different, as it does not encode structure in the name but type. It's in a way Hungarian notation for metrics. The similarity to the structural suffixes above is that you would usually only encode the type in a name if the underlying language has no type support. Again, the motivation for the suffix happened because Prometheus internally has no type support, everything looks like a gauge. And again, the original vision, as can be seen in the original exposition format, was to include type support.

I get that it is now too late to change OpenMetrics fundamentally to represent structured metrics in a more “native” way (as suggested in the final parts of this section). But perhaps we can at least avoid forcing every implementer eternally to apply the same naming constraints that Prometheus currently has? My idea of a minimal change is to use a suffix separator that is not a legal character in regular metric names. We could, for example, finally make use of the . operator, which would nicely gel with structured types in C-like Syntax:

latency_seconds.bucket{le="0.1"} 42
latency_seconds.sum 1.3435
latency_seconds.count 5
latency_seconds.created 9438298429487.89

It's trivial change in the current Prometheus OpenMetrics parser to make it change . back into _. For all other future consumers of OpenMetrics, things are way saner.

[andrewlayman]

Agreed. The units, e.g. "_seconds" in the example above, are also magic suffixes.

[RichiH]

Please see https://github.com/OpenObservability/OpenMetrics/blob/master/specification/OpenMetrics.md#suffixes