Мониторинг логов Nginx: ключевые команды для анализа веб-трафика и ошибок

Мониторинг логов Nginx часто является самым быстрым способом ответить на вопрос, который задают во время инцидента: "Что на самом деле происходит прямо сейчас?". Метрики могут сказать, что количество ошибок 5xx возросло. Логи могут показать путь, апстрим, код состояния, IP-адрес клиента и временные характеристики для запросов, которые завершились ошибкой.

Команды, приведенные здесь, используют обычные инструменты Linux: tail, grep, awk, sort, uniq, less и их варианты для сжатых логов. Они не заменяют полноценную платформу для работы с логами, но это именно то, что нужно, когда у вас есть SSH-доступ к серверу и требуется быстрый и обоснованный ответ.

Понимание типов логов Nginx

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

Логи доступа (access.log): Записывают каждый запрос, обработанный сервером. Этот журнал жизненно важен для понимания поведения пользователей, объема трафика, географического распределения и времени ответа. По умолчанию поля часто включают IP-адрес, метод запроса, URI, HTTP-статус, размер запроса и user agent.
Логи ошибок (error.log): Записывают диагностическую информацию, предупреждения и критические ошибки, с которыми сталкивается сам Nginx (например, проблемы с конфигурацией, таймауты апстримов, исчерпание ресурсов). Этот журнал является первым местом для поиска неисправностей на стороне сервера.

Стандартные расположения логов

Хотя расположение можно настроить, логи Nginx обычно находятся в следующих каталогах в большинстве дистрибутивов:

Тип дистрибутива	Путь к логам по умолчанию
Debian/Ubuntu	`/var/log/nginx/`
RHEL/CentOS	`/var/log/nginx/`
Пользовательская установка (из исходников)	Различается, проверьте `nginx.conf`

В качестве основных примеров мы будем использовать /var/log/nginx/access.log и /var/log/nginx/error.log.

1. Мониторинг в реальном времени с помощью `tail`

Команда tail необходима для наблюдения за текущей активностью сервера по мере ее возникновения. Флаг -f (follow) обеспечивает прокрутку вывода в реальном времени.

Мониторинг живого трафика доступа

Чтобы просматривать новые запросы, поступающие на сервер, используйте tail -f для лога доступа:

tail -f /var/log/nginx/access.log

Одновременный мониторинг ошибок

Часто полезно отслеживать ошибки во время тестирования изменений конфигурации или развертываний. Это можно сделать, запустив два отдельных сеанса терминала или используя такой инструмент, как multitail (если он установлен):

tail -f /var/log/nginx/error.log

Совет: Если вам нужно увидеть последние 100 строк перед отслеживанием новых записей, используйте tail -n 100 -f /var/log/nginx/access.log.

2. Поиск и фильтрация с помощью `grep`

grep (Global Regular Expression Print) является рабочей лошадкой для поиска конкретных строк в файлах логов. Он позволяет быстро фильтровать логи по кодам состояния, IP-адресам, методам и т.д.

Поиск конкретных HTTP-статусов

При устранении неполадок критически важно быстро идентифицировать все запросы, которые привели к определенной ошибке. Мы используем пробелы вокруг кода состояния, чтобы избежать ложных срабатываний от похожих чисел (например, чтобы не сопоставить 200 в 2000).

Найти все ошибки 404 (Не найдено):

grep " 404 " /var/log/nginx/access.log

Найти все серверные ошибки 5xx:

grep -E " 50[0-9] " /var/log/nginx/access.log

Фильтрация по пути запроса или IP-адресу

Чтобы увидеть все запросы, сделанные с определенного IP-адреса клиента, или все попытки доступа к определенному пути (например, /admin):

# Фильтрация по IP-адресу клиента
grep "192.168.1.10" /var/log/nginx/access.log

# Фильтрация попыток доступа к определенному URL
grep "/wp-login.php" /var/log/nginx/access.log

Фильтрация в реальном времени

Вы можете передать вывод tail -f в grep, чтобы отслеживать только определенные события по мере их возникновения:

# Прямой эфир только ошибок 5xx
tail -f /var/log/nginx/access.log | grep -E " 50[0-9] "

3. Работа с большими и ротированными логами

Файлы логов могут быстро стать огромными. Nginx обычно использует утилиты ротации логов (logrotate) для сжатия старых логов с помощью gzip.

Просмотр больших файлов с помощью `less`

Вместо загрузки всего файла в память (что может привести к сбою сеанса терминала) используйте less для постраничного просмотра. less также позволяет перемещаться назад и эффективно искать.

