FYI: Broken link

Another way to put it is that gauges, counters, stateset names MUST NOT end with _count, _sum, _gcount, _gsum, _bucket - kind of simple rule. Would that be more clear?

I'd just simplify further:

MetricFamily name MUST NOT end with _count, _sum, _gcount, _gsum, _bucket.

It's true for anything except Histograms and Gauge Histograms , including Summary since that has series without magic suffixes. But I don't think it's worth making an exception for Histograms, Gauge Histograms. Especially because I don't think people will actually follow this unless SDKs prohibit it and I think we need to add a line about ingestors:

Ingestors MAY accept non compliant MetricFamily names and only error out when a naming clash occurs.

Generally good point, but especially _count might be common as a standalone gauge or even counter. This line would prohibit for compatibility reason (so tmp time) and actually is not needed if the same target does NOT expose <metric without _count_but_histogram>.

Ingestors MAY accept non compliant MetricFamily names and only error out when a naming clash occurs.

Again, if this needs to be stronger that we need to move MetricFamily name MUST NOT end with _count, _sum, _gcount, _gsum, _bucket. to SHOULD NOT.

Every "must" MAY be accepted by some implementations, no?

I proposed SHOULD NOT for wide rule, and MUST NOT for collision explanation - framed as "OpenMetrics 2 converted to OpenMetrics 1 or Prom TEXT should not cause collisions)

Yeah, I agree with SHOULD NOT. MUST NOT presumably means that we place more of a burden on clients exposing the metrics to ensure it doesn't happen (like suffixes in OM 1.0). We either would fail scrapes with bad suffixes, or we would have to "fix" names by modifying them to make them valid (which we sometimes did for OM 1.0).

I'd just simplify further:

MetricFamily name MUST NOT end with _count, _sum, _gcount, _gsum, _bucket.

It's true for anything except Histograms and Gauge Histograms , including Summary since that has series without magic suffixes. But I don't think it's worth making an exception for Histograms, Gauge Histograms. Especially because I don't think people will actually follow this unless SDKs prohibit it and I think we need to add a line about ingestors:

Ingestors MAY accept non compliant MetricFamily names and only error out when a naming clash occurs.

From WG:

• Let's have other guidance for naming conventions (snake_case, unit) (TODO)

• What if exposer has this metric, what should be done? We need consistent logic for violating MUST NOT. Implementations are used to be relaxing. TODO research failure modes for violating various MUST NOT rules? e.g. server side will reject this. We don't want to put burden on clients. SDK blocking.
• General usability generic protocol vs e2e Prometheus experience?
• Collision move to should not and be around naming?
• Stronger case than just naming suffix.
• leaning into "SHOULD NOT and explain ingestors/Prometheus will likely reject such scrape for foreseeable future (for this case)"

Assuming SHOULD NOT for the suffixes

MUST NOT conflict

To ensure that the user doesn't run into this, the SDK must validate. We don't do this now, so introducing the check is technically breaking (you can register foo_total gauge and foo counter).

SDKs already check for some collisions (go, java.

But not specifically for this. So I think it's not that hard to implement on top of existing checks !?

It might force a major version, as this can be technically breaking, but on the other hand, I think we'll need a major version anyway to be able to introduce some strict mode that checks that Prometheus naming conventions are followed. SDK strict mode should be the default and I think it should be possible to turn it off generally or per metric.

Even with this validation, the user might run into problems later due to federation or some other feature.

SHOULD NOT conflict

As you say, we can explain why it's bad, but no burden on anyone, the ingestor will just reject the sample if it runs into it. This is simpler. It would be super annoying if we rejected the whole scrape due to one metric.

Conclusion

I think to avoid breaking change due to OM2.0 I'd also say SHOULD NOT.

But I'll continue to advocate for SDKs with default strict mode that checks that the name specified follows Prometheus naming conventions.