Бесплатная миграция IT-инфраструктуры в облако

Логи NGINX: журналы доступа и ошибок

Александр Бархатов
Александр Бархатов
Технический писатель
26 ноября 2024 г.
79
13 минут чтения
Средний рейтинг статьи: 5

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

Предварительные требования

Для работы с журналами Nginx нам понадобится следующее:

  • Один сервер или одна виртуальная машина с абсолютно любым предустановленным дистрибутивом Linux: Ubuntu, Debian, RHEL, CentOS и многие другие. В данной статье будет использоваться Ubuntu 22.04.

  • Установленный веб-сервер Nginx. Установить Nginx на Ubuntu можно по инструкции. В статье мы будем использовать Nginx 1.18.0, установленный из репозиториев дистрибутива Ubuntu. 

Создание облачного сервера

Для демонстрации работы Nginx нам нужно арендовать облачный сервер

1) Входим в аккаунт Timeweb Cloud при помощи логина или адреса электронной почты и пароля или при помощи Passkey, ВКонтакте, GitHub, Google.

2) После успешной авторизации отобразится панель управления текущего проекта. Переходим в раздел «Облачные серверы» и нажимаем «Создать» или «Добавить».

3) Выбираем операционную систему, которая будет установлена на сервер. В нашем случае нам необходима Ubuntu версии 22.04.

Image5

4) Выбираем регион, в котором будет находиться наш сервер. Выбирать рекомендуется тот регион, который ближе всего находится к вам физически. У каждого доступного региона справа вверху отображается ping, т.е. время, необходимое для передачи данных с вашего компьютера на сервер. Чем меньше указанное время, тем быстрее будет осуществляться передача данных.

Image1

5) Далее выбираем необходимую конфигурацию для сервера. Так как в данной статье будут рассмотрены только базовые примеры по работе с журналами Nginx, можно выбрать минимальную доступную конфигурацию, включающую в себя одноядерный процессор, 1 ГБ оперативной памяти и 15 ГБ места на NVMe диске. В реальности вам необходимо выбирать ту конфигурацию, которая будет удовлетворять вашим потребностям при работе с Nginx. Стоит отметить, что сам Nginx (не включая нагрузку) потребляет минимальное количество ресурсов. Расчет необходимой конфигурации происходит исходя из используемой нагрузки. Выбираем соответствующий тариф:

Image4

6) Далее необходимо решить, будет ли сервер доступен из внешний сети или же только из приватной (частной) сети. Если не уверены в настройках, оставьте эти параметры без изменений.

Чтобы сервер был доступен из интернета, закажите для него публичный IP.

7) По желанию можно оформить дополнительные услуги, включая резервные копии и защиту от DDoS-атак (последняя доступна только в Санкт-Петербурге и Москве).

8) Также заранее можно загрузить SSH-ключ, чтобы не входить на север при помощи пароля.

9) Можно задать необходимое имя для сервера которое будет отображаться в панели управления, а также выбрать проект.

10) Для создания сервера необходимо нажать на кнопку «Заказать»:

Image3

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

vds

Описание журналов доступа и журнала ошибок NGINX

В своей работе Nginx использует два типа журналов:

  • Журнал доступа — предназначен для записи всех запросов, которые поступают и обрабатываются через Nginx. 
  • Журнал ошибок — предназначен для записи различных ошибок, включая ошибки конфигурации как самого Nginx, так и сторонних сервисов (например, php-fpm).

Журнал доступа access_log

Как уже было упомянуто ранее журнал доступа, он же access_log, используется для записи всех запросов от клиентов. Каждый раз, когда поступает запрос от клиента, Nginx записывает данное обращение в журнал доступа. Сохраненная запись содержит временную метку (Timestamp), информацию о клиенте, включая адрес запрошенного ресурса, адрес клиента и многое другое. По умолчанию журнал доступа записывается в файл access.log, который находится по следующему пути /var/log/nginx.

Типичный вывод лог-записи из журнала доступа выглядит следующим образом:

81.94.230.132 - - [20/Nov/2024:13:52:04 +0300] "GET /favicon.ico HTTP/1.1" 404 197 "http://93.183.83.214/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"

