You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The name of a MetricFamily MUST NOT result in a potential clash for sample metric names as per the ABNF with another MetricFamily in the Text Format within a MetricSet. An example would be a gauge called "foo_created" as a counter called "foo" could create a "foo_created" in the text format.
I read this as a counter name MUST NOT end in _created, because this results in a potential clash.
However, the spec also says
Exposers SHOULD avoid names that could be confused with the suffixes that text format sample metric names use.
Is the problem only with the _created suffix, or are you seeing problems with all other suffixes?
Created timestamp is probably getting a completely new direction. I have the impression that @Maniktherana is working on a proposal to expose it inline with the metric, something like
# TYPE metric counter
# HELP metric example counter with created timestamp
metric 1 ct1234
Regarding suffixes in general we have 3 issues already about it 😅 #281#282#283
The name of a MetricFamily MUST NOT result in a potential clash for sample metric names as per the ABNF with another MetricFamily in the Text Format within a MetricSet. An example would be a gauge called "foo_created" as a counter called "foo" could create a "foo_created" in the text format.
I read this as a counter name MUST NOT end in _created, because this results in a potential clash.
However, the spec also says
Exposers SHOULD avoid names that could be confused with the suffixes that text format sample metric names use.
It would be good to have more clarity whether a suffix like _created is allowed in a metric name or not.
Yes so for counters, summaries and histograms the rule currently is to avoid ending them with _created. If you have a counter, for example, named foo itll have a foo_created line to indicate it's created timestamp.
Other metric types can have _created but they'll be treated as normal (since created timestamps don't apply to those). So if you create a gauge called foo_created, it'll be treated as any other gauge.
Activity
ArthurSens commentedon Dec 9, 2024
Is the problem only with the _created suffix, or are you seeing problems with all other suffixes?
Created timestamp is probably getting a completely new direction. I have the impression that @Maniktherana is working on a proposal to expose it inline with the metric, something like
Regarding suffixes in general we have 3 issues already about it 😅 #281 #282 #283
bwplotka commentedon Dec 9, 2024
Can we add a separate clean issue to track CT discussion? @ArthurSens
Maniktherana commentedon Dec 9, 2024
Yes so for counters, summaries and histograms the rule currently is to avoid ending them with _created. If you have a counter, for example, named foo itll have a foo_created line to indicate it's created timestamp.
Other metric types can have _created but they'll be treated as normal (since created timestamps don't apply to those). So if you create a gauge called foo_created, it'll be treated as any other gauge.
Hope this helps!
ArthurSens commentedon Dec 9, 2024
Sure thing. I was just trying to clarify whether the issue here was specific to CT or about suffixes in general. I'll create a new issue.
If this issue here is just about CT, should we close it?
ArthurSens commentedon Jan 30, 2025
Can I close this issue since we already have three others proposing different ideas for the same problem?