Revert #5308?

[trask]

Heads up, based on specification meeting discussion today, I'm proposing in open-telemetry/opentelemetry-specification#3493:

Do not use total

Counters have _total appended to their names when they are mapped to Prometheus, which would lead to _total_total. The reason that the Prometheus mapping cannot suppress adding the duplicate _total is because then the mapping wouldn't be bidirectional.

[jack-berg]

I still think #5308 is a justifiable change, since as mentioned here, the prometheus client does the same check. I think we should wait for the prometheus compatibility doc to explicitly disallow this before we revert.

[trask]

@jsuereth described the problem with this kind of non-bidirectional mapping on the spec call:

with #5308: xyz_total -> SDK (prom endpoint) -> Collector scraping --> OTLP --> xyz 🚫

without #5308: xyz_total -> SDK (prom endpoint) -> Collector scraping --> OTLP --> xyz_total 🟢

[jack-berg]

Ah, interesting. It's an unusual use case, since if you're going to the collector you'd almost certainly prefer OTLP to maximize data integrity. Using prometheus as an intermediate representation in a pipeline that terminates in OTLP has a simple solution - don't use the prometheus format! 😁

Interested in what @ShadowySpirits and @dashpole think about this. Tried to get @dashpole to chime in before #5308, but I think he's on leave.

[jack-berg]

@dashpole check out this additional argument for double appending _total.

[dashpole]

IMO the duplicate _total is worse than not round-tripping. But this is also made moot if we don't strip total in the prometheus receiver anymore: open-telemetry/wg-prometheus#72

[jack-berg]

Closing this now that the spec has clarified that implementations should not add duplicate suffixes: open-telemetry/opentelemetry-specification#3581