Где:

  • 81.94.230.132 — IP-адрес клиента, который сделал запрос.
  • - — Идентификатор клиента. Если в ответ вернулся символ дефиса, значит, идентификация через identd не используется.
  • - - Имя пользователя. Если в ответ вернулся символ дефиса, то авторизация на запрашиваемом ресурсе не требуется или не пройдена.
  • [20/Nov/2024:13:52:04 +0300] — Временная метка, когда был сделан запрос. Сама метка состоит из следующих данных:
    • 20/Nov/2024 — Дата запроса в формате день/месяц/год.

    • 13:52:04 — Время, когда был сделан запрос. Указывается то время, которое используется на сервере.

    • +0300 — Используемый часовой пояс. В данном случае используется UTC+3:00.

  • GET /favicon.ico HTTP/1.1 — Строка запроса протокола HTTP. Состоит из:
    • GET — Метод который использовался при доступе к запрашиваемому ресурсу.

    • /favicon.ico — Запрашиваемый ресурс.

    • HTTP/1.1 — Используемая версия HTTP-протокола.

  • 404 — Код ответа HTTP. В данном случае код ответа 404 означает, что запрашиваемый ресурс не найден.
  • 197 — Размер переданного ответа в байтах (включая заголовки и тело ответа).
  • http://93.183.83.214/ — HTTP referer (содержит URL источника запроса).
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 — User-Agent клиента (содержит информацию о браузере и операционной системе).

Настроить журнал доступа можно как на уровне веб-сервера, задав необходимые настройки в файле nginx.conf, так и отдельно для каждого веб-сайта, используя его конфигурационный файл в директории /etc/nginx/sites-available (если Nginx был установлен из репозиториев операционной системы) или в директории /etc/nginx/conf.d.

Для настройки журнала доступа используется два параметра:

  • log_format — указывает формат лога и то, какие данные необходимо логировать. Для этого используются многочисленные встроенные переменные (будут рассмотрены далее).

  • access_log — задает путь до файла журнала доступа, в который будут записываться события. По умолчанию используется путь /var/log/nginx/access.log.

Ниже приведем пример настройки access.log, заданной в основном конфигурационном файле /etc/nginx/nginx.conf:

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

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

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

Здесь мы используем следующие переменные: 

  • $remote_addr — записывает IP-адрес клиента.
  • $remote_user — записывает имя пользователя, переданное в авторизации (при наличии включенной авторизации на сайте).
  • $time_local — записывает локальное время, то есть время, когда был сделан запрос.
  • $request — записывает строку с HTTP-запросом (включая метод, URI и версию протокола).
  • $status — записывает HTTP-статус ответа.
  • $body_bytes_sent — записывает количество байт в теле ответа (без заголовков).
  • $http_referer — записывает заголовок HTTP Referer (адрес страницы, с которой был выполнен переход).
  • $http_user_agent — записывает заголовок User-Agent (информация о браузере/клиенте).

Более подробно ознакомиться со всеми встроенными переменными можно в документации Nginx.

Полное содержание файла nginx.conf представлено ниже:

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

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##
           log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent"';
	access_log /var/log/nginx/access.log;
	##
	# Gzip Settings
	##

	gzip on;

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# Virtual Host Configs
	##

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Журнал ошибок error_log

Для записи всевозможных ошибок существует второй журнал — error_log. В данный журнал записываются такие ошибки, как:

  • Ошибки конфигурации
  • Проблемы с подключением к бекенд-серверам (backend)
  • Ошибки, связанные с получением доступа/прав к файлам
  • Внутренние ошибки сервера (5xx)
  • Проблемы в работе SSL

По умолчанию журнал ошибок записывается в файл error.log, который находится по пути /var/log/nginx.

Типичный вывод лог-записи из файла error.log выглядит так:

20/Nov/2024:14:00:00 [error] 1234#5678: *10 open() "/var/www/html/test-page.html" failed (2: No such file or directory), client: 127.0.0.1, server: my-local-server.com, request: "GET /test-page.html HTTP/1.1", host: "example.com"

