Топ-5 ключевых метрик мониторинга Nginx: шпаргалка для администратора | AdminWiki
Logo

Топ-5 ключевых метрик мониторинга Nginx: шпаргалка для администратора

25 июля 2026 10 мин. чтения
Содержание статьи

Введение: почему мониторинг Nginx - это не просто графики

Nginx - точка входа для 34% всех сайтов в мире. Каждый запрос пользователя проходит через него. Если сервер начинает деградировать, бизнес теряет деньги сразу: клиенты не могут оформить заказ, API не отвечает, статика не грузится. По статистике эксплуатации, 70% инцидентов с веб-сервером можно предотвратить, если вовремя заметить аномалии в ключевых метриках.

Эта статья - практическая шпаргалка для системных администраторов и DevOps-инженеров. Вы получите пять метрик, которые покрывают 90% проблем Nginx: Active Connections, Requests per Second, процент ошибок 4xx/5xx, Upstream Response Time и Waiting Connections. Для каждой - пороговые значения, признаки проблем и конкретные действия. В конце - готовая таблица для настройки алертов и сценарии комплексной диагностики.

Если вам нужна более глубокая настройка сбора метрик, изучите наше руководство по мониторингу Nginx upstream с health checks. Для быстрого анализа логов пригодится шпаргалка по grep и awk для поиска ошибок.

1. Active Connections: сколько соединений держит Nginx прямо сейчас

Active Connections - количество соединений, которые Nginx обрабатывает в данный момент: читает заголовки, передает тело запроса, отправляет ответ. Эта метрика показывает мгновенную нагрузку на сервер. Рост активных соединений - первый сигнал, что инфраструктура приближается к пределу пропускной способности.

Как получить метрику Active Connections

Включите модуль ngx_http_stub_status_module. Добавьте в конфигурацию Nginx:

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

После перезагрузки Nginx запросите статус:

curl http://127.0.0.1:8080/nginx_status

Пример вывода:

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

Первая строка - искомые Active Connections. Строки Reading, Writing, Waiting детализируют состояние: чтение клиентского запроса, отправка ответа, ожидание в keepalive. Для автоматизированного сбора метрик используйте nginx-prometheus-exporter - он парсит этот вывод и отдает данные в формате Prometheus. Подробная настройка стека описана в нашем руководстве по Prometheus и Alertmanager.

Пороговые значения и типичные проблемы

Лимит активных соединений Nginx вычисляется по формуле: worker_connections * worker_processes. При стандартной конфигурации worker_connections 1024 и одном воркере лимит - 1024 соединения. На высоконагруженных серверах значение worker_connections поднимают до 10240 или выше.

Практические пороги:

  • Норма: до 70% от лимита. Сервер работает в штатном режиме.
  • Предупреждение: 70-85%. Нагрузка высокая, пора анализировать тренды и готовиться к масштабированию.
  • Критично: выше 85%. Nginx начинает отклонять новые соединения. Клиенты видят ошибки подключения.

Резкий скачок Active Connections при неизменном RPS - классический признак медленных клиентов или начала DDoS-атаки на уровне соединений. Проверьте лог ошибок на предмет worker_connections are not enough. Если видите это сообщение - увеличивайте worker_connections или количество воркеров.

Обратная ситуация: Active Connections стабильно низкое, а пользователи жалуются на недоступность. Проверьте, не уперся ли сервер в лимит файловых дескрипторов ОС (ulimit -n). Nginx не сможет открыть новые соединения, даже если worker_connections позволяет.

2. Requests per Second: темп обработки запросов

Requests per Second (RPS) - количество HTTP-запросов, которые Nginx обрабатывает за секунду. Это интегральная метрика производительности всей цепочки: клиент → Nginx → бэкенд. Падение RPS при стабильной входящей нагрузке - прямой сигнал о деградации одного из компонентов.

Мониторинг RPS: инструменты и методы

