Do not expect metric relabeling to remove Prometheus up

Prometheus excludes automatically generated series such as up from metric relabeling.

Source facts

Prometheus target relabeling rewrites the target label set before scraping and applies steps in configuration order. Metric relabeling operates on samples immediately before ingestion. Metric relabeling does not apply to automatically generated series such as up. The same-looking rule syntax therefore has a different boundary depending on where it is configured.

Source: Prometheus documentation — Configuration.

Applicability

Review native Prometheus metric filtering separately from target selection, including the automatically generated up exception.

DSE recommendation

DSE recommends treating scrape-health series and filtered application samples as separate expected outputs of a collection change. Write an explicit decision for up: retain it as the scrape signal, or change target selection when the intended outcome is to stop scraping that target. Do not present an ingestion filter as proof that the network request stopped. Review rule order when one target transformation supplies another’s input. Keep a small expected-series list with the job so a responder can distinguish an intentional application-metric exclusion from an unavailable exporter.

Verification

In a nonproduction scrape job, compare discovered targets, scrape activity, up, and a disposable application metric before and after the rule. Confirm the chosen stage produces the intended effect without losing unrelated samples. Review the resulting labels for unique series identity. Retain the target state, observed scrape and queries for up and the application metric together. Ask the monitoring owner to approve the result specifically against the expected-series list rather than a single empty dashboard panel.

Official reference

Prometheus documentation — Configuration. Reviewed October 20, 2026.