Логи access_log и error

2: Стандартные настройки логов

Модуль log встроен в ядро Nginx, потому его не нужно устанавливать.

Конфигурация модуля по умолчанию включает только основные настройки.

На свежем сервере Nginx регистрирует запросы в двух отдельных файлах:

/var/log/nginx/error.log (лог ошибок);
/var/log/nginx/access.log (лог, в котором хранится информация о запросах).

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

Чтобы увидеть, как выглядит стандартная строка лога access.log, запросите пустой файл:

Сервер вернёт:

Этот ответ содержит следующие данные:

HTTP/1.1 200 OK – код состояния, отправленный Nginx (200 OK значит, что при обработке файла не возникло ошибки).
Content-Length: 0 – это значит, что возвращаемый документ нулевой длины.
Thu, 30 Jun 2016 18:10:15 GMT – дата обработки процесса.

Теперь проверьте файл access.log.

В файле будет примерно такая запись:

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

Рассмотрим по порядку категории, присутствующие в файле:

Сначала указывается IP-адрес пользователя, сделавшего запрос (127.0.0.1).
Затем идут данные об удалённом входе (здесь всегда будет прочерк, потому что Nginx не поддерживает такие данные).
Далее указано имя пользователя, создавшего подключение (в случае анонимного запроса в файле будет прочерк).
Дата запроса (она совпадает с датой из ответа веб-сервера).
Далее следует путь к запросу, который включает в себя метод (GET), путь к запрашиваемому файлу (/empty.text) и протокол (HTTP/1.1).
Затем идёт код состояния ответа (в данном случае 200 ОК).
Длина передаваемого файла (0).
HTTP заголовок Referer, который содержит адрес документа, от которого поступил запрос. В этом примере он пуст, но если бы это был файл изображения, то Referer указал бы на страницу, на которой использовано это изображение. Заголовок Referer – это результат неправильного написания слова «referrer», что является частью стандарта HTTP.
Агент (в данном случае curl).

Как видите, даже простая запись в логе access предоставляет много полезной информации о запросе. Однако на данный момент в файле отсутствует важный фрагмент данных – имя хоста в пути к файлу (localhost).

Настройка журнала доступа

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

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

Самый основной синтаксис директивы access_log следующий:

access_log log_file log_format;

Где log_file – полный путь к файлу журнала и формат log_format, используемый файлом журнала.

Журнал доступа может быть включен либо в http, server или location директива блока.

По умолчанию журнал доступа включен глобально в директиве http внутри основного файла конфигурации Nginx.
/etc/nginx/nginx.conf

http {
  ...
  access_log  /var/log/nginx/access.log;
  ...
}

Для удобства обслуживания рекомендуется установить отдельный файл журнала доступа для каждого блока сервера. Директива access_log установлена в директиве server перекрывает одну установленные в директиве http (более высокого уровня).
/etc/nginx/conf.d/domain.ru.conf

http {
  ...
  access_log  /var/log/nginx/access.log;
  ...

  server {
    server_name domain.ru
    access_log  /var/log/nginx/domain.access.log;
    ...
  }
}

Если формат журнала не указан, Nginx использует предопределенный комбинированный формат, который выглядит следующим образом:

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

Чтобы изменить формат ведения журнала, либо переопределите настройку по умолчанию, либо определите новый. Например, чтобы определить новый формат ведения журнала с именем main, который расширит объединенный формат значением, показывающим заголовок X-Forwarded-For, добавьте следующее определение в директиву http или server:

log_format  custom  '$remote_addr - $remote_user  "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

Чтобы использовать новый формат, укажите его имя после файла журнала, как показано ниже:

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

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

access_log  off;

Ведение журнала ошибок с помощью njs

С njs вы можете использовать или (для более старых версий njs объект ngx недоступен) в функции javascript для записи заголовков. js функция должна вызываться явно, чтобы это работало, например, с Директива .

Js модуль:

Разрешить вход в локацию:

Для журнала ошибок экранирование не применяется, поэтому вы получите необработанный json:

Запись в журнал ошибок может быть полезна, если вы не хотите портить журналы доступа или вам нужно регистрировать заголовки только для определенного местоположения (для конкретного местоположения можно использовать директиву access_log и отдельный log_format)

Пользовательские логи

В предыдущем разделе строка, описывающая access.log, использует не такую директиву, как предыдущие строки для настройки логов. Она использует CustomLog:

Эта директива имеет такой синтаксис:

В данном случае log_format (формат логов) является комбинированным (combined). Эта спецификация не является внутренней спецификацией Apache; она задаёт пользовательский формат, который определен в конфигурационном файле по умолчанию.

