Мониторинг инфраструктуры: какие метрики действительно полезны

Состояние сервиса, saturation, latency, error rate и почему одного CPU недостаточно.

Мониторинг нужен не для красивых графиков, а для ответа на вопросы: работает ли сервис, ухудшается ли качество и где находится узкое место. Поэтому полезнее начинать от пользовательского результата и лишь затем спускаться к ресурсным метрикам.

Четыре группы сигналов

Для многих систем хорошо работают четыре класса показателей: latency, traffic, errors и saturation.

Latency показывает, сколько занимает операция. Traffic — сколько запросов или работы проходит через систему. Errors отражает неуспешные операции. Saturation показывает, насколько близко ресурс подошёл к пределу.

Почему CPU 90% не всегда проблема

Высокая загрузка CPU сама по себе может означать, что сервер эффективно выполняет работу. Проблема начинается, когда появляется очередь и растёт время ответа.

И наоборот, CPU 20% не доказывает здоровье приложения: оно может ждать БД, сеть, блокировку или внешний API.

Метрики должны быть связаны

Хорошая панель позволяет пройти путь от симптома к ресурсу. Например: выросло время ответа API → выросло время запросов БД → на storage увеличилась latency записи.

Алерты

Алерт должен приводить к действию. Постоянно мигающий порог, который никто не расследует, создаёт alert fatigue.

Практический вывод

Начинать стоит с доступности и пользовательской задержки, затем добавлять показатели ключевых зависимостей и насыщения ресурсов.