[BUG] PrometheusSimple emits info metric while advertising legacy Prometheus text exposition

[Godspeed-exe]

Description

cardano-node 11.1.2 emits the cardano_build_info metric with the type info from its built-in PrometheusSimple endpoint.

However, the endpoint advertises the legacy Prometheus text exposition format:

Content-Type: text/plain;version=0.0.4;charset=utf-8

The info metric type is not valid in the Prometheus 0.0.4 text format. As a result, legacy Prometheus clients reject the scrape or report a parsing error.

Environment

cardano-node 11.1.2 - linux-x86_64 - ghc-9.6
git rev fef83fed01d7926f3de83b3b917be5a4a48768b5

The node uses the built-in direct metrics endpoint configured with:

PrometheusSimple suffix 127.0.0.1 12798

cardano-tracer is not being used for this endpoint.

Reproduction

Request the direct node metrics endpoint:

curl -s -D - -o /dev/null http://localhost:12798/metrics

Response headers include:

HTTP/1.1 200 OK
Content-Type: text/plain;version=0.0.4;charset=utf-8

The response contains:

# TYPE cardano_node_metrics_cardano_build_info info
cardano_node_metrics_cardano_build_info{version_major="11",version_minor="1",version_patch="2",version="11.1.2",revision="fef83fed01d7926f3de83b3b917be5a4a48768b5",compiler_name="ghc",compiler_version="9.6.7",compiler_version_major="9",compiler_version_minor="6",compiler_version_patch="7",architecture="x86_64",os_name="linux"} 1

Actual behavior

The response combines:

1. The Prometheus 0.0.4 content type:

text/plain;version=0.0.4

2. An OpenMetrics-only metric type:

# TYPE ... info

This is not valid according to the advertised exposition format.

Expected behavior

The endpoint should produce output valid for the format advertised by its Content-Type.

Possible fixes include:

Option 1: Render the metric as a gauge in legacy Prometheus mode

# TYPE cardano_node_metrics_cardano_build_info gauge
cardano_node_metrics_cardano_build_info{version_major="11",version_minor="1",version_patch="2",version="11.1.2",revision="...",compiler_name="ghc",compiler_version="9.6.7",architecture="x86_64",os_name="linux"} 1

This preserves the existing metadata labels and the conventional value of 1.

Option 2: Serve genuine OpenMetrics

If info is intended, the endpoint should advertise and emit OpenMetrics consistently:

Content-Type: application/openmetrics-text; version=1.0.0

The endpoint should also negotiate this format reliably through the Accept header.

Option 3: Add an explicit compatibility configuration

An option such as the following could allow operators with legacy Prometheus installations to select gauge-compatible output:

{
  "prometheusInfoAsGauge": true
}

Additional notes

The metric is defined in cardano-node/src/Cardano/Node/Tracing/Tracers/NodeVersion.hs using:

PrometheusM "cardano_build_info" (getCardanoBuildInfo nvt)

The direct endpoint is the node's PrometheusSimple backend, not cardano-tracer.

The existing metricsNoSuffix setting does not solve this issue because it changes metric names only; it does not change the metric type.

Impact

Operators using legacy Prometheus-compatible scrapers cannot reliably ingest the node's direct metrics endpoint. The scrape may fail entirely, or the cardano_build_info metric may be rejected.

This is particularly problematic because the endpoint advertises the legacy Prometheus format while returning a metric type associated with OpenMetrics.