Добавили один label в Prometheus и он съел 32 ГБ и упал во время инцидента

[denis_hex97]

Добавили label pod_id чтобы подебажить сеть по 200 подам. Через неделю Prometheus распух с 8 до 32 ГБ RAM и его OOMKilled-нуло прямо посреди прод-инцидента. Алертинг тоже лёг, разумеется. Шикарный тайминг.

[dockerssh2428]

Классика. 50 метрик * 200 подов * churn при каждом деплое = сотни тысяч новых временных рядов в час. pod_id или uuid в лейблах это граната с выдернутой чекой.

[neonapi460]

Ага, посчитали постфактум — около 150k серий в час нагенерили. Чинилось 10 минут через metric_relabel_configs с drop этого лейбла. Но осадок от лежащего алертинга остался надолго.

[ruslan_pro]

Совет: повесьте sample_limit на скрейп и отдельный алерт на prometheus_tsdb_head_series. Чтобы узнавать о кардинальности заранее, а не когда уже OOM прилетел.

[pavel2571]

А почему sample_limit не спас в этом случае? У нас он стоит, я думал он как раз от такого защищает.

[artem_node41]

sample_limit режет на момент скрейпа, но эфемерные серии всё равно живут в head-блоке до истечения staleness (по дефолту 5 минут). При быстром churn подов head пухнет быстрее чем чистится.

[dockerbit4781]

Мы такие сценарии увели в VictoriaMetrics, она на высокой кардинальности по памяти ведёт себя сильно гуманнее. Не серебряная пуля, но дышать стало заметно легче.

[jscode1641]

Это классическая cardinality explosion — ты добавил метку с уникальным значением на каждый под, то есть создал 200 новых time series на каждую существующую метрику с этим лейблом. У Prometheus memory = O(количество активных series), и 200 подов × допустим 50 метрик на под = 10000 новых серий только от одного лейбла. Лечится либо через recording rules (предагрегируй до добавления лейбла), либо вообще не тащи pod_id в Prometheus — для отладки сети конкретного пода лучше Loki с теми же лейблами или временный scrape в отдельный Prometheus instance.

[cacheasync9461]

На будущее: перед добавлением любого лейбла запускай promtool tsdb analyze на снапшоте и смотри cardinality по top series. Там сразу видно, что взорвёт RAM. Ещё полезно выставить --storage.tsdb.max-block-chunk-seg-size и поставить лимит через --query.max-samples, чтобы один кривой запрос не положил весь Prometheus во время инцидента, когда ты как раз лезешь смотреть что горит.

[fedor_tcp]

Алертинг поверх того же Prometheus, который мониторит — это архитектурная бомба, которая тут и взорвалась. В идеале Alertmanager должен принимать алерты и от резервного Prometheus или хотя бы от внешнего healthcheck. У нас после похожей истории поставили отдельный минимальный Prometheus только для алертов на infrastructure-метрики (сам основной Prometheus, node exporter) с жёстким лимитом на количество series через --storage.tsdb.retention.size.