Какие метрики сервера и приложения нужно мониторить

Что мониторить в первую очередь

Метрики делятся на два уровня:

• Ресурсы сервера — CPU, память, диск, сеть. Отвечают на вопрос «хватает ли железа».
• Поведение приложения — задержка, количество запросов, ошибки. Отвечают на вопрос «хорошо ли пользователю».

Начинать стоит со второго уровня: пользователя не волнует загрузка CPU, его волнует, что страница открывается медленно или с ошибкой. Ресурсы помогают понять причину.

Четыре золотых сигнала

Подход из книги Google SRE. Для любого сервиса, который обслуживает запросы:

1. Latency (задержка) — время ответа. Смотрите на перцентили p95 и p99, а не на среднее: среднее прячет медленные запросы.
2. Traffic (трафик) — запросов в секунду или другой показатель нагрузки.
3. Errors (ошибки) — доля неуспешных ответов: HTTP 5xx, таймауты, неверные ответы.
4. Saturation (насыщение) — насколько сервис близок к пределу: очереди, пулы соединений, загрузка самого узкого ресурса.

Методы RED и USE

Два упрощённых чек-листа, которые хорошо дополняют друг друга.

RED — взгляд снаружи, как видит сервис клиент. USE — взгляд изнутри, для поиска узкого места.

Метрики ресурсов и что значит всплеск

Пороги ниже — стартовые точки, а не правило. Правильные значения зависят от вашего нормального уровня нагрузки.

CPU

• Что смотреть: загрузка, load average относительно числа ядер, iowait, steal на виртуалках.
• Стартовый порог: долгая загрузка выше 80–90% — повод разобраться.
• Что обычно значит всплеск: рост трафика, тяжёлый запрос или цикл в коде, cron-задача. Высокий iowait указывает на медленный диск, высокий steal — на перегруженный хост у провайдера.

Память

• Что смотреть: доступная память (available, а не free), использование swap, события OOM killer.
• Стартовый порог: available стабильно ниже 10–15% или активный swap.
• Что обычно значит: утечка памяти (график растёт «лесенкой» до перезапуска), слишком большие кеши или пулы, рост нагрузки.

Диск

• Что смотреть: заполненность, свободные inode, задержка I/O, IOPS.
• Стартовый порог: заполненность выше 80–85% — предупреждение, выше 90–95% — срочно.
• Что обычно значит: разросшиеся логи без ротации, бэкапы на том же диске, временные файлы. Рост задержки I/O — тяжёлые запросы к базе или исчерпанный лимит облачного диска.

Сеть

• Что смотреть: входящий и исходящий трафик, ошибки и потери пакетов, число соединений, TCP-ретрансмиты.
• Что обычно значит всплеск: маркетинговая рассылка или бот-трафик, DDoS, большие выгрузки, проблемы у провайдера.

Метрики приложения и бизнеса

Помимо системных, полезно собирать:

• длительность запросов к базе данных и число медленных запросов;
• размер очередей и время обработки фоновых задач;
• внешние зависимости — платёжные шлюзы, API, их задержку и ошибки;
• бизнес-метрики — регистрации, заказы, оплаты. Резкое падение заказов при «зелёных» серверах часто первым сигнализирует о поломке.

Как настроить алерты без шума

• Алерт должен требовать действия. Если на него можно не реагировать — это не алерт, а график.
• Алертите на симптомы, а не на причины: «выросла доля ошибок» важнее, чем «CPU 85%».
• Используйте длительность: условие держится несколько минут, а не одну точку.
• Разделите уровни: предупреждение в чат, критичное — дежурному.
• Пересматривайте пороги после инцидентов.

Частые ошибки

• Смотреть только на среднюю задержку.
• Мониторить сервер, но не проверять сайт снаружи (uptime-проверки).
• Ставить десятки алертов, к которым команда привыкает и перестаёт реагировать.
• Не хранить историю метрик — без неё не видно трендов и нормального уровня.