Получить RPS можно двумя способами. Первый - вычисление из лога доступа: подсчет строк за временной интервал. Второй - через nginx-prometheus-exporter, который отдает метрику nginx_http_requests_total. PromQL-запрос для отображения RPS на дашборде Grafana:

rate(nginx_http_requests_total[1m])

Для настройки алерта на падение RPS ниже порога используйте правило:

alert: NginxLowRPS
expr: rate(nginx_http_requests_total[5m]) < 100
for: 5m
labels:
  severity: warning
annotations:
  summary: "Nginx RPS упал ниже 100 запросов в секунду"

Число 100 замените на ваш baseline - средний RPS за неделю. Без baseline-анализа алертинг будет бесполезен: порог без привязки к реальной нагрузке генерирует ложные срабатывания или пропускает инциденты.

Диагностика по RPS: когда бить тревогу

Отклонение RPS на 30% вниз от baseline при сохранении количества входящих соединений - повод для немедленной проверки. Типичные причины падения:

  • Бэкенд не справляется. Upstream Response Time растет, Nginx ждет ответа, новые запросы в очередь не принимаются. Смотрите метрику Upstream Response Time и ошибки 502/504.
  • Исчерпан лимит worker_connections. Active Connections на максимуме, новые запросы отклоняются.
  • Сетевые проблемы между Nginx и бэкендом. Пакеты теряются, соединения висят в состоянии SYN_SENT.

RPS полезно анализировать в паре с HTTP-кодами ответов. Если RPS растет, а доля 200 не меняется - сервер масштабируется нормально. Если RPS растет вместе с 5xx - бэкенд захлебывается, и рост нагрузки его добивает.

3. Процент ошибок 4xx и 5xx: индикатор здоровья приложения

Коды ответов 4xx сигнализируют об ошибках на стороне клиента: неверный URL, отсутствие прав, некорректный запрос. Коды 5xx - проблемы на стороне сервера: упавший бэкенд, таймаут, внутренняя ошибка приложения. Разделение критически важно: 4xx могут быть нормой, 5xx - всегда инцидент.

Анализ ошибок 4xx: не все они враги

Допустимый уровень 4xx зависит от приложения. Для публичного сайта 3-5% 404 ошибок - норма: поисковые боты перебирают несуществующие URL, пользователи ошибаются в адресах. Резкий скачок 404 может указывать на сканирование уязвимостей или битые ссылки после обновления фронтенда.

Тревожные сигналы среди 4xx:

  • Рост 401/403. Проблемы с аутентификацией или правами доступа. Возможно, истек срок токенов или изменены политики безопасности.
  • Массовые 429 (Too Many Requests). Срабатывает rate limiting. Либо легитимная нагрузка выросла, либо началась атака перебором.
  • Стабильный поток 400 (Bad Request). Кто-то шлет мусорные запросы. Проверьте, не появился ли в логах странный User-Agent.

Для быстрого анализа кодов ответов из логов используйте готовые команды из нашей статьи по анализу логов Nginx с grep и awk.

Ошибки 5xx: красный флаг для администратора

Любая 5xx ошибка - это потерянный запрос. Допустимый уровень - не более 0.1% от общего трафика. Все, что выше 1%, требует немедленного вмешательства.

Ключевые коды и их причины:

  • 500 Internal Server Error. Ошибка в коде приложения. Смотрите логи бэкенда.
  • 502 Bad Gateway. Бэкенд недоступен: упал процесс, закрыт порт, сеть между Nginx и бэкендом разорвана. Проверьте статус сервиса и сетевое соединение.
  • 503 Service Unavailable. Nginx не может найти рабочий бэкенд в upstream-пуле. Все серверы помечены как недоступные после health checks.
  • 504 Gateway Timeout. Бэкенд не уложился в proxy_read_timeout. Увеличьте таймаут или оптимизируйте медленный эндпоинт.

Настройте алерт: более 10 ошибок 5xx в минуту - критический инцидент. Используйте Prometheus-метрику nginx_http_requests_total{status=~"5.."} и правило в Alertmanager. Готовые конфигурации алертов для Nginx, CPU и памяти собраны в пошаговом руководстве по Prometheus и Alertmanager.

