Однажды я унаследовал инстанс Grafana с 47 панелями дашбордов. Загрузка CPU, использование памяти, дисковый I/O, сетевые байты, JVM heap — каждая метрика, которую можно вообразить. Всё было зелёным. Постоянно.
Два дня спустя API упал на 4 часа. Ни одного сработавшего оповещения.
Почему? Потому что CPU был на 22%, память — на 45%, а диск — на 30%. Всё «здорово». Настоящая проблема заключалась в истощении пула соединений — метрике, за которой никто не следил.
Четыре золотых сигнала (и ничего больше)
Книга SRE от Google попала в точку. Вам нужно ровно четыре сигнала:
1. Задержка (Latency) — Сколько времени занимают запросы? Не средняя задержка — она скрывает проблемы. Отслеживайте P50, P95 и P99:
- P50 = 200ms означает, что половина пользователей получает ответ за 200ms (хорошо)
- P95 = 800ms означает, что 1 из 20 пользователей ждёт 800ms (приемлемо)
- P99 = 5000ms означает, что 1 из 100 пользователей ждёт 5 секунд (проблема)
Ваш P99 — это ваша реальная производительность. Среднее значение лжёт.
2. Трафик (Traffic) — Сколько запросов вы обрабатываете? Это ваш базовый уровень. Если трафик падает на 80% во вторник в 14:00, что-то не так, даже если все остальные метрики зелёные.
3. Ошибки (Errors) — Какой процент запросов завершается сбоем? Отслеживайте уровень ошибок, а не их количество. 100 ошибок из 1 миллиона запросов (0.01%) — это нормально. 100 ошибок из 200 запросов (50%) — это сбой.
4. Насыщение (Saturation) — Насколько заполнена ваша система? Подключения к базе данных, память, глубина очереди, пулы потоков. Когда любой ресурс достигает 80% использования, нужно действовать — не потому что он сломан, а потому что вы потеряли запас прочности.
Моя реальная настройка мониторинга
Для платформы Nexural:
