A commerce platform lost metrics visibility when their Prometheus servers began getting OOM-killed within minutes of starting. The trigger was a routine application deployment; the cause was a single new label.
A team had added a user identifier as a label on a request counter. Every distinct user created a new time series, so active series count grew without bound during traffic hours. Prometheus consumed memory until the kernel killed it, and on restart it had to replay a write-ahead log that had grown enormous, which took long enough that the process was killed again before it finished. The monitoring system was in a crash loop it could not recover from on its own, and the team had no metrics at all while it was down.
Prometheus on Kubernetes scraping several hundred targets, feeding Grafana dashboards and Alertmanager routes.
First priority was getting a Prometheus process to stay up, which meant breaking the WAL replay loop before addressing the metric itself. We brought the server up in a state where it could complete replay, identified the offending series by cardinality, dropped it at the relabel stage so it stopped being ingested, and then put guardrails in place so the same class of mistake cannot silently repeat.
Active series count fell back to a sustainable level and the OOM crash loop ended the same day. The scrape-level limits have since caught two further cardinality mistakes at ingest, before either affected the server.
Ongoing support for large Prometheus instances where restarts caused extended monitoring blind spots due to slow write-ahead log replay.
Assessment of a Prometheus federation topology that had grown past its limits, causing gaps and duplicated data across sites.
Whether you need architecture advisory, 24/7 support, or full managed services, AceMQ has the expertise to help.