Как настроить ведение журнала и ротацию журналов в Nginx на Ubuntu VPS

Введение

Чтобы избавить себя от проблем с веб-сервером, вы можете настроить ведение журнала. Регистрация информации на вашем сервере дает вам доступ к данным, которые помогут вам устранять неполадки и оценивать ситуации по мере их возникновения.

В этом руководстве вы изучите возможности ведения журналов Nginx и узнаете, как настроить эти инструменты в соответствии с вашими потребностями. В качестве примера вы будете использовать виртуальный частный сервер Ubuntu 22.04, но любой современный дистрибутив должен работать аналогично.

Предпосылки

Чтобы следовать этому руководству, вам понадобятся:

• Один сервер Ubuntu 22.04 с пользователем без полномочий root с поддержкой sudo и брандмауэром. Чтобы начать работу, выполните нашу начальную настройку сервера.
• Nginx установлен на сервере. Следуйте нашему руководству по установке Nginx в Ubuntu 22.04, чтобы установить его.

Когда Nginx работает на вашем сервере Ubuntu 22.04, вы готовы начать.

Понимание директивы Error_log

Nginx использует несколько различных директив для управления журналированием системы. Тот, который включен в основной модуль, называется error_log.

error_log Синтаксис

Директива error_log используется для обработки общих сообщений об ошибках. Если вы знакомы с Apache, это очень похоже на директиву Apache ErrorLog.

Директива error_log использует следующий синтаксис:

error_log log_file log_level

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

Уровни ведения журнала

Директиву error_log можно настроить для записи большего или меньшего количества информации по мере необходимости. Уровень ведения журнала может быть любым из следующих:

• emerg: аварийные ситуации, когда система находится в непригодном для использования состоянии.
• оповещение: серьезные ситуации, требующие оперативных действий.
• crit: важные проблемы, требующие решения.
• ошибка: Произошла ошибка, и что-то не удалось.
• warn: произошло что-то необычное, но это не повод для беспокойства.
• уведомление: что-то нормальное, но стоит отметить, что произошло.
• info: информационное сообщение, которое было бы неплохо узнать.
• debug: информация об отладке, которая может быть полезна для определения места возникновения проблемы.

Уровни, расположенные выше в списке, считаются более приоритетными. Если вы укажете уровень, журнал зафиксирует этот уровень и любой уровень выше указанного.

Например, если вы укажете error, журнал будет фиксировать сообщения с пометками error, crit, alert и <появление.

Пример использования этой директивы находится внутри основного файла конфигурации. Используйте предпочитаемый текстовый редактор для доступа к следующему файлу конфигурации. В этом примере используется nano:

sudo nano /etc/nginx/nginx.conf

Прокрутите файл до раздела # Logging Settings и обратите внимание на следующие директивы:

. . .
##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
. . .

Если вы не хотите, чтобы error_log что-либо регистрировал, вы должны отправить вывод в /dev/null:

. . .
error_log /dev/null crit;
. . .

Другая директива ведения журнала, access_log, будет обсуждаться в следующем разделе.

Понимание директив ведения журнала HttpLogModule

В то время как директива error_log является частью основного модуля, директива access_log является частью HttpLogModule. Это дает возможность настраивать журналы.

В этот модуль включено несколько других директив, которые помогают настраивать пользовательские журналы.

log_format Директива

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

Существует один формат, предопределенный Nginx, который называется combined. Это общий формат, используемый многими серверами.

Ниже приведен пример комбинированного формата, если он не был определен внутренне и его необходимо указать с помощью директивы log_format:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Это определение охватывает несколько строк, пока не найдет точку с запятой (;).

Строки, начинающиеся со знака доллара ($), обозначают переменные, а такие символы, как -, [ и ] интерпретируются буквально.

Общий синтаксис директивы:

log_format format_name string_describing_formatting;

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

Понимание директивы access_log

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

Директива access_log использует следующий синтаксис:

access_log /path/to/log/location [ format_of_log buffer_size ];

Значением по умолчанию для access_log является формат combined, упомянутый в разделе log_format. Вы можете использовать любой формат, определенный определением log_format.

Размер буфера — это максимальный размер данных, которые Nginx будет хранить до того, как запишет все это в журнал. Вы также можете указать сжатие файла журнала, добавив gzip в определение:

access_log /path/to/log/location format_of_log gzip;

В отличие от директивы error_log, если вы не хотите вести журнал, вы можете отключить его, обновив его в файле конфигурации:

. . .
##
# Logging Settings
##

access_log off;
error_log /var/log/nginx/error.log;

. . .

В этом случае нет необходимости писать в /dev/null.

Управление ротацией журналов

По мере роста файлов журналов становится необходимым управлять механизмами ведения журналов, чтобы не занимать место на диске. Ротация журналов – это процесс переключения файлов журналов и, возможно, архивирования старых файлов на определенный период времени.

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

Ротация журнала вручную

Чтобы вручную чередовать журналы, вы можете создать скрипт для их ротации. Например, переместите текущий журнал в новый файл для архивации. Обычная схема заключается в том, чтобы назвать самый последний файл журнала с суффиксом .0, а затем назвать более старые файлы с помощью .1 и т. д.:

mv /path/to/access.log /path/to/access.log.0

Команда, которая на самом деле меняет журналы, называется kill -USR1 /var/run/nginx.pid. Это не убивает процесс Nginx, а вместо этого отправляет ему сигнал, заставляющий перезагрузить файлы журнала. Это приведет к регистрации новых запросов в обновленном файле журнала:

kill -USR1 `cat /var/run/nginx.pid`

В файле /var/run/nginx.pid Nginx хранит PID главного процесса. Он указывается в верхней части файла конфигурации /etc/nginx/nginx.conf строкой, начинающейся с pid:

sudo nano /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
...

После ротации выполните sleep 1, чтобы позволить процессу завершить передачу. Затем вы можете заархивировать старые файлы или выполнить любые процессы после ротации, которые вам нравятся:

sleep 1
[ post-rotation processing of old log file ]

Ротация логов с помощью logrotate

Приложение logrotate — это программа, используемая для ротации журналов. Он установлен в Ubuntu по умолчанию, а Nginx в Ubuntu поставляется со специальным скриптом logrotate.

Используйте предпочитаемый вами текстовый редактор для доступа к сценарию поворота. В этом примере используется nano:

sudo nano /etc/logrotate.d/nginx

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

Остальная часть файла указывает, что журналы будут меняться ежедневно и что 52 старые копии будут сохранены.

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

. . .
postrotate
	[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
. . .

Этот раздел указывает Nginx перезагрузить файлы журнала после завершения ротации.

Заключение

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

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