Nginx: практический мониторинг, анализ логов и отладка ошибок | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Nginx: практический мониторинг, анализ логов и отладка ошибок

03 мая 2026 9 мин. чтения
Содержание статьи

Эффективный мониторинг и анализ логов Nginx - это основа стабильной работы любого веб-сервиса. Без правильной настройки вы узнаете о проблемах от пользователей, а не из систем оповещения. Эта статья дает пошаговый план для построения полного цикла мониторинга: от конфигурации структурированных логов до диагностики ошибок и настройки алертинга в Telegram или Slack. Вы научитесь интегрировать Nginx с Prometheus через nginx_exporter, визуализировать метрики в Grafana и быстро находить корень проблем по кодам ответа 502, 504 или 413.

Фундамент: настройка структурированных логов для эффективного анализа

Правильный формат логов экономит часы на их последующем анализе. Сырые, неструктурированные логи сложно парсить автоматически, что замедляет реакцию на инциденты. Начните с конфигурации, которая сразу готовит данные для систем типа ELK или простых скриптов на awk и grep.

Оптимальный формат access лога для парсинга и стека ELK

Используйте формат, который включает ключевые метрики производительности и удобен для машинной обработки. JSON-формат стал стандартом для интеграции с современными системами.

Добавьте в конфигурацию Nginx (обычно в секцию http файла nginx.conf) следующий блок:

log_format json_combined escape=json
  '{'
    '"timestamp":"$time_iso8601",'
    '"remote_addr":"$remote_addr",'
    '"remote_user":"$remote_user",'
    '"request":"$request",'
    '"status":"$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"request_time":"$request_time",'
    '"upstream_response_time":"$upstream_response_time",'
    '"upstream_addr":"$upstream_addr",'
    '"http_referer":"$http_referer",'
    '"http_user_agent":"$http_user_agent"'
  '}';

access_log /var/log/nginx/access.log json_combined;

Ключевые поля этого формата:

  • $request_time - общее время обработки запроса на стороне Nginx.
  • $upstream_response_time - время, затраченное бэкендом на формирование ответа. Разница между этим значением и $request_time указывает на накладные расходы самого Nginx.
  • $status - код HTTP-ответа (200, 404, 502 и т.д.).
  • $body_bytes_sent - объем переданных данных.

JSON-формат упрощает загрузку логов в Elasticsearch или Loki. Для традиционного парсинга утилитами командной строки подойдет структурированный текстовый формат. Пример команды для поиска запросов, обрабатывавшихся дольше 5 секунд: grep '"request_time":"[5-9]\|1[0-9]' /var/log/nginx/access.log | head -20.

Настройка error лога и управление уровнем детализации

Error-логи Nginx требуют баланса между информативностью и объемом. Уровень логирования по умолчанию error часто недостаточен для отладки, а уровень debug генерирует огромные объемы данных.

Настройте раздельное логирование для разных виртуальных хостов и контекстов:

# В основном конфиге nginx.conf
error_log /var/log/nginx/error.log warn;

# Внутри блока server для конкретного хоста
server {
    listen 80;
    server_name api.example.com;
    error_log /var/log/nginx/api.error.log info;
    ...
}

Уровни логирования (debug, info, warn, error, crit) определяют детализацию. Для продакшена начните с warn, а для отладки проблем на staging переключите на info. Критически важно настроить ротацию логов, чтобы они не заполнили диск. Используйте стандартный logrotate. Пример конфигурации /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

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

Сбор метрик в реальном времени: интеграция Nginx с Prometheus через nginx_exporter

Логи дают историческую картину, но для оперативного реагирования нужны метрики в реальном времени. nginx_exporter - это стандартный способ вытащить внутренние метрики Nginx в формат, понятный Prometheus.

Установка и базовая конфигурация nginx_exporter

Самый быстрый способ запуска - использовать Docker или готовый бинарный файл. Для production-среды рекомендуется настраивать через systemd.

Установка из бинарного релиза:

# Скачайте последнюю версию (актуально на май 2026)
wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v0.11.0/nginx-prometheus-exporter_0.11.0_linux_amd64.tar.gz
# Распакуйте и переместите бинарник
sudo mv nginx-prometheus-exporter /usr/local/bin/

Создание systemd-сервиса: Создайте файл /etc/systemd/system/nginx-exporter.service.

[Unit]
Description=NGINX Prometheus Exporter
After=network.target

[Service]
Type=simple
User=nobody
ExecStart=/usr/local/bin/nginx-prometheus-exporter \
    -nginx.scrape-uri=http://localhost:8080/stub_status
Restart=on-failure

[Install]
WantedBy=multi-user.target

Запустите и активируйте сервис:

sudo systemctl daemon-reload
sudo systemctl start nginx-exporter
sudo systemctl enable nginx-exporter