4. Upstream Response Time: насколько быстро отвечает бэкенд

Upstream Response Time - время в секундах от отправки запроса бэкенду до получения первого байта ответа. Метрика показывает производительность серверной части приложения. Nginx здесь выступает как измерительный прибор: он фиксирует задержку, которую создает ваш код, база данных и бизнес-логика.

Настройка логирования Upstream Response Time

Добавьте переменную $upstream_response_time в формат access_log:

log_format upstream_time '$remote_addr - $request - $status - '
                         'upstream: $upstream_response_time s';
access_log /var/log/nginx/upstream_time.log upstream_time;

Пример записи в логе:

10.0.0.1 - GET /api/users HTTP/1.1 - 200 - upstream: 0.234 s

Для потокового анализа используйте awk:

awk '{print $NF}' /var/log/nginx/upstream_time.log | sort -n | tail -20

Эта команда покажет 20 самых медленных запросов. Для полноценного мониторинга настройте экспорт метрики nginx_upstream_response_time_seconds через nginx-prometheus-exporter и визуализируйте процентили в Grafana.

Интерпретация значений: когда бэкенд тормозит

Практические бенчмарки для веб-приложений:

  • Отлично: среднее время до 100 мс. Пользователь не замечает задержки.
  • Хорошо: 100-300 мс. Комфортная работа для большинства приложений.
  • Приемлемо: 300-1000 мс. Пользователь ощущает паузу, но остается на сайте.
  • Плохо: больше 1 секунды. Конверсия падает, пользователи уходят.

Среднее значение (p50) может быть обманчиво: 90% запросов выполняются за 100 мс, а 10% - за 5 секунд из-за тяжелых отчетов. Всегда анализируйте процентили p95 и p99. Если p95 превышает 2 секунды - бэкенд требует срочной оптимизации.

Корреляция с другими метриками: рост Upstream Response Time при стабильном RPS и росте 5xx - бэкенд деградирует. Рост вместе с RPS - бэкенд не справляется с нагрузкой, пора масштабировать. Подробнее о настройке мониторинга upstream-пулов читайте в руководстве по health checks и сбору метрик бэкендов.

5. Waiting Connections: скрытая угроза очереди запросов

Waiting Connections - соединения, которые находятся в состоянии keepalive: запрос обработан, ответ отправлен, но TCP-соединение не закрыто. Клиент может отправить следующий запрос по этому же соединению, экономя время на установку нового TCP-рукопожатия. Рост waiting при низких active connections - признак проблемы.

Keepalive и Waiting Connections: как они связаны

Параметр keepalive_timeout определяет, сколько секунд Nginx держит неактивное соединение открытым. Значение по умолчанию - 75 секунд. При 1000 запросов в секунду и таймауте 75 секунд сервер может держать до 75 000 waiting-соединений. Это расходует память и файловые дескрипторы.

Рекомендации по настройке:

  • API и мобильные клиенты: keepalive_timeout 15s; - клиенты быстро забирают данные и уходят.
  • Веб-сайты: keepalive_timeout 30s; - баланс между экономией TCP-рукопожатий и расходом ресурсов.
  • Длинные опросы (long polling): keepalive_timeout 65s; - клиенты висят в ожидании событий.

Параметр keepalive_requests ограничивает количество запросов в рамках одного keepalive-соединения. Значение 100-1000 - разумный компромисс.

Диагностика проблем с Waiting Connections

Нормальное количество waiting-соединений - до 70% от общего числа активных. Если waiting стабильно выше 90%, а active connections низкое - клиенты открывают соединения, но не отправляют запросы. Причины:

  • Слишком большой keepalive_timeout. Соединения висят без дела. Уменьшите таймаут.
  • Медленные клиенты. Пользователи с плохим интернетом долго передают запрос. Nginx держит соединение открытым. Проверьте географию клиентов и сетевые задержки.
  • Ошибка 499 (Client Closed Request). Клиент разорвал соединение до получения ответа. Корреляция роста waiting и 499 - признак, что бэкенд отвечает слишком медленно, и клиенты уходят, не дождавшись.