Где:

  • 20/Nov/2024:14:00:00 — Временная метка возникновения ошибки. Состоит из следующих данных:
    • 20/Nov/2024 — Дата запроса в формате день/месяц/год.

    • 14:00:00 — Время, когда был сделан запрос. Указывается то время, которое используется на сервере.

  • [error] — Уровень ошибки. Может иметь значения [error], [info], [warn], [crit] и другие. Уровни логирования будут рассмотрены в следующей главе.
  • 1234#5678 — Идентификатор процесса и потока.
  • open() "/var/www/html/test-page.html" failed (2: No such file or directory) — Полное описание возникшей ошибки. В данном случае был выполнен запрос к несуществующему файлу (странице) с именем test-page.html.
  • client: 127.0.0.1 — IP-адрес клиента, который выполнил запрос. В данном примере запрос был отправлен с локального компьютера (localhost).
  • server: my-local-server.com — Имя сервера, на который был отправлен запрос.
  • request: "GET /test-page.html HTTP/1.1" - Строка запроса протокола HTTP. Состоит из:
    • GET — Метод, который использовался при доступе к запрашиваемому ресурсу.

    • /test-page.html — Запрашиваемый ресурс.

    • HTTP/1.1 — Используемая версия HTTP-протокола.

  • host: "example.com" — имя хоста, к которому был отправлен запрос.

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

Для настройки журнала доступа используется два параметра:

  • log_format — указывает формат лога и то, какие данные необходимо логировать. Для этого используются многочисленные встроенные переменные (будут рассмотрены далее).

  • error_log — задает путь до файла журнала доступа, в который будут записываться события. По умолчанию используется путь /var/log/nginx/error.log.

Воспользуемся следующим примером настройки error.log, который необходимо указать в основном конфигурационном файле веб-сервера nginx.conf:

  log_format error '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';
error_log /var/log/nginx/access.log main;

Рассмотрим подробнее переменные:

  • $remote_addr — записывает IP-адрес клиента.
  • $remote_user — записывает имя пользователя, переданное в авторизации (при наличии включенной авторизации на сайте).
  • $time_local — записывает локальное время, то есть время, когда был сделан запрос.
  • $request — записывает строку с HTTP-запросом (включая метод, URI и версию протокола).
  • $status — записывает HTTP-статус ответа.
  • $body_bytes_sent — записывает количество байт в теле ответа (без заголовков).
  • $http_referer — записывает заголовок HTTP Referer (адрес страницы, с которой был выполнен переход).
  • $http_user_agent — записывает заголовок User-Agent (информация о браузере/клиенте).
  • $gzip_ratio — записывает коэффициент сжатия Gzip (при условие что в настройках Nginx включено сжатие).

Полное содержимое конфигурационного файла nginx.conf представлено ниже:

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

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##
  log_format error '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';
error_log /var/log/nginx/access.log error;
	##
	# Gzip Settings
	##

	gzip on;

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# Virtual Host Configs
	##

	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Уровни логирования в журналах Nginx

В Nginx применяются следующие 8 уровней логирования, которые применимы как к журналу доступа, так и к журналу ошибок:

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

  • info — используется для записи информационных сообщений о работе сервера. К таким сообщениям относят, например, сообщения о запуске или остановке серверных процессов.

  • notice — указывает на важные, но не критичные события. Эти сообщения полезны для понимания работы системы, но не требуют вмешательства со стороны администратора веб-сервера. К таким сообщениям относится, например, обновление конфигурации.

  • warn —  логирует предупреждения, которые не являются критичными, но могут привести к проблемам в будущем.

  • error — сообщает о проблемах, которые привели к сбою обработки определенных запросов, но не влияют на общую работоспособность сервера. Например, невозможность открыть файл или подключиться к бэкенду.

  • crit — указывает на критические ошибки, которые могут нарушить нормальную работу сервера. Например, сбой в работе модуля или нехватка ресурсов.

  • alert — сообщает о серьезных проблемах, которые требуют немедленного вмешательства.

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

Разверните свой Ubuntu VDS в Timeweb Cloud

Заключение

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

Хотите внести свой вклад?
Участвуйте в нашей контент-программе за
вознаграждение или запросите нужную вам инструкцию
img-server
26 ноября 2024 г.
79
13 минут чтения
Средний рейтинг статьи: 5
Пока нет комментариев