Как добавить модуль журнала в Nginx на CentOS 7

Вступление

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

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

В этом руководстве мы рассмотрим, как использовать модуль журналирования Nginx. Мы настроим отдельные файлы журнала для разных блоков сервера, а затем настроим вывод журнала. Мы также добавим дополнительную информацию о запросах (в примере этого руководства - время, необходимое для обработки запроса) в журнал доступа, помимо того, что Nginx включает по умолчанию.

Предпосылки

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

Один сервер CentOS 7, настроенный с помощью this первоначальное руководство по настройке сервера, включая пользователя без полномочий root.
Nginx установлен на вашем сервере, следуя How для установки Nginx на CentOS 7 учебник.

Шаг 1 - Создание тестовых файлов

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

Когда Nginx (или любой другой веб-сервер) получает HTTP-запрос на файл, он открывает этот файл и передает его пользователю, передавая его содержимое по сети. Чем меньше файл, тем быстрее он может быть передан. Когда файл передается полностью, запрос считается выполненным, и только после этого запись регистрируется.

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

Давайте создадим 1-мегабайтный файл с именем +1 mb.test в каталоге Nginx по умолчанию, используя` + truncate`.

sudo truncate -s 1M /usr/share/nginx/html/1mb.test

Аналогично, давайте создадим еще два файла разных размеров, сначала 10, а затем 100 мегабайт, назвав их соответственно.

sudo truncate -s 10M /usr/share/nginx/html/10mb.test
sudo truncate -s 100M /usr/share/nginx/html/100mb.test

И последнее, но не менее важное: давайте создадим и пустой файл:

sudo touch /usr/share/nginx/html/empty.test

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

Шаг 2 - Понимание конфигурации по умолчанию

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

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

Журнал доступа, расположенный в + / var / log / nginx / access.log +, используется чаще. Здесь хранится информация обо всех запросах к Nginx. В этом журнале вы можете видеть, среди прочего, какие файлы получают пользователи, какие веб-браузеры они используют, какие у них IP-адреса и какой код состояния HTTP Nginx отвечает на каждый запрос.

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

curl -i http://localhost/empty.test

В ответ вы должны увидеть несколько заголовков HTTP-ответа:

Заголовки ответа Nginx

HTTP/1.1 200 OK
Server: nginx/1.6.3
Date: Fri, 05 Aug 2016 22:05:03 GMT
Content-Type: application/octet-stream
Content-Length: 0
Last-Modified: Fri, 05 Aug 2016 22:04:55 GMT
Connection: keep-alive
ETag: "57a50d87-0"
Accept-Ranges: bytes

Из этого ответа вы можете узнать несколько вещей:

+ HTTP / 1.1 200 OK + сообщает нам, что Nginx ответил кодом состояния «+200 OK +», сообщающим, что ошибки не было.
+ Content-Length: 0 + означает, что возвращаемый документ имеет нулевую длину.
Запрос был обработан в + Пт, 05 августа 2016 22:05:03 GMT.

Давайте посмотрим, соответствует ли это тому, что Nginx хранит в своем журнале доступа. Файлы журнала доступны для чтения только администраторам, поэтому для доступа к ним необходимо использовать + sudo +.

sudo tail /var/log/nginx/access.log

Журнал будет содержать такую строку, соответствующую тестовому запросу, который мы выдавали ранее.

Доступ к записи в журнале

::1 - - [05/Aug/2016:22:05:03 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"

Nginx использует Combined Log Format, который является стандартизированным форматом журналов доступа, обычно используемых веб-серверами для обеспечения взаимодействия. В этом формате каждая часть информации ограничена одним пробелом; дефисы представляют недостающие фрагменты информации.

Слева направо категории:

* IP-адрес пользователя *, который запросил ресурс. Поскольку вы использовали + curl + локально, адрес указывает на локальный хост + :: 1 +.
* Удаленная регистрация * информации. Здесь всегда будет дефис, потому что Nginx не поддерживает эту информацию.
* Username зарегистрированного пользователя * в соответствии с HTTP Basic Authentication. Это будет пустым для всех анонимных запросов.
* Дата запроса *. Вы можете видеть, что это соответствует дате из наших заголовков ответа.
* Путь запроса *, который включает в себя метод запроса (+ GET +), путь к запрашиваемому файлу (+ / empty.text +), а также используемый протокол (+ HTTP / 1.1 +).
* Код статуса ответа *, который был +200 OK +, что означает успех.
* Длина переданного файла *, которая здесь равна + 0 +, поскольку файл был пустым.
Заголовок * HTTP Referer *, который содержит адрес документа, из которого был получен запрос. В этом примере он пуст, но если бы это был файл изображения, реферер указал бы на страницу, на которой использовалось изображение. + Заголовок HTTP Referer - это неправильное написание слова «referrer», которое восходит к истокам HTTP и является частью стандарта HTTP.
* Пользовательский агент *, который здесь + curl +.
Пустой заголовок * X-Forwarded-For *, который содержит информацию об IP-адресе источника, если исходный запрос был перенаправлен через прокси-сервер.

Даже одна запись в журнале доступа содержит много ценной информации о запросе. Тем не менее, один важный бит информации отсутствует. Хотя мы запросили точное местоположение + http: // localhost / empty.test +, в записи журнала есть только путь к файлу + / empty.test +; информация об имени хоста (здесь + localhost +) теряется.

Шаг 3 - Настройка отдельного журнала доступа

Далее мы переопределим конфигурацию ведения журнала по умолчанию (где Nginx хранит один файл журнала доступа для всех запросов) и заставим Nginx вместо этого хранить отдельный файл журнала для блока сервера по умолчанию, который поставляется с чистой установкой Nginx. Вы можете ознакомиться с блоками сервера Nginx, прочитав How для установки Nginx Серверные блоки (виртуальные хосты) в CentOS 7 учебное пособие.

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

Чтобы изменить конфигурацию блока сервера Nginx по умолчанию, откройте файл конфигурации блока Nginx сервера в + vi + (здесь находится https://www.digitalocean.com/community/tutorials/install-and-using-the-vim-text -editor-on-a-cloud-server # modal-edit [краткое введение в + vi + '] (если вы не знакомы с ним) или ваш любимый текстовый редактор.

sudo vi /etc/nginx/nginx.conf

Найдите блок конфигурации + server +, который выглядит следующим образом:

/etc/nginx/nginx.conf

. . .
server {
   listen       80 default_server;
   listen       [::]:80 default_server;
. . .

и добавьте две строки, отмеченные красным, в конфигурацию:

/etc/nginx/nginx.conf

. . .
server {
   listen 80 default_server;
   listen [::]:80 default_server;



. . .

Директива + access log устанавливает путь к файлу, в котором будут храниться журналы доступа, а` + error_log` делает то же самое для журнала ошибок. Мы используем ту же директорию, что и журналы Nginx по умолчанию (+ / var / log / nginx +), но с разными именами файлов. Если у вас есть несколько блоков серверов, хорошей идеей будет называть лог-файлы последовательным и значимым образом, например, используя имя домена в имени файла.

Сохраните и закройте файл для выхода.

Чтобы включить новую конфигурацию, перезапустите Nginx.

sudo systemctl restart nginx

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

curl -i http://localhost/empty.test

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

sudo tail /var/log/nginx/default-access.log

На следующем шаге мы настроим формат журналов в этом новом файле и добавим дополнительную информацию.

Шаг 4 - Настройка пользовательского формата журнала

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

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

Чтобы определить новый формат ведения журнала, создайте новый файл конфигурации с именем + timed-log-format.conf + в каталоге дополнительных настроек Nginx.

sudo vi /etc/nginx/conf.d/timed-log-format.conf

Добавьте следующее содержание:

/etc/nginx/conf.d/timed-log-format.conf

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

Сохраните и закройте файл для выхода.

Директива установки + log_format + определяет новый формат журнала. Следующий элемент - это уникальный идентификатор этого формата; здесь мы используем * timed *, но вы можете выбрать любое имя.

Далее идет сам формат журнала, разделенный на три строки для удобства чтения. Nginx предоставляет информацию обо всех запросах в именованных системных переменных, перед которыми стоит знак доллара. Они будут заменены фактической информацией о запросе при записи подробностей запроса в журнал доступа (например, + $ request_addr + будет заменен на IP-адрес посетителя).

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

Теперь у нас есть пользовательский формат журнала с именем * timed *, определенный в конфигурации Nginx, но серверный блок по умолчанию еще не использует этот формат. Далее откройте файл конфигурации Nginx блока сервера.

sudo vi /etc/nginx/nginx.conf

Найдите блок конфигурации + server +, который мы изменили ранее, и добавьте имя формата журнала + timed + в настройку + access_log +, как показано ниже красным цветом:

/etc/nginx/nginx.conf

. . .
server {
   listen 80 default_server;
   listen [::]:80 default_server;

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

Сохраните и закройте файл для выхода.

Чтобы включить новую конфигурацию, перезапустите Nginx.

sudo systemctl restart nginx

Теперь, когда все настроено, давайте проверим, работает ли оно.

Шаг 5 - Проверка новой конфигурации

Мы можем протестировать новую конфигурацию, вызвав некоторые запросы к Nginx с помощью + curl +, как мы это делали на шаге 2. На этот раз мы будем использовать файлы примеров, созданные на шаге 1:

curl -i http://localhost/empty.test
curl -i http://localhost/1mb.test
curl -i http://localhost/10mb.test
curl -i http://localhost/100mb.test

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

Давайте отобразим журнал доступа после выполнения этих запросов.

sudo tail /var/log/nginx/default-access.log

Журнал теперь будет содержать больше строк, но последние четыре будут соответствовать только что выполненным тестовым запросам.

Доступ к записям журнала

::1 - - [05/Aug/2016:22:14:04 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"
::1 - - [05/Aug/2016:22:14:04 +0000] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.29.0" "-"
::1 - - [05/Aug/2016:22:14:07 +0000] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.29.0" "-"
::1 - - [05/Aug/2016:22:15:10 +0000] "GET /100mb.test HTTP/1.1" 200 104857600 "-" "curl/7.29.0" "-"

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

Если это так, вы успешно настроили собственный формат журнала в Nginx!

Заключение

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

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

Список переменных, которые можно использовать с форматами журналов Nginx, описан в документации по модулю журнала Nginx.

TOC

Как добавить модуль журнала в Nginx на CentOS 7

Вступление

Предпосылки

Шаг 1 - Создание тестовых файлов

Шаг 2 - Понимание конфигурации по умолчанию

Шаг 3 - Настройка отдельного журнала доступа

Шаг 4 - Настройка пользовательского формата журнала

Шаг 5 - Проверка новой конфигурации

Заключение

Related