Проверьте статистику: если waiting растет, а ошибки 499 тоже растут - проблема в медленном бэкенде, а не в настройках keepalive. Клиенты ждут ответа, не выдерживают и отключаются. Nginx при этом продолжает держать соединение до истечения таймаута.

Собираем всё вместе: комплексная диагностика и настройка алертов

Отдельная метрика редко указывает на проблему однозначно. Диагностика строится на корреляции: комбинация отклонений в нескольких метриках формирует паттерн, который точно указывает на первопричину.

Типовые сценарии отказов и их метрики

Сценарий 1: высокая нагрузка. Active Connections > 80% лимита, RPS вышел на плато и не растет, ошибок 5xx нет. Сервер уперся в потолок производительности. Решение: увеличить worker_connections, добавить воркеры, масштабировать горизонтально.

Сценарий 2: деградация бэкенда. Upstream Response Time растет, RPS падает, доля 502/504 ошибок увеличивается. Один или несколько бэкендов не справляются. Решение: проверить логи приложения, перезапустить проблемный инстанс, проверить health checks в upstream-пуле.

Сценарий 3: сетевые проблемы. Waiting Connections аномально высоки, ошибки 499 растут, RPS падает. Сеть между клиентом и Nginx или между Nginx и бэкендом нестабильна. Решение: проверить потери пакетов, задержки, MTU на интерфейсах.

Сценарий 4: DDoS на уровне соединений. Active Connections резко выросли до лимита, RPS не изменился или упал, waiting connections почти нет. Злоумышленник открывает соединения и не шлет запросы, исчерпывая лимит. Решение: включить limit_conn, настроить файрвол на блокировку IP с аномальным количеством соединений.

Шпаргалка: пороговые значения и действия

Метрика Норма Предупреждение Критично Действие
Active Connections < 70% лимита 70-85% > 85% Увеличить worker_connections, добавить воркеры, масштабировать
Requests per Second ±15% от baseline отклонение 15-30% отклонение > 30% Проверить бэкенд, сеть, логи ошибок
Ошибки 5xx < 0.1% 0.1-1% > 1% Проверить статус бэкенда, логи приложения, перезапустить сервис
Upstream Response Time (p95) < 500 мс 500-1000 мс > 1000 мс Профилировать бэкенд, оптимизировать запросы, увеличить ресурсы
Waiting Connections < 70% от active 70-90% > 90% Уменьшить keepalive_timeout, проверить сетевые задержки, ошибки 499

Для оперативного реагирования настройте дашборд в Grafana, который выводит все пять метрик на одном экране. Добавьте алерты с эскалацией: сначала в Telegram, при отсутствии реакции в течение 5 минут - звонок дежурному. Готовые шаблоны дашбордов и правила алертинга для высоконагруженных систем собраны в руководстве по наблюдаемости для высоконагруженных систем.

Заключение: мониторинг Nginx как привычка

Пять метрик - Active Connections, RPS, ошибки 4xx/5xx, Upstream Response Time и Waiting Connections - покрывают 90% проблем веб-сервера. Систематический сбор и анализ этих показателей превращает мониторинг из реактивного тушения пожаров в проактивное управление инфраструктурой. Вы видите проблему до того, как о ней сообщат пользователи.

Начните с малого: включите stub_status, настройте экспорт метрик в Prometheus, создайте дашборд с пятью графиками. Добавьте два-три алерта на критические пороги. Через неделю у вас появятся baseline-значения, через месяц - понимание паттернов нагрузки вашего приложения. Час настройки сегодня экономит часы расследований завтра.

Для углубленного изучения темы используйте материалы Admin-Wiki: мониторинг upstream с health checks, анализ логов grep и awk, построение алертинга на Prometheus.

Поделиться:
Сохранить гайд? В закладки браузера