Guidance around defining SemConv for info metrics

[kamphaus]

Should SemConv define guidance on how to define info metrics?
If yes, what should that guidance be?

Info metrics are a well established metric type in Prometheus and OpenMetrics for a time series that has a constant value and whose main value lies in its existence or its attributes.
By convention the name of the metric ends in an _info suffix:

https://prometheus.io/docs/practices/naming/#metric-names:~:text=count%20with%20unit)-,foobar_build_info,-(for%20a%20pseudo
https://github.com/prometheus/OpenMetrics/blob/main/specification/OpenMetrics.md#info
https://github.com/prometheus/OpenMetrics/blob/main/specification/OpenMetrics.md#suffixes

The Otel Specs's page on compatibility with Prometheus / OpenMetrics also includes Info metrics: https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/#info
When exporting to prometheus this already specifies that resources should be exported as an info metric.

This article explains the advantage of an info metric as opposed to including its attributes on other time series as well as ways to use an info metrics in conjunction with other time series in Prometheus queries:
https://www.robustperception.io/exposing-the-software-version-to-prometheus/

Guidance on how to define info metrics could be defined as part of https://github.com/open-telemetry/semantic-conventions/blob/main/docs/how-to-write-conventions/README.md#defining-metrics

Examples of info metrics

• target_info metric exposed by the otel-collector prometheus exporter https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/145942706622aba5c276ca47f48df438228bfea4/exporter/prometheusexporter/collector.go#L335
• otel_scope_info in the otel-collector https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/145942706622aba5c276ca47f48df438228bfea4/pkg/translator/prometheus/constants.go#L22
• node_uname_info in the node-exporter to expose the uname information https://github.com/prometheus/node_exporter/blob/f2ec547b49af53815038a50265aa2adcd1275959/collector/uname.go#L67
• go_info to expose the go version of a go binary https://github.com/prometheus/client_golang/blob/e4b2208dd8cb6d1425f00250db842ec3c1e8749e/prometheus/go_collector.go#L228

Here a screenshot of some info metrics available on a prometheus scraping my k8s state and app metrics:

Related metrics types

A metric type that is related to info metrics are state metrics.
These are gauge metrics where the gauge value corresponds to the values of an enum or boolean.
For example: the up metric from prometheus.

[trask]

thanks @kamphaus!

another place where this could be documented briefly is https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/naming.md#instrument-naming

one question that came to mind, when would we choose having *.uptime vs *.info metric, or could it make sense to have both? (e.g. we currently have system.uptime and process.uptime)

[kamphaus]

Is your question whether we could cover all *.info metrics using a corresponding *.uptime metric with the same attributes?

https://opentelemetry.io/docs/specs/otel/compatibility/prometheus_and_openmetrics/#info mentions the ability to aggregate away labels by summing up the 1s. That's not possible with *.uptime.

The *.uptime metric also supposes that the start time is exactly known.
This is the case for any SDK exporting the uptime of the process it runs in.
However it might not be possible to determine it for externally observed systems like CICD with the cicd.pipeline.run.info metric.
As an example the observer process might restart mid-run which should not reset the emitted *.uptime of the observed system.

or could it make sense to have both?

I guess it depends on the metrics and their attributes, but in general I would say it makes sense to have both.

[dyladan]

It seems to me like _info metrics exist as a prometheus workaround for lack of proper resource/entity support. I'm not sure I understand why we would encode these in the semantic conventions.

[kamphaus]

It seems to me like _info metrics exist as a prometheus workaround for lack of proper resource/entity support. I'm not sure I understand why we would encode these in the semantic conventions.

The resource to info metric transformation is not be sufficient to cover all info metrics (it just defines the target_info metric).
While it would be nice to have proper support for entities in all applications, the current state is that many applications just expose a prometheus endpoint.
I see value in defining SemConv for commonly used info metrics like go_info, node_uname_info and k8s info metrics.
Having SemConv for info metrics could allow for better transformation like reading the node_os_info metric and creating an os entity from it.