Skip to content

Conversation

ywwg
Copy link
Member

@ywwg ywwg commented Oct 2, 2025

@ywwg ywwg force-pushed the owilliams/utf8-abnf branch from 755a40d to 908e3a6 Compare October 2, 2025 15:33
@ywwg ywwg marked this pull request as ready for review October 2, 2025 15:34
@ywwg ywwg marked this pull request as draft October 2, 2025 15:37
Signed-off-by: Owen Williams <[email protected]>
@ywwg ywwg marked this pull request as ready for review October 2, 2025 15:41
Copy link
Member

@krajorama krajorama left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, one nit comment

Signed-off-by: Owen Williams <[email protected]>
Copy link
Member

@krajorama krajorama left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good, I think need some examples with CI check on them

@ywwg ywwg requested a review from krajorama October 6, 2025 17:18
@krajorama
Copy link
Member

@ywwg I'd suggest to scan the "Design considerations" section, in particular https://prometheus.io/docs/specs/om/open_metrics_spec/#metric-naming-and-namespaces .

I've done it as a follow-up to relaxed suffix rules, see #2751

Signed-off-by: Owen Williams <[email protected]>
@ywwg ywwg requested review from dashpole and krajorama October 8, 2025 15:44
-->

We aim for a balance between understandability, avoiding clashes, and succinctness in the naming of metrics and label names. Names are separated through underscores, so metric names end up being in “snake_case”.
We aim for a balance between understandability, avoiding clashes, and succinctness in the naming of metrics and label names. Names are separated through underscores, so metric names end up being in “snake_case”. While we strongly recommend the practices recommended in this document, other metric systems have different philosophies regarding naming conventions. OpenMetrics allows metrics to be exposed, but without the conventions and suffixes recommended here there is an increased risk of collisions and incompatibilities along the chain of services in a metrics system. Users wishing to use alternative conventions will need to take special care and expend additional effort to ensure that the entire ecosystem is consistent.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We aim for a balance between understandability, avoiding clashes, and succinctness in the naming of metrics and label names. Names are separated through underscores, so metric names end up being in “snake_case”. While we strongly recommend the practices recommended in this document, other metric systems have different philosophies regarding naming conventions. OpenMetrics allows metrics to be exposed, but without the conventions and suffixes recommended here there is an increased risk of collisions and incompatibilities along the chain of services in a metrics system. Users wishing to use alternative conventions will need to take special care and expend additional effort to ensure that the entire ecosystem is consistent.
We aim for a balance between understandability, avoiding clashes, and succinctness in the naming of metrics and label names. Names are separated through underscores, so metric names end up being in “snake_case”. While we strongly recommend the practices recommended in this document, other metric systems have different philosophies regarding naming conventions. OpenMetrics allows these metrics to be exposed, but without the conventions and suffixes recommended here there is an increased risk of collisions and incompatibilities along the chain of services in a metrics system. Users wishing to use alternative conventions will need to take special care and expend additional effort to ensure that the entire system is consistent.

Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks for extending!

I assume we will follow with same/similar wording in 2.0, right?

Can we outline e.g. in the description of this PR why we add UTF-8 capability to 1.1 instead of releasing this change with 2.0? Would be useful for bookkeeping.

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

Successfully merging this pull request may close these issues.

4 participants