less /var/log/nginx/access.log
# Внутри less нажмите 'G', чтобы перейти в конец, 'g' - в начало, и '/' - для поиска.

Поиск в сжатых логах с помощью `zgrep`

Для поиска в ротированных логах (файлы .gz) без ручной распаковки используйте варианты z распространенных команд (zcat, zgrep).

# Поиск ошибки 403 в сжатом файле лога
zgrep " 403 " /var/log/nginx/access.log.1.gz

4. Структурированный анализ с помощью `awk`, `cut` и `sort`

Логи Nginx, особенно использующие стандартный комбинированный формат, структурированы пробелами. Эта структура позволяет таким инструментам, как awk и cut, извлекать определенные поля данных для статистического анализа.

В стандартном комбинированном формате ключевыми полями обычно являются:

$1: Удаленный IP-адрес
$7: Запрошенный URI
$9: HTTP-статус
$10: Отправлено байт
$12: HTTP Referer
$14: User Agent

Поиск наиболее запрашиваемых страниц

Этот конвейер использует awk для извлечения URI ($7), sort для группировки одинаковых записей, uniq -c для их подсчета и sort -nr для их числового отображения в обратном порядке (сначала с наибольшим количеством).

awk '{print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr | head -10

Подсчет кодов состояния

Чтобы быстро получить разбивку всех кодов состояния, записанных в логе:

awk '{print $9}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr

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

Выявление запросов с высокой задержкой (если логируются)

Если ваша конфигурация Nginx логирует время ответа апстрима ($upstream_response_time), вы можете использовать awk для поиска медленных запросов (например, медленнее 1 секунды).

Примечание: Предполагается, что время ответа находится в 12-м поле ($12). Проверьте вашу конфигурацию log_format, прежде чем доверять номеру поля.

awk '($12 > 1.0) {print $12, $7}' /var/log/nginx/access.log | sort -nr

Лучшие практики анализа логов

Используйте `grep -v` для исключения

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

# Просмотр логов доступа, исключая все успешные ответы 200
grep -v " 200 " /var/log/nginx/access.log

# Просмотр логов, исключая известные user agent'ы Googlebot
grep -v "Googlebot" /var/log/nginx/access.log

Сравнивайте логи доступа с логами ошибок

Когда вы видите всплеск ответов 502 или 504, проверьте лог ошибок за тот же временной промежуток. Логи доступа показывают результат, видимый клиенту. Логи ошибок часто объясняют причину на стороне прокси:

grep "upstream" /var/log/nginx/error.log | tail -50
grep -E "connect\(\) failed|upstream timed out|no live upstreams" /var/log/nginx/error.log

Например, 502 в логе доступа вместе с connect() failed (111: Connection refused) в логе ошибок указывает на сервис апстрима, который не принимает соединения. 504 вместе с upstream timed out указывает на медленный апстрим или слишком низкое значение таймаута для этого пути запроса.

Будьте осторожны с номерами полей

Многие примеры предполагают комбинированный формат лога Nginx. В реальных производственных конфигурациях часто добавляются $request_time, $upstream_response_time, $host, $request_id или поля с пересылаемыми IP-адресами. Перед использованием команды awk '{print $9}' в серьезном расследовании проверьте активный формат:

nginx -T 2>/dev/null | grep -A3 "log_format"

Если ваш формат лога заключает запрос в кавычки, разделенные пробелами поля awk все еще работают для простых проверок, но их легко неправильно интерпретировать для user agent'ов и рефереров, поскольку эти значения содержат пробелы. Для более глубокого анализа отправляйте логи в парсер или используйте такой формат, как экранирование JSON в выделенном логе доступа.

Безопасная обработка

Логи доступа Nginx содержат конфиденциальные данные, такие как IP-адреса и, возможно, параметры запроса. Убедитесь, что при передаче логов для анализа вы используете защищенные протоколы (SCP/SFTP) и ограничиваете доступ к каталогу логов только уполномоченным лицам (обычно пользователю root или syslog).

# Проверка прав доступа
ls -l /var/log/nginx/

Практический рабочий процесс

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

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Затем переходите от общего к частному: код состояния, путь, ошибка апстрима, временное окно, шаблон клиента. Сохраняйте точные команды, которые вы использовали, в заметках об инциденте. Это значительно упростит следующий анализ и поможет другому инженеру воспроизвести ваши выводы, вместо того чтобы полагаться на смутные воспоминания о том, как "выглядели" логи.

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