cd /news/mlops/one-new-label-multiplied-our-metrics… · home topics mlops article
[ARTICLE · art-134462] src=dev.to ↗ pub= topic=mlops verified=true sentiment=↓ negative

One new label multiplied our metrics by every order we take

Engineer Sergey Shinder recounts how adding a single order-id label to a Prometheus counter caused active time series to explode from roughly 1.1 million to 14 million in under three days, crashing the metrics server during a live payments incident. The team mitigated the outage by dropping the label at the scrape with a relabel rule, then added per-service series budgets, an 80 percent alert threshold, a CI check rejecting metric label names ending in 'id' or matching words like email, path and url, and a dashboard showing top metric names by series count. Shinder argues high-cardinality identifiers belong on traces or exemplars rather than as metric dimensions.

by read2 min views1 publishedSep 19, 2026

On a Friday afternoon a colleague added a label to a counter so he could follow one customer's orders through a queue. The label was the order id. It went through review in four minutes, because it was three characters of change and the reasoning behind it was good.

By Sunday evening our metrics server was restarting in a loop, and on Monday morning, in the middle of a genuine payments incident, we had no monitoring at all.

A label is not a field on a log line. It is a dimension, and every distinct combination of label values is its own time series, with its own entry in a memory resident index and its own block of samples. Our order ids are unique, sixty thousand of them a day, on a counter that four services increment. Those series do not go away when the order does, because they have to be queryable for as long as the retention window. We went from around one point one million active series to fourteen million in under three days.

The failure was not clean. Ingestion slowed first, which delayed rule evaluation, which meant alerts arrived minutes late and some evaluation cycles were skipped altogether. Then the process was killed for memory, came back, spent twenty minutes replaying its write ahead log, and was killed again. The system we would normally use to understand an outage was the system having one.

We dropped the label at the scrape with a relabel rule before touching the application, because that stops it without waiting on a deploy. Then the guards went in. Every service has a series budget and a rule that fires at eighty percent of it. A check in CI rejects any metric whose label name ends in id, or matches a short list of words including email, path and url. A panel shows the top metric names by series count, which none of us had ever looked at and which made the cause obvious in about ten seconds.

The identifier itself was a reasonable thing to want. It belongs on a trace, or on an exemplar attached to a bucket, where it costs one record rather than a whole dimension multiplied across every dimension you already had.

– Sergey Shinder

── more in #mlops 4 stories · sorted by recency
── more on @sergey shinder 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/one-new-label-multip…] indexed:0 read:2min 2026-09-19 ·