Настройка ведения журнала Nginx и поиск ошибок
Общие сведения
Рекомендуется создавать отдельный файл журнала доступа для каждого серверного блока
error — ошибки при обработке запроса
crit — критические проблемы
debug — debug сообщения
info — Информационные сообщения
notice — Уведомления
warn — Предупреждения
alert — Оповещения. Должно быть исправлено немедленно.
emerg — Система находится в непригодном для использования состоянии.
По умолчанию все уровни логов записываются в один журнал
Приведенная ниже конфигурация изменяет минимальный уровень серьезности сообщений об ошибках для входа с ошибки на предупреждение:
error_log logs/error.log warn;
Директива error_log также может быть указана на уровнях http, stream, server и location и переопределяет настройку, унаследованную от более высоких уровней. В случае ошибки сообщение записывается только в один журнал ошибок, ближайший к уровню, на котором произошла ошибка.
Чтобы переопределить настройку по умолчанию, используется директива log_format
Для изменения формата протоколируемых сообщений, а также директиву access_log для указания местоположения журнала и его формата.
В примере определяется формат журнала, который расширяет предопределенный комбинированный формат со значением, указывающим степень сжатия ответа в формате gzip
http {
log_format compression '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
server {
gzip on;
access_log /spool/logs/nginx-access.log compression;
...
}
}
Другой пример позволяет отслеживать различные значения времени между NGINX и вышестоящим сервером.
Можно использовать следующие переменные для регистрации значений времени:
$upstream_connect_time – Время, затраченное на установление соединения с вышестоящим сервером
$upstream_header_time – Время между установлением соединения и получением первого байта заголовка ответа от вышестоящего сервера
$upstream_response_time – Время между установлением соединения и получением последнего байта тела ответа от вышестоящего сервера
$request_time – Общее время, затраченное на обработку запроса
Все значения времени измеряются в секундах с разрешением в миллисекунду.
log_format upstream_time '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"'
'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';
Когда запрос обрабатывается через несколько серверов, переменная содержит несколько значений, разделенных запятыми
При внутреннем перенаправлении из одной вышестоящей группы в другую значения разделяются точкой с запятой
Когда запрос не может достичь вышестоящего сервера или не может быть получен полный заголовок, переменная содержит 0 (ноль)
В случае внутренней ошибки при подключении к восходящему потоку или при получении ответа из кэша переменная содержит - (дефис)
Чтобы включить кэширование дескрипторов файлов журнала, используется директива open_log_file_cache.
Когда обработка запроса завершена, сообщение записывается в журнал, который настроен на текущем уровне или унаследован от предыдущих уровней. Если один уровень определяет несколько журналов доступа, сообщение записывается во все из них.
Выборка параметров TLS
В этом примере каждый клиент идентифицируется по его уникальной комбинации IP-адреса и пользовательского агента.
В примере определяется пользовательский формат журнала sslparams
$ssl_cipher - шифры, используемые в соединении
$remote_addr - IP-адрес клиента $remote_addr
$http_user_agent - значение стандартного поля HTTP-запроса агента пользователя
log_format sslparams '$ssl_protocol $ssl_cipher '
'$remote_addr "$http_user_agent"';
server {
listen 443 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
if ($seen = "") {
set $seen 1;
set $logme 1;
}
access_log /tmp/sslparams.log sslparams if=$logme;
# ...
}
Сообщения системного журнала могут быть отправлены на сервер, который может быть доменным именем, IP-адресом или путем к сокету UNIX-домена:
error_log syslog:server=unix:/var/log/nginx.sock debug;
В примере сообщения журнала ошибок NGINX записываются в сокет домена UNIX на уровне ведения журнала отладки, а журнал доступа записывается на сервер системного журнала с IPv6-адресом и портом 1234.
Параметр facility= указывает тип программы, которая регистрирует сообщение, другие возможные значения: auth, authpriv, daemon, cron, ftp, lpr, kern, почта, новости, системный журнал, пользователь, uucp, local0 ...
Параметр tag= применяет пользовательский тег к сообщениям системного журнала (nginx в нашем примере).
Debug
Чтобы запустить nginx в режиме debug:
service nginx stop && service nginx-debug start
Чтобы включить отладку в NGINX с открытым исходным кодом, вам нужно будет перекомпилировать его с помощью флага --with-debug, указанного в скрипте configure
nginx -V 2>&1 | grep arguments
./configure --with-debug
sudo make
sudo make install
Журнал отладки записывает ошибки и любую информацию, связанную с отладкой, и по умолчанию отключен.
Чтобы включить его, убедитесь, что NGINX скомпилирован для поддержки отладки
Журнал отладки может быть записан в файл, выделенный буфер в памяти, вывод stderr или в системный журнал
Рекомендуется включить журнал отладки на ”main“ уровне конфигурации NGINX, чтобы получить полную картину происходящего
Чтобы уменьшить негативное влияние, вы можете настроить запись журнала отладки в буфер памяти или настроить журнал отладки для определенных IP-адресов.
Найдите директиву error_log, которая по умолчанию находится в основном контексте, и измените уровень ведения журнала на debug. При необходимости измените путь к файлу журнала:
sudo vi /etc/nginx/nginx.conf
Включение отладки
Чтобы включить режим отладки, убедиться, что NGINX скомпилирован для поддержки отладки, а затем включите его в файле конфигурации NGINX с параметром debug директивы error_log.
Для этого необходимо найти директиву error_log, которая по умолчанию находится в основном контексте, и изменить уровень ведения журнала на debug. При необходимости измените путь к файлу журнала:
error_log /var/log/nginx/error.log debug;
Журнал отладки может быть записан в файл, выделенный буфер в памяти, вывод stderr или в системный журнал.
Рекомендуется включить журнал отладки на ”основном“ уровне конфигурации NGINX, чтобы получить полную картину происходящего.
Можно настроить запись журнала отладки в буфер памяти или настроить журнал отладки для определенных IP-адресов
Журнал отладки для выбранных IP-адресов
error_log /path/to/log;
...
events {
debug_connection 192.168.1.1;
debug_connection 192.168.10.0/24;
}
Чтобы настроить журнал отладки для конкретного виртуального хоста, добавьте директиву error_log внутри определенного серверного блока, в которой задайте новый путь к файлу журнала и уровень ведения журнала отладки:
http {
...
server {
error_log /path2/to/log debug;
...
}
}
Источники
Связанные темы
Оптимизация производительности
Настройка виртуального сервера Nginx