prometheus / prometheus/OpenMetrics

Extend OpenMetrics by a stability data type

Open
#199 7 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

triage:deciding:needs-info
Dominant language
Go
Stars
2.5k
Forks
175
PR merge metrics
No merged PRs in 30d

Description

In order to improve metrics experience, I would like to propose two fields to be added to the spec.

Stability

Stability is a string that is  used to describe the maturity of the MetricFamily. If it is unset, the MetricFamily is considered stable
Recommended values for lifecycle:
* Alpha for metrics that might be renamed or are unstable in terms of other features (e.g. units or dimensions).
* Beta for metrics that will be considered stable soon.
* Stable This is the default and what consumers can assume if the Stability string is not set.
* Deprecated for metrics that should not be used anymore. 
StabilityHint

StabilityHint is string that is used to provide a human-readable hint for the MetricFamily. This can include e.g. a replacement for the MetricFamily.

As an example:

# TYPE process_cpu_microseconds_total counter
# UNIT process_cpu_microseconds_total seconds
# HELP process_cpu_microseconds_total Total user and system CPU time spent in seconds.
# STABILITY process_cpu_microseconds_total Deprecated
# STABILITYHINT process_cpu_microseconds_total This metric going to be replaced by process_cpu_seconds_total.
process_cpu_microseconds_total 4.20072246e+06

This could allow consumers to warn when an unstable metric is used and improve metrics lifecycle. We currently see issues where e.g. grafana dashboards use a deprecated metric and users only figure out when the metric is gone on the consumer side.

This is similar to https://github.com/OpenObservability/OpenMetrics/issues/189 but with a clearer focus on lifecycle.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the OpenMetrics specification and the related OpenObservability issue #189, since no implementation files or tests are named here. The work is done when the lifecycle fields, syntax, semantics, and compatibility implications have been agreed and incorporated into the specification.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design, observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.