Ref: #217
MetricsExpositionFormat in spur-core/src/config.rs has two variants: Slurm_0_0_4 (default) and OpenMetrics_1_0. We should simplify this to just OpenMetrics 1.0.
The "Slurm_0_0_4" variant doesn't correspond to a real format spec. Slurm 25.11 labels its own output "OpenMetrics" (MetricsType=metrics/openmetrics) but happens to emit Prometheus 0.0.4 on the wire without # EOF. Spur's compatibility contract covers the CLI, REST API, and FFI. The metrics endpoint lives on a separate port (6822) outside that surface, so there's no need to match Slurm's wire behavior here.
For gauges the body is identical between the two formats. The only difference today is the Content-Type header and the # EOF trailer. However, once we add counters and histograms (scheduler cycle counts, RPC latencies), the formats diverge in meaningful ways (counter _total handling, native histograms, exemplars). Maintaining and testing dual encoding for every new metric type is work we can avoid.
OpenMetrics is what Prometheus prefers. The default scrape negotiation order is OpenMetricsText1.0.0 > 0.0.1 > PrometheusText1.0.0 > PrometheusText0.0.4. Every major scraper and exporter (kube-state-metrics, node_exporter, cAdvisor, OTel Collector) supports it.
No users of this config option exist yet. The endpoint is new in #217, so simplifying now is straightforward. Doing it later would be a breaking config change.
The prometheus-client crate's encode() already produces spec-compliant OpenMetrics 1.0. We can use it directly instead of branching around it.
Ref: #217
MetricsExpositionFormatinspur-core/src/config.rshas two variants:Slurm_0_0_4(default) andOpenMetrics_1_0. We should simplify this to just OpenMetrics 1.0.The "Slurm_0_0_4" variant doesn't correspond to a real format spec. Slurm 25.11 labels its own output "OpenMetrics" (
MetricsType=metrics/openmetrics) but happens to emit Prometheus 0.0.4 on the wire without# EOF. Spur's compatibility contract covers the CLI, REST API, and FFI. The metrics endpoint lives on a separate port (6822) outside that surface, so there's no need to match Slurm's wire behavior here.For gauges the body is identical between the two formats. The only difference today is the
Content-Typeheader and the# EOFtrailer. However, once we add counters and histograms (scheduler cycle counts, RPC latencies), the formats diverge in meaningful ways (counter_totalhandling, native histograms, exemplars). Maintaining and testing dual encoding for every new metric type is work we can avoid.OpenMetrics is what Prometheus prefers. The default scrape negotiation order is
OpenMetricsText1.0.0 > 0.0.1 > PrometheusText1.0.0 > PrometheusText0.0.4. Every major scraper and exporter (kube-state-metrics, node_exporter, cAdvisor, OTel Collector) supports it.No users of this config option exist yet. The endpoint is new in #217, so simplifying now is straightforward. Doing it later would be a breaking config change.
The
prometheus-clientcrate'sencode()already produces spec-compliant OpenMetrics 1.0. We can use it directly instead of branching around it.