Skip to content

Inconsistent requirements for suffixes #284

Open

Description

@fstab

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.

Activity

  1. ArthurSens commented on Dec 9, 2024

    @ArthurSens
    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

  2. bwplotka commented on Dec 9, 2024

    @bwplotka
    Member

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

  3. Maniktherana commented on Dec 9, 2024

    @Maniktherana

    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!

  4. ArthurSens commented on Dec 9, 2024

    @ArthurSens
    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?

  5. ArthurSens commented on Jan 30, 2025

    @ArthurSens
    Member

    Can I close this issue since we already have three others proposing different ideas for the same problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions