Skip to content

feat: support info metrics #267

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.

Sign up for GitHub

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

Open
bernot-dev wants to merge 1 commit into
base: release-2.53.5-gmp
Choose a base branch
from
Open

feat: support info metrics #267

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions google/export/series_cache.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -446,6 +446,14 @@ func (c *seriesCache) populate(ref storage.SeriesRef, entry *seriesCacheEntry, e
metric_pb.MetricDescriptor_DOUBLE,
)

case model.MetricTypeInfo:
protos.gauge = newSeries(
c.getMetricType(metricName, gcmMetricSuffixGauge, gcmMetricSuffixNone),
Copy link
Collaborator

@bwplotka bwplotka Nov 24, 2025

Choose a reason for hiding this comment

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

One question to answer before we move forward: Should we reuse gauge suffixgcmMetricSuffixGauge or add some /info suffix and if that decision even matter now (e.g. we can easily change later). Gauge would totally work for now. The only reason to do info is to be forward compatible with potential special handling of info in PromQL later on. Similar for stateset.

FYI: the definitions of those rare types are here: https://prometheus.io/docs/specs/om/open_metrics_spec/#info

I think it's fine to have gauge for both now, because:

  • There are no clear plans how to have special PromQL handling for info and stateset. There are small discussions on some storage efficiency gains for native info/stateset samples, but that's not impacting us.
  • If, ever, we will make breaking changes to Prometheus to suddenly treat info and stateset specially on PromQL it will be a big thing and in 4.0 Prometheus, soo.. YAGNI.
  • Otel collector is already assuming a "sum" (gauge) AFAIK

@lyanco @realschwa @dashpole to double check my thinking (:

FYI: There's some discussions to add info and stateset natively to SDK (https://cloud-native.slack.com/archives/CC6CPDEJV/p1762847796024439), so they will be more popular, but again, will be treated as a gauge on consumption.

Copy link
Collaborator

@lyanco lyanco Nov 25, 2025

Choose a reason for hiding this comment

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

+1 to YAGNI - gauge seems fine for now and it matches other info-like metrics that already exist (e.g. the ones from ksm).

Do these metrics typically end in _info? If so we can always special case metrics that end in _info/gauge if we ever need to. Or later on if /info becomes necessary we could always change how we write these metrics to include a /info suffix, or double-write (cardinality is not high for these, so cost isn't either), or something.

Copy link
Collaborator Author

@bernot-dev bernot-dev Dec 1, 2025

Choose a reason for hiding this comment

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

The info suffix is specified for OpenMetrics. Not sure how well that translates to real-world usage.

metadata.Help,
metric_pb.MetricDescriptor_GAUGE,
metric_pb.MetricDescriptor_DOUBLE,
)

case model.MetricTypeUnknown:
protos.gauge = newSeries(
c.getMetricType(metricName, gcmMetricSuffixUnknown, gcmMetricSuffixNone),
Expand Down