Мониторинг Nginx в Zabbix: настройка шаблонов, триггеров и дашбордов

Nginx обрабатывает входящие соединения, раздает статику и балансирует трафик на бэкенды. Его падение или деградация мгновенно отражаются на пользователях. Zabbix дает единую точку контроля: вы видите состояние веб-сервера рядом с метриками CPU, памяти и дисковой подсистемы на одном экране. Эта инструкция проведет вас через четыре этапа: включение модуля status в Nginx, импорт готового шаблона в Zabbix, создание триггеров аварийных оповещений и построение дашбордов для визуального анализа. Все шаги проверены на актуальных версиях 2026 года.

К концу настройки вы получите работающую связку Nginx + Zabbix с автоматическими уведомлениями о недоступности сервера, росте ошибок 5xx и аномальном потреблении ресурсов. Если вам нужен альтернативный подход с Prometheus и Grafana, в базе знаний есть готовые конфиги и дашборды для мониторинга Nginx с алертингом на 502/504 ошибки.

Введение: зачем мониторить Nginx в Zabbix

Веб-сервер Nginx работает на границе инфраструктуры и принимает на себя весь входящий трафик. Без мониторинга вы узнаете о проблеме от пользователей, а не от системы оповещения. Zabbix решает эту задачу централизованно: один инструмент собирает метрики со всех уровней стека, от железа до приложения.

Пять метрик, которые необходимо отслеживать в первую очередь: активные соединения, количество запросов в секунду, доля ошибок 4xx и 5xx, время ответа upstream-серверов и утилизация воркеров. Эти показатели формируют базовый контур observability. Подробный разбор пороговых значений и сценариев диагностики есть в статье «Топ-5 ключевых метрик мониторинга Nginx» - используйте ее как шпаргалку при настройке алертов.

Архитектура решения проста: Nginx отдает внутреннюю статистику через endpoint /nginx_status, Zabbix опрашивает этот endpoint по HTTP, сохраняет данные в базу и проверяет условия триггеров. При отклонении метрик от нормы система отправляет уведомление через настроенный канал: email, Telegram, Slack. Дашборды собирают графики в единый экран для быстрой диагностики.

Шаг 1: Включение модуля status в Nginx

Zabbix получает метрики Nginx через HTTP-запросы к специальному location, который отдает статистику. За эту статистику отвечает модуль ngx_http_stub_status_module. Он не включен в некоторые минимальные сборки Nginx - это нужно проверить до начала настройки.

Проверка доступности модуля status

Выполните команду на сервере с Nginx:

nginx -V 2>&1 | grep -o with-http_stub_status_module

Если вывод пуст - модуль отсутствует. В этом случае пересоберите Nginx с флагом --with-http_stub_status_module или используйте Docker-образ, включающий модуль по умолчанию (официальный nginx:latest содержит stub_status). На облачных VDS от Timeweb Cloud предустановленные образы Nginx идут с модулем из коробки, что экономит время на сборку.

Для расширенного мониторинга в Nginx Plus доступен ngx_http_api_module, который отдает детальные метрики по зонам upstream, кешированию и сессиям. В open-source версии используйте stub_status - его данных достаточно для базового мониторинга.

Настройка location для сбора метрик

Добавьте в конфигурацию Nginx отдельный server-блок или location внутри существующего:

server {
    listen 127.0.0.1:8080;
    server_name localhost;

    location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        allow 192.168.1.100; # IP Zabbix-сервера
        deny all;
    }
}

Три важных момента. Первое: директива stub_status активирует отдачу статистики. Второе: правила allow/deny ограничивают доступ - без них метрики сможет запросить любой, кто достигнет порта. Третье: вынесите status на отдельный порт или служебный IP, чтобы не смешивать с пользовательским трафиком.

После изменения конфигурации проверьте синтаксис и перезагрузите Nginx:

nginx -t && nginx -s reload

Убедитесь, что endpoint отвечает. С Zabbix-сервера или прокси выполните:

curl http://192.168.1.10:8080/nginx_status

Ожидаемый вывод:

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

Три строки: активные соединения, суммарные счетчики accepted/handled/requests, состояние соединений по фазам чтения, записи и ожидания. Эти цифры станут источником данных для Zabbix.

Шаг 2: Импорт и настройка шаблона Nginx в Zabbix

Шаблон в Zabbix - это набор элементов данных, триггеров, графиков и правил обнаружения, упакованных в переиспользуемую сущность. Вместо ручного создания десятков элементов вы подключаете готовый шаблон к хосту и получаете мониторинг за минуты.

Где взять актуальный шаблон

Zabbix 6.0 LTS и новее поставляют встроенный шаблон «Template App Nginx by HTTP». Он использует HTTP-агент для опроса /nginx_status и не требует установки Zabbix-агента на сервер с Nginx. Путь в интерфейсе: Data collection → Templates → нажмите «Import» и выберите файл из официального репозитория git.zabbix.com, если шаблон отсутствует в вашей версии.

Проверьте совместимость: шаблоны для Zabbix 7.0 могут использовать макросы и функции, отсутствующие в 6.0. При импорте система предупредит о несоответствии версий. Для продуктивных сред используйте шаблон, соответствующий вашей мажорной версии Zabbix.

Привязка шаблона к узлу сети и настройка макросов

Создайте хост для Nginx или используйте существующий. Перейдите в Configuration → Hosts, выберите целевой хост и откройте вкладку Templates. Нажмите «Select» и добавьте «Template App Nginx by HTTP». После привязки перейдите на вкладку Macros и укажите:

{$NGINX.STUB_STATUS.HOST} - IP-адрес сервера с Nginx (например, 192.168.1.10)
{$NGINX.STUB_STATUS.PORT} - порт, на котором слушает location /nginx_status (например, 8080)
{$NGINX.STUB_STATUS.SCHEME} - http или https, в зависимости от конфигурации

Шаблон подставит эти макросы в URL опроса: {$NGINX.STUB_STATUS.SCHEME}://{$NGINX.STUB_STATUS.HOST}:{$NGINX.STUB_STATUS.PORT}/nginx_status. Через 60 секунд после сохранения проверьте поступление данных: Monitoring → Latest data, фильтр по хосту. Вы должны увидеть значения элементов nginx.status.active, nginx.status.accepts, nginx.status.handled, nginx.status.requests, nginx.status.reading, nginx.status.writing, nginx.status.waiting.

Если данные не поступают, проверьте сетевую доступность с Zabbix-сервера: curl http://192.168.1.10:8080/nginx_status. Убедитесь, что файрвол не блокирует порт 8080 между Zabbix-сервером и Nginx. В разделе «Типовые проблемы и их решение» разобраны остальные частые причины.

Шаг 3: Создание триггеров для аварийных оповещений

Триггер - это логическое выражение, которое вычисляется на основе собранных данных. Когда выражение становится истинным, Zabbix генерирует событие проблемы. Шаблон «Template App Nginx by HTTP» содержит базовые триггеры, но их стоит дополнить под реальные сценарии эксплуатации.

Примеры триггеров для типовых проблем Nginx

Триггер 1: Nginx не отвечает. Отсутствие данных за три минуты означает, что endpoint статистики недоступен - Nginx упал, порт закрыт файрволом или сервер выключен.

nodata(/Template App Nginx by HTTP/nginx.status.active,3m)=1

Выражение срабатывает, когда элемент nginx.status.active не получает новых значений в течение трех минут. Степень серьезности: High.

Триггер 2: Рост отброшенных соединений. Nginx принимает соединения (accepts), но не все обрабатывает (handled). Разница между accepts и handled указывает на перегрузку - сервер не успевает обслуживать входящий трафик.

(last(/Template App Nginx by HTTP/nginx.status.accepts) - last(/Template App Nginx by HTTP/nginx.status.handled)) / last(/Template App Nginx by HTTP/nginx.status.accepts) * 100 > 5

Порог 5% - эмпирическое значение. При стабильной работе разница близка к нулю. Степень серьезности: Warning.

Триггер 3: Аномальное падение трафика. Резкое снижение числа обработанных запросов может указывать на проблемы с upstream-серверами или сетевой связностью.

avg(/Template App Nginx by HTTP/nginx.status.requests,5m) / avg(/Template App Nginx by HTTP/nginx.status.requests,30m) * 100 < 30

Выражение сравнивает среднее количество запросов за 5 минут со средним за 30 минут. Падение ниже 30% от нормального уровня генерирует алерт. Степень серьезности: Average.

Для создания триггера перейдите в Configuration → Templates, выберите шаблон Nginx, откройте вкладку Triggers и нажмите «Create trigger». Заполните имя, выражение и степень серьезности. Вкладка «Tags» позволяет добавить метки для маршрутизации оповещений в разные каналы.

Настройка оповещений: Actions и уведомления

Триггер без действия - молчаливая запись в логе. Чтобы получать уведомления, настройте Actions: Configuration → Actions → Create action. В условиях укажите теги триггера или степень серьезности. В операциях добавьте отправку сообщения пользователям или группам через настроенные media types (Email, Telegram, Slack).

Предварительно настройте media types в Administration → Media types. Для Telegram потребуется токен бота и ID чата. Для email - SMTP-сервер и учетные данные. Протестируйте доставку: Administration → Media types → выберите тип → нажмите «Test».

Рекомендуется настроить эскалацию: если проблема не решена за 15 минут, отправляется повторное уведомление другой группе (например, дежурному инженеру второй линии). Это делается добавлением шагов в операцию действия с увеличивающейся задержкой.

Шаг 4: Визуализация метрик на дашбордах