Проверьте работу экспортера, запросив метрики: curl http://localhost:9113/metrics. В ответе вы должны увидеть метрики с префиксом nginx_.

Настройка Nginx для отдачи метрик (stub_status)

Экспортер получает данные со status-страницы Nginx. Модуль stub_status должен быть собран в вашей версии Nginx (он есть в стандартных сборках).

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

server {
    listen 8080; # Отдельный порт для метрик
    server_name localhost;
    location /stub_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1; # Разрешаем только localhost
        deny all;
    }
}

Проверьте доступность статуса: curl http://localhost:8080/stub_status. Ответ должен содержать строки Active connections, requests и соединения в состояниях reading, writing, waiting.

Добавление цели в Prometheus и проверка сбора данных

Теперь нужно указать Prometheus, откуда собирать метрики. В файле конфигурации Prometheus prometheus.yml в секцию scrape_configs добавьте новую задачу.

scrape_configs:
  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']
        labels:
          instance: 'nginx-production'
          role: 'webserver'
    scrape_interval: 15s

Перезагрузите конфигурацию Prometheus (или перезапустите сервис) и проверьте, что цель появилась в статусе UP в веб-интерфейсе Prometheus (http://your-prometheus:9090/targets). Выполните запрос nginx_connections_total в графане Prometheus, чтобы убедиться в сборе данных.

Визуализация и дашборды: создание единой картины в Grafana

Собранные метрики нужно превратить в наглядные графики для быстрой оценки состояния. Grafana - стандартный инструмент для этой задачи.

Импорт готового дашборда для nginx_exporter

Не создавайте дашборд с нуля, если есть проверенные сообществом варианты. Перейдите на grafana.com/grafana/dashboards и найдите дашборд по ID, например, 12708 (NGINX Exporter Full).

В интерфейсе Grafana выберите Create → Import, введите ID дашборда и нажмите Load. Выберите источник данных Prometheus, созданный на предыдущем шаге. После импорта дашборд автоматически заполнится графиками, использующими метрики nginx_*.

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

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

  • Requests per Second (RPS): График метрики rate(nginx_http_requests_total[1m]). Резкий спад может означать проблемы с сетью или приложением, резкий рост - DDoS-атаку.
  • Active Connections: Разбейте на три графика: nginx_connections_reading, nginx_connections_writing, nginx_connections_waiting. Большое количество соединений в состоянии waiting часто указывает на медленные бэкенды.
  • HTTP Status Codes: Используйте запросы типа sum(rate(nginx_http_requests_total{status=~"5.*"}[5m])) для отслеживания доли 5xx ошибок. Установите порог (например, 5%) и цветовую индикацию.
  • Request/Upstream Time: График перцентилей (p95, p99) для метрик nginx_http_request_duration_seconds и nginx_upstream_response_duration_seconds. Помогает выявить деградацию производительности, незаметную по средним значениям.

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

Практическая диагностика: находим и исправляем типичные ошибки Nginx

Когда в Grafana появляется всплеск ошибок, алгоритм диагностики должен быть четким. Рассмотрим три частые ошибки.

502 Bad Gateway: бэкенд недоступен или отвечает с ошибкой

Ошибка 502 означает, что Nginx не смог получить корректный ответ от upstream-сервера (бэкенда).

Чек-лист диагностики:

  1. Проверьте логи бэкенда: Убедитесь, что само приложение запущено и слушает указанный в proxy_pass порт. Ищите ошибки запуска или падения в его логах.
  2. Проверьте сетевую доступность: Выполните с сервера Nginx команду telnet <backend_ip> <backend_port> или curl -v http://<backend_ip>:<backend_port>/health.
  3. Проанализируйте error-лог Nginx: Ищите записи с текстом connect() failed (111: Connection refused) или upstream prematurely closed connection.
  4. Проверьте таймауты в конфиге Nginx: Убедитесь, что директивы proxy_connect_timeout, proxy_read_timeout заданы адекватно (например, 30s). Слишком малые значения могут обрывать нормальные, но медленные соединения.

Пример корректной настройки upstream с резервным сервером и health check можно найти в нашей статье про продвинутую настройку балансировщика нагрузки Nginx.

504 Gateway Timeout: превышены таймауты ожидания ответа

Ошибка 504 говорит, что бэкенд работает, но не уложился в отведенное время. Это проблема производительности.

Алгоритм действий:

  1. Анализ метрик upstream_response_time: В Grafana изучите график перцентилей p95 и p99 для метрики nginx_upstream_response_duration_seconds. Сравните с настройкой proxy_read_timeout.
  2. Настройка keepalive для upstream: Добавьте в блок upstream директивы для поддержания соединений с бэкендом, чтобы избежать накладных расходов на установку TCP-соединения для каждого запроса. 
    upstream backend {
    server 10.0.1.10:8080;
    keepalive 32;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}
  3. Диагностика бэкенда: Проверьте логи приложения на предмет медленных SQL-запросов, внешних API-вызовов или нехватки ресурсов (CPU, память).

413 Request Entity Too Large: ограничение на размер загружаемых данных

Эта ошибка возникает при попытке загрузить файл, размер которого превышает лимит, заданный директивой client_max_body_size.

Решение: Увеличьте лимит в соответствующем контексте (http, server, location). Для API, принимающего большие файлы, настройка может выглядеть так:

location /api/upload {
    client_max_body_size 100M;
    proxy_pass http://backend;
    ...
}

Убедитесь, что аналогичный лимит настроен и в самом бэкенд-приложении (например, в настройках веб-фреймворка или приложения в Docker). Если вы работаете с контейнерами, детали диагностики ошибок 4xx в этом стеке описаны в руководстве по диагностике ошибок 401 и 403 в Nginx, Docker и Kubernetes.

Для анализа паттернов в логах, которые могут указывать на попытки атак или сканирования, используйте готовые команды из статьи Практический анализ логов Nginx и Apache.

Алертинг: настраиваем уведомления о критических событиях

Мониторинг без алертинга - это просто исторический архив. Настройте автоматические уведомления, чтобы узнавать о проблемах первыми.

Создание правил алертинга в Prometheus

Создайте файл /etc/prometheus/nginx_alerts.yml с правилами. Подключите его в prometheus.yml через директиву rule_files.

groups:
  - name: nginx_alerts
    rules:
    - alert: NginxHigh5xxErrorRate
      expr: sum(rate(nginx_http_requests_total{status=~"5.*"}[5m])) / sum(rate(nginx_http_requests_total[5m])) > 0.05
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: "Высокий уровень 5xx ошибок в Nginx"
        description: "{{ $labels.instance }}: Доля 5xx ошибок составляет {{ $value | humanizePercentage }}."

    - alert: NginxExporterDown
      expr: up{job="nginx"} == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Nginx экспортер недоступен"
        description: "{{ $labels.instance }} экспортер не отдает метрики более 1 минуты."

    - alert: NginxHighResponseTime
      expr: histogram_quantile(0.95, rate(nginx_http_request_duration_seconds_bucket[5m])) > 1
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Высокое время ответа Nginx"
        description: "{{ $labels.instance }}: 95-й перцентиль времени ответа превышает 1 секунду ({{ $value }}s)."

Маршрутизация и отправка уведомлений через Alertmanager

Alertmanager получает алерты от Prometheus и отправляет их по заданным каналам. Базовая конфигурация для отправки в Telegram через бота.

Пример конфигурации Alertmanager alertmanager.yml:

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'telegram-notifications'

receivers:
- name: 'telegram-notifications'
  telegram_configs:
  - bot_token: 'YOUR_BOT_TOKEN'
    chat_id: YOUR_CHAT_ID
    send_resolved: true
    message: '{{ range .Alerts }}[{{ .Status | toUpper }}] {{ .Labels.severity | upper }}: {{ .Annotations.summary }}\n{{ .Annotations.description }}\n{{ end }}'

После настройки перезапустите Alertmanager. При срабатывании условия, описанного в правилах Prometheus, вы получите сообщение в Telegram.

Резюме и рекомендации по безопасному внедрению

Вы прошли полный путь настройки мониторинга для Nginx: от конфигурации структурированных логов до развертывания алертинга. Ключевые шаги: настройка JSON-формата логов, установка nginx_exporter, добавление источника данных в Prometheus, импорт дашборда в Grafana и создание правил для Alertmanager.

Перед внедрением в production соблюдайте меры безопасности:

  1. Тестируйте в staging-среде. Все изменения в конфигурации Nginx и правила алертинга сначала проверяйте на нерабочем сервере.
  2. Создавайте бэкапы конфигов. Перед правкой nginx.conf сделайте копию. Используйте систему контроля версий (Git) для хранения конфигураций мониторинга.
  3. Ограничивайте доступ к метрикам. Страница /stub_status и порт экспортера (9113) должны быть доступны только с localhost или доверенных IP-адресов через firewall.
  4. Начинайте с малого. Внедрите сначала сбор базовых метрик и алерт на недоступность экспортера. По мере необходимости добавляйте сложные правила на основе перцентилей времени ответа.

Для тонкой настройки производительности Nginx под высокие нагрузки, включая расчет worker_processes и оптимизацию keepalive, используйте готовые конфигурации из нашего гайда по оптимизации Nginx.

Используйте агрегатор AiTunnel для доступа к более чем 200 моделям ИИ, включая GPT и Claude, через единый API. Это упрощает автоматизацию анализа логов или генерации отчетов на основе собранных метрик без необходимости настройки VPN и управления множеством ключей.

Официальная документация, на которую стоит опираться для углубленного изучения: документация Nginx, nginx-prometheus-exporter, Prometheus Alerting Rules.

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