Снова откройте конфигурационный файл по умолчанию и найдите строку, определяющую формат combined:

Команда LogFormat определяет пользовательский формат логов, вызываемых директивой CustomLog.

Этот формат называется комбинированным (combined).

Примечание: Подробнее о доступных форматах можно узнать .

Существует еще несколько распространённых форматов, которые можно использовать в определении виртуальных хостов. Можно также создавать свои собственные форматы.

2: Стандартные настройки логов

Модуль log встроен в ядро Nginx, потому его не нужно устанавливать.

Конфигурация модуля по умолчанию включает только основные настройки.

На свежем сервере Nginx регистрирует запросы в двух отдельных файлах:

/var/log/nginx/error.log (лог ошибок);
/var/log/nginx/access.log (лог, в котором хранится информация о запросах).

Чтобы увидеть, как выглядит стандартная строка лога access.log, запросите пустой файл:

На экране появится ряд HTTP-заголовков:

Этот ответ содержит следующие данные:

HTTP/1.1 200 OK – код состояния, отправленный Nginx (200 OK значит, что при обработке файла не возникло ошибки).
Content-Length: 0 – это значит, что возвращаемый документ нулевой длины.
Fri, 05 Aug 2016 22:05:03 – дата обработки процесса.

Теперь проверьте файл access.log.

В файле будет примерно такая запись:

Рассмотрим по порядку категории, присутствующие в файле:

Сначала указывается IP-адрес пользователя, сделавшего запрос (::1).
Затем идут данные об удалённом входе (здесь всегда будет прочерк, потому что Nginx не поддерживает такие данные).
Далее указано имя пользователя, создавшего подключение (в случае анонимного запроса в файле будет прочерк).
Дата запроса (она совпадает с датой из ответа веб-сервера).
Далее следует путь запроса, который включает в себя метод (GET), путь к запрашиваемому файлу (/empty.text) и протокол (HTTP/1.1).
Затем идёт код состояния ответа (в данном случае 200 ОК).
Длина передаваемого файла (0).
HTTP заголовок Referer, который содержит адрес документа, от которого поступил запрос. В этом примере он пуст, но если бы это был файл изображения, то Referer указал бы на страницу, на которой использовано это изображение. Заголовок Referer – это результат неправильного написания слова «referrer», что является частью стандарта HTTP.
Агент (в данном случае curl).
Заголовок X-Forwarded-For (содержит информацию об исходном IP-адресе, если запрос был направлен через прокси-сервер; в данном случае стоит прочерк).

Особенность

Собственно для чего я написал эту статью.

По неподтверждённой информации при описании access_log и error_log в файлах, которые подключаются через include, они действуют только внутри подключаемого файла.

Например, «file1.conf»:

file1.conf

error_log /mydirectory/myerror.log error;
access_log /mydirectory/myerror.log;

location …. и другие настройки в файле

1
2
3
4
5

error_log /mydirectory/myerror.log error;
access_log /mydirectory/myerror.log;

location …. и другие настройки в файле

Основной «nginx.conf»:

http {
…

include file1.conf;
include file2.conf;
include file3.conf;
….

}

1
2
3
4
5
6
7
8
9

http {
…

include file1.conf;
include file2.conf;
include file3.conf;
….

}

В такой конфигурации access_log и error_log, описанные в «file1.conf», действуют только внутри «file1.conf», а в файлах «file2.conf», «file3.conf» можно описать другие access_log и error_log для location-ов, которые описаны в них («file2.conf», «file3.conf»).

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

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

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

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

Создайте файл 1mb.test размером в один мегабайт в каталоге сайта:

Затем создайте ещё два файла размером в 10 и 100 мегабайт:

Также для работы понадобится пустой файл:

Просмотр логов с помощью ISPManager

Если на сервере установлен ISPManager, логи можно легко читать, используя приведенный ниже алгоритм.

На главной странице, в панели инструментов «WWW» нужно нажать на вкладку «Журналы».
ISPManager выдаст журналы посещений и серверных ошибок в виде:
- ru.access.log;
- ru.error.log.*
* Вместо «newdomen.ru» из примера в выдаче будет название актуального домена.

Открыть файл лога можно, нажав на «Посмотреть» в верхнем меню.
Для просмотра всех записей журнала, необходимо нажать на «Скачать» и сохранить файл на локальный носитель.
Более старые версии логов можно найти во вкладке «Архив».

1: Создание тестовой веб-страницы

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