Дашборд собирает ключевые графики на одном экране. Вместо переключения между разделами Latest data и Graphs вы видите состояние Nginx за секунду. Это критично при инцидентах, когда время на диагностику ограничено.

Ключевые виджеты для мониторинга Nginx

Минимальный набор виджетов для рабочего дашборда:

График «Active connections» - элемент nginx.status.active. Показывает текущую нагрузку. Резкий рост - повод проверить upstream-серверы на задержки. Настройте отдельные линии для reading, writing и waiting, чтобы видеть распределение соединений по фазам.
Счетчик «Requests per second» - вычисляемый элемент на основе nginx.status.requests с преобразованием в скорость (change per second). Интенсивность трафика в реальном времени.
График «Error rate» - требует дополнительного сбора логов Nginx или метрик из access.log. Показывает долю ответов 4xx и 5xx. Рост ошибок 5xx - критический инцидент, требующий немедленной реакции.
Gauge «Uptime» - время с последнего перезапуска Nginx. Полезно для корреляции с плановыми работами и выявления незапланированных рестартов.

Пример готового дашборда и его импорт

Создайте новый дашборд: Dashboards → Create dashboard. Добавьте виджеты через кнопку «Add widget». Для графика выберите тип «Graph», укажите элементы данных из шаблона Nginx и настройте временной интервал по умолчанию (1 час).

Готовый дашборд можно экспортировать в JSON и перенести между инсталляциями Zabbix. На странице дашборда нажмите «Share» → «Export». Для импорта используйте Dashboards → Import. Это экономит время при развертывании мониторинга на нескольких средах: настройте дашборд один раз на staging, экспортируйте и импортируйте на production.

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

Типовые проблемы и их решение

За пять лет работы с этой связкой я выделил три повторяющиеся проблемы, которые возникают у большинства администраторов при первой настройке. Решения проверены на десятках инсталляций.

Zabbix не видит метрики Nginx

Симптом: в Latest data элементы шаблона отображаются серым, без значений. Диагностика по цепочке:

С Zabbix-сервера выполните curl -v http://IP_NGINX:PORT/nginx_status. Если ответ не получен - проблема на сетевом уровне или в конфигурации Nginx.
Проверьте, что location /nginx_status содержит директиву stub_status и правила allow для IP Zabbix-сервера. Ошибка в порядке правил deny/allow - частая причина: deny all должно идти последним.
Убедитесь, что макросы шаблона {$NGINX.STUB_STATUS.HOST} и {$NGINX.STUB_STATUS.PORT} указывают на правильные IP и порт. Опечатка в IP - самая частая причина после файрвола.
Проверьте файрвол на сервере с Nginx: iptables -L -n | grep PORT или ufw status. Порт должен быть открыт для входящих соединений с IP Zabbix-сервера.

Триггеры срабатывают ложно или не срабатывают

Ложные срабатывания возникают из-за слишком чувствительных порогов или коротких интервалов усреднения. Используйте avg(5m) вместо last() для метрик, подверженных кратковременным всплескам. Настройте подходящий severity для каждого триггера - это позволит фильтровать неважные алерты на уровне действий.

Отсутствие срабатываний проверяйте через тестовые уведомления. В Administration → Media types выберите канал и нажмите «Test». Если тест проходит, а боевые уведомления не приходят - проверьте условия в Actions: возможно, триггер не попадает под фильтр по тегам или severity.

Для отладки выражений используйте встроенный тестер: Configuration → Hosts → выберите хост → откройте триггер → нажмите «Test». Вы увидите пошаговое вычисление выражения с реальными данными и поймете, на каком этапе условие не выполняется.

Заключение: итоги и дальнейшие шаги

Вы настроили четыре компонента мониторинга Nginx в Zabbix: модуль stub_status отдает метрики по HTTP, шаблон собирает их без агента, триггеры генерируют алерты при отклонениях, дашборд визуализирует состояние в реальном времени. Эта связка закрывает базовый мониторинг и занимает 20-30 минут при первом развертывании.

Следующий уровень - мониторинг upstream-серверов. Когда Nginx балансирует трафик на несколько бэкендов, необходимо отслеживать доступность и время ответа каждого. В статье «Мониторинг Nginx Upstream: Health Checks, метрики и визуализация» разобрана настройка проверок здоровья и сбор метрик по каждому серверу пула.

Для высоконагруженных систем рассмотрите интеграцию с Grafana через плагин Zabbix. Это дает гибкость визуализации и возможность объединить метрики из разных источников на одном дашборде. Руководство «Наблюдаемость для высоконагруженных систем в 2026» содержит готовые шаблоны алертов и дашбордов для SRE-практик.

Если вы строите мониторинг с нуля и нуждаетесь в облачной инфраструктуре, Timeweb Cloud предоставляет VDS с предустановленными шаблонами Nginx и Zabbix. Это сокращает время развертывания с часов до минут.