Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent requirements for suffixes #284

Open
fstab opened this issue Dec 9, 2024 · 4 comments
Open

Inconsistent requirements for suffixes #284

fstab opened this issue Dec 9, 2024 · 4 comments

Comments

@fstab
Copy link
Member

fstab commented Dec 9, 2024

The spec says

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.

Suffixes for the respective types are:

  • Counter: '_total', '_created'
  • Summary: '_count', '_sum', '_created', '' (empty)
  • Histogram: '_count', '_sum', '_bucket', '_created'
  • GaugeHistogram: '_gcount', '_gsum', '_bucket'
  • Info: '_info'
  • Gauge: '' (empty)
  • StateSet: '' (empty)
  • Unknown: '' (empty)

Here it says SHOULD NOT.

It would be good to have more clarity whether a suffix like _created is allowed in a metric name or not.

@ArthurSens
Copy link
Member

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

@bwplotka
Copy link
Member

bwplotka commented Dec 9, 2024

Can we add a separate clean issue to track CT discussion? @ArthurSens

@Maniktherana
Copy link

The spec says

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.

Suffixes for the respective types are:

  • Counter: '_total', '_created'
  • Summary: '_count', '_sum', '_created', '' (empty)
  • Histogram: '_count', '_sum', '_bucket', '_created'
  • GaugeHistogram: '_gcount', '_gsum', '_bucket'
  • Info: '_info'
  • Gauge: '' (empty)
  • StateSet: '' (empty)
  • Unknown: '' (empty)

Here it says SHOULD NOT.

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.

Hope this helps!

@ArthurSens
Copy link
Member

Can we add a separate clean issue to track CT discussion? @ArthurSens

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants