Metric Relabeling Can Be a Memory Optimization

Grafana, Loki and Alloy expose many internal metrics that are useful for development but unnecessary on a small production Prometheus. The monitoring mistake would be to read one metric in isolation. metric_relabel_configs keep-lists for observability components is useful because it narrows the question, and dropping unused series at scrape time reduces tsdb cardinality while retaining process health and the counters needed to debug the monitoring stack itself.

In software operations this falls under telemetry allow-listing. A dashboard becomes much more valuable when the operator knows what a rising line can prove, what it cannot prove, and which second signal should confirm the hypothesis.

My prevention rule is: Keep a reviewed metric set for high-volume exporters, document why each family matters, and revisit the allow-list when adding new dashboards or alerts. That keeps false positives lower without weakening visibility into real degradation.

The hserver source evidence is 218300b. Keeping that provenance matters because monitoring logic changes over time; the article should remain connected to the exact engineering decision it describes.