Наблюдаемость и алертинг
Метрики, алерты и SLO, которые указывают на причину: Prometheus, VictoriaMetrics, Alertmanager, Grafana и сигналы, которые врут.
17 статей
- Сертификаты истекли по расписанию. Алерт неделю кричал — в пустотуkubeadm-кластер потерял control plane ровно через год после установки. Алерт об истечении горел семь дней, но у Alertmanager был только receiver null.
- Алерт сработал, и никто его не увидел: метка cluster потерялась в агрегацииНода четыре часа сидела на 90–98% CPU и закончила OOM kill. Алерт на CPU сработал, но avg by(instance) выкинул метку, по которой выбирали все маршруты и дашборды.
- Ребаланс-шторм оказался обычным деплоем: порог, который растёт вместе с группойАлерт на ребалансы Kafka горел на 60 в час при каждом релизе. Метрика суммировалась по 40 консьюмерам и усреднялась по скользящему часу — алерт описывал прошлое.
- Argo CD показывал Synced, а API-сервер молча выкинул мой фиксМесяцы без метрик, фикс уже в git и зелёный Synced. Поля не было в схеме CRD, API-сервер его отрезал, и никто не пожаловался.
- Три отказа алертинга из одного корня: имя там, где должен быть IDКто-то переименовал канал в Slack, и доставка алертов продакшен-системы молча умерла. Это был третий отказ на одном и том же идентификаторе — все прошлые фиксы меняли транспорт и оставляли имя.
- Kafka на 94 % диска, 17 часов в запасе и retention, который хранил вдвое большеТрафик вырос в 150 раз, а тома никто не пересматривал. Хуже того, при дефолтном роллинге сегментов retention в 7 дней на деле означал 7–14. Как мы выиграли время и устранили причину.
- Реплика Postgres 23 часа крутилась в цикле pg_rewind: пересоздавать, а не чинитьПосле failover реплика CloudNativePG не смогла сделать rewind: её WAL-сегменты были нулевого размера, а каталог данных — в десять раз меньше, чем у primary. 23 часа никто не заметил, потому что метрики оператора не собирались.
- Error budget в VictoriaMetrics: recording rules, burn-rate алерты и одна честная панельКак мы собрали error budget для сервисов первого уровня из уже существующих метрик: SLO-цели по сервисам, multi-window burn-rate алерты, ряд в Grafana — и почему отрицательный бюджет сразу после запуска не был инцидентом.
- Один алерт на p99, пять медленных маршрутов, пять разных причинАлерт на латентность уровня сервиса не называл ни одного эндпоинта. Разбивка по маршрутам показала внешний шлюз, проверку капчи, вызов провайдера — и набор ловушек измерения, которые увели бы нас не туда.
- Лаг упал в ноль, а ничего не починилось: зависший Kafka-консьюмер, спрятанный переименованием group.idЛаг консьюмера рос пять дней, потом упал в ноль и там остался. Выглядело как «само рассосалось». На деле консьюмер завис, метрика исчезла, а алерт зарезолвился сам.
- Профилируем утечку памяти в Python на проде с memray — и авария, которую мы устроили по дорогеБэкенд падал по OOM каждые 10–15 часов. Почасовые снимки memray на живом поде нашли утечку в библиотечных middleware, а не в коде приложения — после того как первая попытка положила прод на семь минут.
- Четыре проверки, которые врали, пока система была здороваЗа один день миграций платформы четыре проверки сообщали об ошибке, хотя всё было в порядке. Когда один сигнал спорит со всеми остальными, первым подозревайте сам сигнал.
- Алерты, которые не могут сработать: слепой ServiceMonitor и мёртвый канал доставкиПир Vault 32 часа был sealed, а секреты неделю не синхронизировались — при алерте VaultSealed в репозитории и здоровом Alertmanager. Инцидент спрятали два независимых сбоя.
- Апгрейд GitLab и два сигнала, которые вралиРядовой минорный апгрейд self-hosted GitLab в Docker. Предварительная проверка насчитала 32 незавершённые миграции, а контейнер стал healthy, ничего не обслуживая.
- Смержено, засинкано, смонтировано — и всё равно не алертит: vmalert без hot reloadНовые правила для Kafka прошли через Git и Argo CD в ConfigMap, но vmalert их так и не начал оценивать. GitOps-конвейер оборвался на последнем шаге.
- Панель Grafana, которая говорит, когда под упадёт по OOMКак превратить тренд памяти в ETA до OOM и до заполнения диска на PromQL, два бага, из-за которых панель врала, и утечка, которую она поймала в первый же день.
- Пять дней на 1/3 при зелёных дашбордах: когда статус CRD врётMySQL InnoDB Cluster пять дней работал без HA, а статус ресурса, фаза подов и readiness gate показывали здоровье. Все три сигнала шли от одного зависшего оператора.