Hserver Monitoring: Observability Architecture · advanced
Prometheus Series Count Is an Observability Capacity Metric
The hserver stack carried roughly twenty-seven thousand active Prometheus series, enough that label growth and exporter changes could materially change memory and storage cost.
The hserver stack carried roughly twenty-seven thousand active Prometheus series, enough that label growth and exporter changes could materially change memory and storage cost. On hserver the first signal I use for this question is prometheus_tsdb_head_series and acceptance baseline. Series count is the closest operational measure of metric cardinality pressure and gives a before-and-after check for scrape or label changes.
The important part is interpretation rather than collecting another graph. cardinality budgeting. That gives the metric a specific operational job instead of making it another number on a dashboard.
The practical control is straightforward: Record a baseline, review large jumps after exporter changes, and remove unnecessary high-cardinality labels before increasing Prometheus resources. This also gives me a repeatable check after deployments, exporter changes, or capacity tuning.
Repository evidence for this monitoring behavior is commit 218300b. I keep that reference with the note because a monitoring conclusion is stronger when the configuration and runtime decision that produced it can be inspected later.