Мониторинг Nginx через Grafana и Prometheus - прямой путь к контролю над производительностью веб-сервера. Вы получаете единую панель, где в реальном времени видны нагрузка, задержки и ошибки. Этот материал - пошаговое руководство от включения stub_status до настройки алертов в Slack. Все конфигурации проверены на production-окружениях и готовы к внедрению.
Основная цель - дать вам рабочий дашборд и понимание каждой метрики. Вы узнаете, как собирать данные через nginx-prometheus-exporter, строить графики по запросам PromQL и настраивать оповещения о критических сбоях. Следуйте инструкциям последовательно, и через час у вас будет готовая система мониторинга.
Ключевые метрики Nginx для мониторинга
Эффективный дашборд начинается с правильных метрик. Nginx отдаёт десятки показателей, но для оперативного контроля достаточно четырёх групп: RPS, время ответа, ошибки и активные соединения. Они входят в методологию RED (Rate, Errors, Duration) и покрывают 90% инцидентов, связанных с веб-сервером. Отклонение любого из этих показателей сразу указывает на деградацию сервиса.
Связь метрик с пользовательским опытом прямая: рост времени ответа увеличивает отказы, ошибки 5xx ломают функциональность, а падение RPS до нуля означает полную недоступность. Отслеживая эти четыре сигнала, вы видите полную картину здоровья Nginx без лишнего шума.
RPS и время ответа: основа анализа производительности
RPS (Requests Per Second) показывает количество запросов, которые Nginx обрабатывает ежесекундно. Это индикатор нагрузки. Резкий скачок RPS без изменения трафика часто указывает на атаку или ошибку в клиентском приложении, генерирующем повторные запросы. Плавный рост в течение недель говорит о естественном увеличении аудитории и необходимости масштабирования.
Время ответа измеряется тремя способами. Среднее значение (avg) обманчиво: один медленный запрос на фоне тысяч быстрых почти не меняет картину. Медиана (p50) показывает типичный опыт пользователя. Но главный инструмент - процентили p95 и p99. P99 = 2 секунды означает, что 1% пользователей ждут ответа дольше двух секунд. Именно эти «хвосты» вызывают жалобы и отток. На дашборде выводите p95 и p99 отдельными линиями, а среднее - полупрозрачным фоном для контекста.
Ошибки и активные соединения: индикаторы стабильности
HTTP-коды ответа делятся на две категории. Ошибки 4xx (403, 404, 429) сигнализируют о проблемах на стороне клиента: неверные токены, отсутствующие ресурсы, превышение лимитов. Их рост требует проверки клиентского кода или конфигурации Nginx. Ошибки 5xx (500, 502, 503, 504) - это сбои на серверной стороне: упавший бэкенд, таймаут соединения, нехватка памяти. Каждая 502 или 504 ошибка означает, что пользователь не получил ответ. Мониторинг соотношения 5xx к общему числу запросов - прямой индикатор стабильности.
Активные соединения Nginx отдаёт в разрезе трёх состояний: reading (чтение заголовков), writing (отправка ответа), waiting (keep-alive соединения в ожидании). Рост waiting до пределов worker_connections блокирует приём новых запросов. На графике соединений вы сразу видите, исчерпан ли пул и когда началась деградация.
Сбор метрик: настройка Nginx Prometheus Exporter
Prometheus не умеет забирать метрики напрямую из Nginx. Нужен промежуточный компонент - экспортер. Официальный nginx-prometheus-exporter подключается к stub_status Nginx, парсит текстовый вывод и отдаёт данные в формате, понятном Prometheus. Схема простая: Nginx → stub_status → exporter → Prometheus → Grafana.
Перед запуском экспортера убедитесь, что Nginx собран с модулем ngx_http_stub_status_module. Проверьте командой nginx -V 2>&1 | grep -o with-http_stub_status_module. Если модуля нет, пересоберите Nginx или используйте готовый образ из статьи по практическому мониторингу Nginx, где приведены готовые конфигурации.
Включение stub_status в Nginx
Добавьте в конфигурацию Nginx отдельный server-блок или location внутри существующего:
server {
listen 127.0.0.1:8080;
server_name localhost;
location /nginx_status {
stub_status;
allow 127.0.0.1;
deny all;
}
}Директива allow/deny критична: stub_status раскрывает внутренние счётчики, и доступ извне недопустим. После изменения конфигурации выполните nginx -t && nginx -s reload. Проверьте отдачу метрик: curl http://127.0.0.1:8080/nginx_status. Вывод содержит активные соединения, общее количество принятых и обработанных запросов, а также счётчики чтения, записи и ожидания.
Запуск nginx-prometheus-exporter
Самый надёжный способ - Docker. Команда для запуска:
docker run -d \
--name nginx-exporter \
-p 9113:9113 \
nginx/nginx-prometheus-exporter:latest \
-nginx.scrape-uri=http://172.17.0.1:8080/nginx_statusФлаг -nginx.scrape-uri указывает URL вашего stub_status. Если Nginx и экспортер в одном Docker-хосте, используйте IP шлюза docker0 (обычно 172.17.0.1) вместо localhost. Проверьте метрики: curl http://localhost:9113/metrics. Вы увидите строки вида nginx_connections_active, nginx_http_requests_total - это то, что будет забирать Prometheus.
Добавьте job в конфигурацию Prometheus (prometheus.yml):
scrape_configs:
- job_name: 'nginx'
static_configs:
- targets: ['localhost:9113']После перезагрузки Prometheus метрики появятся в его UI. Для комплексного мониторинга сервера, на котором работает Nginx, дополнительно настройте Node Exporter. Готовый стек описан в руководстве по развёртыванию мониторинга за 1-2 часа.
Создание дашборда в Grafana: пошаговое руководство
Grafana подключается к Prometheus как к источнику данных и отображает метрики на панелях. У вас два пути: импортировать готовый дашборд из каталога Grafana.com или собрать свой с нуля. Первый вариант даёт результат за минуту, второй - полный контроль над визуализацией.
Импорт готового дашборда из Grafana.com
Самый популярный дашборд для nginx-prometheus-exporter имеет ID 11111. Для импорта перейдите в Grafana: Dashboards → New → Import. В поле «Import via grafana.com» введите 11111, нажмите Load. Выберите источник данных Prometheus и подтвердите импорт. Дашборд сразу покажет графики RPS, соединений и ошибок.
Готовые дашборды экономят время, но часто требуют доработки под ваши пороги и легенды. После импорта проверьте, что все панели получают данные. Если какая-то пустая, скорее всего, имена метрик в запросах не совпадают с теми, что отдаёт ваш экспортер. Сравните их через Explore в Grafana.
Создание панелей вручную: запросы PromQL
Ручная сборка дашборда даёт понимание каждого графика. Начните с панели RPS. Создайте новую панель с типом Graph, в поле запроса введите:
rate(nginx_http_requests_total[1m])Функция rate() вычисляет запросы в секунду за последнюю минуту, сглаживая краткосрочные всплески. В легенде укажите {{instance}} для отображения имени сервера. Единицы измерения задайте как «reqps» (requests per second).
Для времени ответа Nginx отдаёт гистограмму через переменные nginx_http_request_duration_seconds_bucket. Запрос для p99:
histogram_quantile(0.99, rate(nginx_http_request_duration_seconds_bucket[1m]))Повторите для p95 и p50, меняя квантиль. Выводите эти три линии на одном графике - так вы видите и типичное время, и выбросы.
Панель ошибок стройте на отношении кодов 5xx к общему числу запросов:
sum(rate(nginx_http_requests_total{status=~"5.."}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100Результат - процент ошибок. Для этой панели подходит тип Stat с цветовыми порогами: зелёный до 1%, жёлтый до 5%, красный выше.
Активные соединения отображайте типом Graph с тремя линиями:
nginx_connections_active{state="reading"}
nginx_connections_active{state="writing"}
nginx_connections_active{state="waiting"}Добавьте горизонтальную линию-порог на уровне 80% от worker_connections. Это визуальный индикатор приближения к лимиту. Примеры запросов и визуализаций также разобраны в статье по мониторингу кластерной инфраструктуры.
Настройка алертов в Grafana для критических ситуаций
Дашборд бесполезен, если вы не смотрите на него круглосуточно. Алерты переводят мониторинг из пассивного в активный режим: система сама сообщает о проблеме. Grafana позволяет создавать правила прямо на панелях, без дополнительной настройки Alertmanager (хотя для production-сред Alertmanager рекомендуется).
Пороги срабатывания настраивайте от реальных показателей вашего сервиса, а не от абстрактных цифр. Снимите baseline за неделю: какие RPS в час пик, какое p99 время ответа в норме, какой процент ошибок считается фоновым. От этих значений отталкивайтесь при установке порогов.
Примеры правил алертинга для Nginx
Алерт на рост ошибок 5xx. Условие: процент ошибок 5xx превышает 5% в течение 5 минут. В поле Alert на панели ошибок задайте:
WHEN avg() OF query(A, 5m, now) IS ABOVE 5Пять минут исключают ложные срабатывания при краткосрочных всплесках. Имя алерта: «Nginx High 5xx Rate». В описании укажите: «Доля 5xx ошибок {{$value}}% на {{$labels.instance}}, проверьте бэкенд и логи».
Алерт на задержки. Условие: p99 время ответа превышает 2 секунды в течение 3 минут. Этот порог критичен для пользовательского опыта. Имя: «Nginx P99 Latency High». В описании добавьте ссылку на дашборд для быстрого перехода к анализу.
Алерт на падение трафика. Условие: RPS падает до 0. Это означает, что Nginx не принимает запросы - полный отказ. Здесь задержку перед срабатыванием ставьте минимальную, 1 минуту. Имя: «Nginx Zero Traffic».
Интеграция с каналами уведомлений
Grafana поддерживает встроенные уведомления через Contact Points. Для Slack создайте Webhook в настройках рабочего пространства, затем в Grafana: Alerting → Contact Points → New. Выберите тип Slack, вставьте Webhook URL, укажите канал. Протестируйте кнопкой Test.
Для Telegram и Email настройка аналогична. Рекомендуется дублировать критические алерты в два канала: мгновенное оповещение в мессенджер и резервное на email. Детальная настройка Alertmanager с маршрутизацией и группировкой алертов описана в руководстве по алертингу в Kubernetes - принципы применимы и к standalone Nginx.
Типовые проблемы и их решение
Нет данных в Grafana. Проверьте цепочку последовательно: curl на stub_status → curl на exporter → Prometheus targets (Status → Targets) → Grafana Data Source. В 80% случаев проблема в сетевой доступности между компонентами или неверном IP в -nginx.scrape-uri. Если Prometheus видит exporter, но Grafana молчит, проверьте временной диапазон дашборда - возможно, вы смотрите на старый период без данных.
Высокая кардинальность метрик. Если в лейблах метрик передаются уникальные значения (например, полный URL запроса), Prometheus начинает потреблять гигабайты памяти. Решение: агрегируйте метрики на стороне exporter или используйте relabel_configs в Prometheus для удаления лишних лейблов. Для nginx-prometheus-exporter проблема редкая, но возникает при включении дополнительных модулей вроде VTS.
Неправильные единицы измерения. По умолчанию Grafana может показывать время ответа в секундах как миллисекунды. В настройках панели, вкладка Standard Options, явно задайте Unit: seconds (s). Для RPS выберите reqps. Для процентов - Percent (0-100).
Задержка в отображении. Prometheus по умолчанию скрейпит метрики раз в 15 секунд, Grafana запрашивает их с интервалом, заданным в дашборде. Суммарная задержка может достигать 30-40 секунд. Для оперативного мониторинга уменьшите scrape_interval до 5 секунд, но помните о росте нагрузки на Prometheus.
Заключение: дальнейшие шаги по мониторингу Nginx
Вы настроили сбор метрик, построили дашборд и подключили алерты. Теперь Nginx находится под контролем: любое отклонение RPS, времени ответа или рост ошибок сразу попадает в канал уведомлений. Базовая система мониторинга готова.
Следующий уровень - анализ логов. Настройте парсинг access.log и error.log в Loki или Elasticsearch, чтобы сопоставлять метрики с конкретными запросами. Добавьте трейсинг через OpenTelemetry для сквозного отслеживания запросов от пользователя до бэкенда. Если Nginx работает в Kubernetes, интегрируйте дашборд с метриками подов и сервисов - готовые решения есть в материале по оценке эффективности инфраструктуры. Проверьте дашборд в действии на реальной нагрузке и скорректируйте пороги алертов под паттерны вашего трафика.