Мониторинг Nginx. Какие метрики действительно помогают находить проблемы

Nginx — один из самых популярных веб-серверов и обратных прокси. Он используется для обслуживания сайтов, балансировки нагрузки, завершения SSL-соединений и маршрутизации запросов к приложениям.

При этом многие начинают мониторинг Nginx с просмотра загрузки процессора или количества открытых соединений. Эти показатели действительно полезны, но далеко не всегда позволяют понять, почему пользователи сталкиваются с медленной работой сайта или ошибками.

Чтобы мониторинг приносил реальную пользу, важно отслеживать метрики, которые отражают состояние самого веб-сервера и качество обслуживания запросов.

Какие показатели действительно важны

Прежде всего стоит разделить системные метрики и метрики самого Nginx.

Загрузка CPU, использование памяти и дисковой подсистемы помогают оценить состояние сервера в целом, но не всегда говорят о работе веб-приложения.

Например, процессор может быть загружен всего на 30%, а пользователи при этом получать ошибки 502 из-за недоступности backend-сервиса.

Именно поэтому мониторинг Nginx должен включать собственные показатели работы веб-сервера.

Активные соединения

Одной из самых полезных метрик является количество активных соединений.

Она показывает текущую нагрузку на сервер и позволяет быстро заметить аномалии.

Обычно отслеживают:

• active connections;
• reading;
• writing;
• waiting

Например, резкий рост количества активных соединений может означать:

• всплеск пользовательского трафика;
• DDoS-атаку;
• проблемы с backend-приложением, из-за которых запросы обрабатываются значительно дольше обычного.

Важно анализировать эту метрику в динамике, а не только её текущее значение.

Скорость обработки запросов

Не менее важна производительность самого сервиса.

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

Стоит отслеживать:

• среднее время ответа;
• медиану;
• 95-й и 99-й процентили latency.

Именно высокие процентили чаще всего показывают проблемы раньше средних значений.

Например, среднее время ответа может оставаться на уровне 80 мс, тогда как 99-й процентиль уже вырос до нескольких секунд. Это означает, что часть пользователей сталкивается с серьёзными задержками.

HTTP-коды ответов

Одним из самых информативных источников данных являются коды ответов HTTP.

Рост определённых классов ошибок позволяет быстро понять характер проблемы.

Особенно полезно отслеживать:

• 2xx — успешные запросы;
• 4xx — ошибки клиента;
• 5xx — ошибки сервера.

При этом сами по себе 4xx далеко не всегда являются признаком неисправности. Например, увеличение количества 404 может быть связано с некорректными ссылками или активностью поисковых роботов.

А вот рост 5xx почти всегда требует внимания.

Например:

• 500 — ошибка приложения;
• 502 — backend недоступен или отвечает некорректно;
• 503 — сервис временно не может обработать запрос;
• 504 — превышено время ожидания ответа от upstream.

Резкое увеличение количества таких ответов обычно является одним из первых признаков серьёзного инцидента.

Ошибки upstream

Во многих конфигурациях Nginx работает как reverse proxy перед приложением.

В этом случае проблемы часто возникают не в самом Nginx, а на стороне backend.

Полезно отслеживать:

• количество неудачных подключений к upstream;
• таймауты;
• ошибки чтения ответа;
• количество повторных попыток.

Если backend начинает отвечать медленно или становится недоступным, Nginx обычно первым фиксирует эту проблему.

Поэтому анализ upstream-метрик позволяет быстрее определить источник неисправности.

Скорость установки соединений

Иногда проблема возникает ещё до обработки HTTP-запроса.

Например:

• переполнена очередь входящих соединений;
• заканчиваются файловые дескрипторы;
• сеть испытывает перегрузку.

В результате пользователи замечают долгую загрузку сайта ещё до получения первого байта ответа.

Поэтому полезно следить за временем установления соединений и количеством ошибок подключения.

Логи ошибок

Метрики позволяют обнаружить проблему, а журналы помогают понять её причину.

В error.log можно обнаружить:

• таймауты upstream;
• ошибки SSL;
• проблемы с DNS;
• нехватку системных ресурсов;
• ошибки конфигурации.

Поэтому хороший мониторинг почти всегда объединяет метрики и централизованный сбор логов.

Почему внутренних метрик Nginx недостаточно

Даже если Nginx показывает нормальные показатели активных соединений, низкое количество ошибок и стабильное время обработки запросов, это ещё не означает, что пользователи действительно могут пользоваться сервисом.

Проблемы могут возникать за пределами самого веб-сервера: в сети провайдера, CDN, DNS или на маршруте между клиентом и сервером. В таких случаях внутренние метрики Nginx будут выглядеть нормально, хотя сайт уже недоступен для части пользователей.

Поэтому мониторинг Nginx полезно дополнять внешними проверками доступности.

Например, с помощью Statuser можно регулярно проверять доступность сайтов и API по HTTP и HTTPS из разных географических локаций, измерять время ответа и получать уведомления при появлении ошибок или увеличении задержек. Такой подход позволяет увидеть сервис глазами пользователя и быстрее определить, связана ли проблема с самим Nginx или находится за пределами сервера.

Какие ошибки встречаются чаще всего

Распространённая ошибка — сосредоточиться только на загрузке сервера.

Например, если мониторинг показывает лишь CPU, память и место на диске, можно долго искать причину, хотя проблема давно проявляется в росте 502 или увеличении времени ответа.

Не менее опасно отслеживать только абсолютные значения.

Гораздо полезнее анализировать изменения во времени. Постепенный рост latency, количества ошибок upstream или активных соединений зачастую позволяет обнаружить проблему ещё до того, как пользователи начнут массово обращаться в поддержку.

Итоги

Мониторинг Nginx не должен ограничиваться системными метриками. Наиболее полезную информацию дают показатели, непосредственно связанные с обработкой запросов: активные соединения, время ответа, HTTP-коды, ошибки upstream и скорость установления соединений.

В сочетании с логами и внешним мониторингом такие метрики позволяют быстрее находить причины деградации сервиса, понимать, где именно возникла проблема, и реагировать на неё ещё до того, как она серьёзно повлияет на пользователей.