Давайте создадим в каталоге веб-сайта Nginx по умолчанию простую страницу index.html. В этом файле будет текст, описывающий страницу – «Home».

Давайте с помощью curl проверим, правильно ли обслуживается этот файл. Нам не нужно указывать index.html в этой команде, потому что этот файл обслуживается по умолчанию, если точное имя файла не указано:

В результате вы должны увидеть одно слово Home.

Теперь давайте попробуем получить доступ к файлу, которого нет в /var/www/html/, например old.html:

В ответ вы увидите сообщение об ошибке 404 Not Found, что означает, что страница не существует:

404 Not Found

nginx/1.18.0 (Ubuntu)

В следующем разделе мы будем использовать модуль map, чтобы этот старый адрес снова стал работать – путем автоматического перенаправления пользователей на новые страницы.

Использование с Nginx

При использовании GoAccess с веб-сервером Nginx может возникнуть несколько ньансов. Если на сервере сайт один, то можно ничего не менять и использовать формат логов COMBINED. Или настроить запись логов для каждого сайта в одельный файл типа и тогда также использовать формат COMBINED.

Но бывают ситуации, когда на сайте настроено много поддоменов, особенно актуально для доров. Тогда конфиг Nginx может выглядеть примерно так:

В таком случае в GoAccess можно увидеть только суммарную статистику по всем поддоменам. Чтобы можно было видеть статистику по каждому поддомену отдельно необходимо включить в лог имя virtual host. Для этого необходимо настроить в Nginx формат VCOMBINED.

Настройка VCOMBINED логов в NGINX

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

Для настройки формата VCOMBINED необходимо добавить в следующую конфигурацию:

И включить логирование в формате VCOMBINED в настройках virtual host:

После этого необходимо перезагрузить конфигурацию nginx:

3: Настройка дополнительного лога запросов

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

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

Откройте виртуальный хост Nginx по умолчанию в редакторе:

Найдите блок server:

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

Директива access_log задаёт путь к логу запросов, а error_log указывает путь к логу ошибок. Эти файлы хранятся в одном каталоге со стандартными логами Nginx (/var/log/nginx).

Примечание: Если на одном сервере размещено несколько сайтов, можно использовать описательные имена логов (например, домены).

Сохраните и закройте файл.

Чтобы поддерживать отдельные логи для каждого виртуального хоста, вы должны применять предложенные выше настройки в новых виртуальных хостах Nginx.

Обновите настройки Nginx:

Чтобы протестировать новую настройку, снова отправьте запрос:

Теперь проверьте новый лог-файл:

Кратко о маршрутизации лог-сообщиний в fluent-bit

Маршрутизация в fluent-bit позволяет направлять лог-сообщения через различные фильтры, для их преобразования, и в конечном итоге в один или несколько выходных интерфейсов. Для организации маршрутизации используется две основные концепции:

тег (tag) — человеко читаемый индикатор, позволяющий однозначно определить источник лог-сообщения;
правило сопоставления (match) — правило, определяющее куда лог-сообщение должно быть перенаправлено.

Выглядит все следующим образом:

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

Step 5 — Logging To Syslog

It’s possible to set up Nginx to log events into the system log. The utility allows collecting log messages from different devices on a single syslog server. In Nginx logging to is done using prefix:

Log messages are sent to a which can be:

The domain name
IP address IPv4 or IPv6
a UNIX-domain socket path

In the example above, error log messages are sent to a UNIX domain socket at the logging level. The access log is written to a server with an IPv4 address and port .

The parameter specifies the type of program that is logging the message.

The parameter applies a custom tag to syslog messages.

The parameter sets the severity level of syslog messages for access log.

Важные логи сайта

Access.log — логи посещений пользователей и ботов. Позволяет составить более точную и подробную статистику, нежели сторонние ресурсы, выполняющие внешнее сканирование сайта и отправляющие ряд ненужных запросов серверу. Благодаря данному логу можно получить информацию об используемом браузере и IP-адрес посетителя, данные о местонахождении клиента (страна и город) и многое другое

Стоит обратить внимание, если сайт имеет высокую посещаемость, то анализ логов сервера потребует больше времени. Поэтому для составления статистики стоит использовать специализированные программы (анализаторы).

Error.log — программные ошибки сервера

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

Slow.log (название зависит от используемой оболочки сервера) — в данный журнал записываются медленные запросы сервера. Так принято обозначать запросы с повышенным порогом задержки, выданные пользователю. Этот журнал позволяет выявить слабые места сервера и исправить проблему. Ниже будет рассмотрен способ включить ведение данного лога на разных типах серверов, а также настройка задержки, с которой записи будут заноситься в файл.

