Prometheus не справляется
Вопрос
Интервьюер: «Prometheus съедает 120 ГБ памяти, запросы дашбордов идут минутами, иногда он падает по OOM. Что будете делать?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Измерить: число активных рядов, топ метрик и меток по кардинальности, тяжёлые запросы
Убрать лишнее: высококардинальные метки, неиспользуемые метрики через metric_relabel_configs
Recording rules для тяжёлых запросов дашбордов и алертов
Шардирование целей по нескольким Prometheus или agent-режим с remote_write
Долгое хранение и глобальные запросы в Thanos, Mimir или VictoriaMetrics
Защита на будущее: sample_limit, ревью метрик, алерт на рост рядов
Что могут спросить следом
- Как понять, какие метрики никто не использует?
- Чем шардирование по функциям отличается от шардирования по хешу?
Разбор
Образцовый ответ: «Память Prometheus почти всегда это число активных рядов, поэтому сначала TSDB Status: обычно 2-3 метрики дают половину рядов, например гистограмма с меткой path из реальных URL или метрики kube-state-metrics по всем лейблам подов. Чиню в источнике, а пока режу через metric_relabel_configs. Затем ищу неиспользуемое: сверяю метрики с запросами дашбордов и правил, выкидываю. Тяжёлые запросы дашбордов перевожу на recording rules. Если и после этого много, разделяю нагрузку: несколько Prometheus по группам целей или agent-режим, который только собирает и пишет remote_write в VictoriaMetrics или Mimir, а запросы идут туда. На будущее sample_limit на scrape, алерт на рост prometheus_tsdb_head_series и ревью новых метрик».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.