Эксплуатация: что мониторить в первую очередь

Название идёт от RED — Rate, Errors, Duration, метода Тома Вилки, описывающего каждый запрос тремя числами: сколько идёт, сколько падает, как долго длится. Четвёртый сигнал добавляет книга Google SRE с её четырьмя золотыми сигналами: traffic, errors, latency, saturation — и это то, что в русскоязычных командах называют красным методом мониторинга целиком. Трафик — сколько работы приходит: RPS, сообщений в секунду, заказов в минуту. Ошибки — какая доля работы падает: пятьсотые статусы, невалидные результаты, отказы зависимостей. Латентность — как быстро отвечает сервис, причём интересен хвост: p99, а не средняя, как объяснял урок про гистограммы. Насыщение — насколько сервис забит: глубина очереди, число обработчиков в работе, длина пула соединений. У родственного USE-метода Брендана Грегга та же логика, только для ресурсов: утилизация, насыщение, ошибки.

Порядок для существующего сервиса дисциплинирует и время, и объём. День первый — трафик: счётчик http_requests_total с лейблами route, method и status из урока про HTTP-метрики и одна панель суммарного RPS. День второй — ошибки: та же серия, срез по статусам, панель доли пятисотых. День третий — латентность: гистограмма по route с осмысленными бакетами и панель p50 и p99. День четвёртый — насыщение: датчики обработчиков в работе и очередей, плюс бесплатные go_- и process_-метрики из одиннадцатого урока. Дальше — неделя молчания: команда смотрит на дашборд в будни и релизы, запоминает нормальные уровни, и только после этого пишутся алерты. Каждый шаг мелкий и обратимый, а через неделю у сервиса есть то, чего не давали двести метрик из тикета: ответ на вопрос «жив ли он» за один взгляд.

Сервис приёма платежей два часа отказывал половине заказов, и дежурство узнало об этом от поддержки. Приборная панель тем временем сияла: процессор на тридцати процентах, память в норме, диск спокойный — ресурсы машины выглядели образцово. Что происходило на деле: внутренняя очередь заказов переполнилась после замедления шлюза, новые заказы стали отваливаться по таймауту, а сервис честно съедал процессор на бесполезных ретраях. Метрика трафика молчала — заказы продолжали приходить, — и именно она не должна была молчать: следить требовалось за глубиной очереди и долей ошибок, то есть за насыщением домена, а не утилизацией железа. Вывод кейса длинной в один абзац: дашборд дежурного начинается с сигналов работы — трафик, ошибки, латентность, насыщение, — а графики CPU и памяти существуют, чтобы объяснить уже найденный симптом, а не найти его.

Первый дашборд — здоровье сервиса, шесть-восемь панелей: RPS суммарно, доля ошибок, p50 и p99, обработчики в работе, глубина очереди, горутины и память, статус readiness из девятнадцатого урока. Критерий качества простой: дежурный отвечает на вопрос «что сломалось» за тридцать секунд без чтения документации. Второй дашборд — разрезы: трафик и ошибки по route из шестого урока с переменной route вверху, как в уроке про Grafana; он отвечает на вопрос «где именно». Третий — релизный: сравнение недель до и после выката, латентность и ошибки по версиям. Дальше панелей больше не нужно, пока не появился новый вопрос: дашборд — это справочник дежурного, а не архив графиков, и на вопрос «зачем эта панель» ответ обязан существовать.

Насыщение — самый капризный из четырёх сигналов: у него нет универсальной серии, и прибор подбирается под архитектуру. Для веб-сервиса начинается с датчика обработчиков в работе — то, что рантайм знает сам: число одновременных обработок. Дальше по слоям: глубина очереди заказов в памяти или брокере, время, которое сообщение провело в очереди до обработки, занятость пула соединений к базе, число горутин как косвенный след зависших операций. Важно держать в голове различие: латентность запроса отвечает «как быстро обрабатываем», а время в очереди — «как долго ждём», и растёт обычно первым. CPU и память в этот список не входят: утилизация процессора ничего не говорит о забитости до тех пор, пока не упрётся в потолок, — как раз потому, что кейс платежей лежал при тридцати процентах загрузки. Выбор приборов насыщения — это разговор с архитектором на полчаса, потраченный впрок, потому что именно эти панели останавливают инцидент до таймаутов.

Соблазн поставить алерты в первый же день велик, и он ошибочен: без недели наблюдения пороги пишутся из головы, и дежурство учится игнорировать канал. Порядок такой: дашборд, неделя нормальных уровней, затем алерты на то, что уже видели глазами. Первые три алерта типовые. Доля ошибок выше одного процента в течение пяти минут — симптом, который всегда требует действия. p99 выше согласованного бюджета, скажем секунды, в течение десяти минут — пользователи заметили раньше дежурного. И переключатель мёртвой зоны, dead man's switch: постоянное правило, которое горит всегда, а тишину ловит внешний канал — так обнаруживается пропажа самого мониторинга, о чём писал урок про алерты. Всё остальное — алерты на память, горутины, скрейп — добавляется, когда найден их сценарий действия, а не из солидности.