Классы и функции

До сих пор мы видели logger по умолчанию с именем root, который используется модулем logging всякий раз, когда его функции вызываются непосредственно таким образом: logging.debug(). Вы можете (и должны) определить свой собственный logger, создав объект класса Logger, особенно если ваше приложение имеет несколько модулей. Давайте посмотрим на некоторые классы и функции в модуле.

Наиболее часто используемые классы, определенные в модуле logging, следующие:

: Это класс, чьи объекты будут использоваться в коде приложения напрямую для вызова функций.
: Logger автоматически создает объект LogRecord, в котором находиться вся информация, относящаяся к регистрируемому событию, например, имя логера, функции, номер строки, сообщение и т. д.
: Обработчики отправляют LogRecord в требуемое место назначения вывода, такое как консоль или файл. Обработчик является основой для подклассов, таких как StreamHandler, FileHandler, SMTPHandler, HTTPHandler и других. Эти подклассы отправляют выходные данные журнала соответствующим адресатам, таким как sys.stdout или файл на диске.
: Здесь вы указываете формат вывода, задавая строковый формат, в котором перечислены атрибуты, которые должны содержать выходные данные.

Из всего перечисленного мы в основном имеем дело с объектами класса Logger, которые создаются с помощью функции уровня модуля logging.getLogger(name). Многократные вызовы getLogger() с одним и тем же именем возвращают ссылку на один и тот же объект Logger, что избавляет нас от передачи объектов logger в каждую часть, где это необходимо. Вот пример:

import logging

logger = logging.getLogger('example_logger')
logger.warning('This is a warning')

This is a warning

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

WARNING:example_logger:This is a warning

Опять же, в отличие от корневого logger, пользовательский logger нельзя настроить с помощью basicConfig(). Вы должны настроить его с помощью Handlers и Formatters:

Настройка и основные команды

Если вы используете стандартный лог веб-сервера, то настраивать ничего и не нужно:-).

Стандартные типы логов, которые поддерживает GoAccess:

COMBINED — Combined Log Format,
VCOMBINED — Combined Log Format with Virtual Host,
COMMON — Common Log Format,
VCOMMON — Common Log Format with Virtual Host,
W3C — W3C Extended Log File Format,
SQUID — Native Squid Log Format,
CLOUDFRONT — Amazon CloudFront Web Distribution,
CLOUDSTORAGE — Google Cloud Storage,
AWSELB — Amazon Elastic Load Balancing,
AWSS3 — Amazon Simple Storage Service (S3)

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

Для вывода в HTML необходимо указать имя файла

Также поддерживается вывод в JSON и CSV таблицу. Плюс есть возможность сделать real-time отчет, который обновляется в реальном времени, но это мы рассмотрим далее.

Выбор даты

Важные моменты:

Логи хранятся только за текущий и 4 предыдущих месяца, и только за те дни, когда к сайтам были запросы. Более старые логи не хранятся.
Текущая дата в списке доступна всегда, вне зависимости от того, есть записи в логе или нет.
Если в списке дат отсутствует вчерашнее число, значит логи за этот день ещё обрабатываются и станут доступны позже (как правило, ближе ко второй половине дня). Аналогичная ситуация может быть 1 числа месяца с логами и отчётами за предыдущий месяц.

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

В списке можно:

Выбрать дату для просмотра .
лог за месяц. Примечание Только для .
Просмотреть за месяц. Примечание Только для .

Заключение

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

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

Оригинальная статья: Logging in Python

Spread the love

2
Поделились

Заключение

Я долго размышлял над дашбордом для логов nginx. Рисовал графики, выбирал данные. В итоге остановился на таком варианте. Больше ничего полезного для вывода придумать не смог. Кстати, сама Geo карта тут больше для красоты. Я ей не пользуюсь. Практической пользы в ней не вижу. Если у вас есть советы по каким-то еще полезным данным, которые можно вывести — делитесь. Конечно, можно добавить инфу по юзерагентам, системам и браузерам. Но мне кажется, такие вещи удобнее смотреть в сторонней аналитике. Там будут более точные данные.

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

Онлайн курс по Kubernetes

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

Если вы ответите «да» хотя бы на один вопрос, то это ваш курс:

устали тратить время на автоматизацию?
хотите единообразные окружения?;
хотите развиваться и использовать современные инструменты?
небезразлична надежность инфраструктуры?
приходится масштабировать инфраструктуру под растущие потребности бизнеса?
хотите освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта?

Сдавайте вступительный тест по и присоединяйтесь к новому набору!.