Nginx error log stderr

Основная функциональность

Пример конфигурации

user www www;
worker_processes 2;

error_log /var/log/nginx-error.log info;

events {
    use kqueue;
    worker_connections 2048;
}

...

Директивы

accept_mutex off;

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

Нет необходимости включать accept_mutex
на системах, поддерживающих
флаг EPOLLEXCLUSIVE (1.11.3), или
при использовании reuseport.

До версии 1.11.3 по умолчанию использовалось значение on.

accept_mutex_delay 500ms;

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

daemon on;

Определяет, будет ли nginx запускаться в режиме демона.
Используется в основном для разработки.

Включает отладочный лог для отдельных клиентских соединений.
Для остальных соединений используется уровень лога, заданный директивой
error_log.
Отлаживаемые соединения задаются IPv4 или IPv6 (1.3.0, 1.2.1)
адресом или сетью.
Соединение может быть также задано при помощи имени хоста.
Отладочный лог для соединений через UNIX-сокеты (1.3.0, 1.2.1)
включается параметром “unix:”.

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    ...
}

Для работы директивы необходимо сконфигурировать nginx с параметром
--with-debug,
см. “Отладочный лог”.

Эта директива используется для отладки.

В случае обнаружения внутренней ошибки, например, утечки сокетов в момент
перезапуска рабочих процессов, включение debug_points
приводит к созданию core-файла (abort)
или остановке процесса (stop) с целью последующей
диагностики с помощью системного отладчика.

env TZ;

По умолчанию nginx удаляет все переменные окружения, унаследованные
от своего родительского процесса, кроме переменной TZ.
Эта директива позволяет сохранить часть унаследованных переменных,
поменять им значения или же создать новые переменные окружения.
Эти переменные затем:

• наследуются во время
  обновления исполняемого файла на лету;
• используются модулем
  ngx_http_perl_module;
• используются рабочими процессами.
  Следует иметь в виду, что управление поведением системных библиотек
  подобным образом возможно не всегда, поскольку зачастую библиотеки используют
  переменные только во время инициализации, то есть ещё до того, как их
  можно задать с помощью данной директивы.
  Исключением из этого является упомянутое выше
  обновление исполняемого файла на лету.

Если переменная TZ не описана явно, то она всегда наследуется
и всегда доступна модулю
ngx_http_perl_module.

Пример использования:

env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;

Переменная окружения NGINX используется для внутренних целей nginx
и не должна устанавливаться непосредственно самим пользователем.

error_log logs/error.log error;

Конфигурирует запись в лог.
На одном уровне конфигурации может использоваться несколько логов (1.5.2).
Если на уровне конфигурации main запись лога в файл
явно не задана, то используется файл по умолчанию.

Первый параметр задаёт файл, который будет хранить лог.

Специальное значение stderr выбирает стандартный файл ошибок.
Запись в syslog настраивается указанием префикса
“syslog:”.
Запись в
кольцевой буфер в памяти
настраивается указанием префикса “memory:” и
размера буфера и как правило используется для отладки (1.7.11).

Второй параметр определяет уровень лога
и может принимать одно из следующих значений:
debug, info, notice,
warn, error, crit,
alert или emerg.
Уровни лога, указанные выше, перечислены в порядке возрастания важности.
При установке определённого уровня в лог попадают все сообщения
указанного уровня и уровней большей важности.
Например, при стандартном уровне error в лог попадают
сообщения уровней error, crit,
alert и emerg.
Если этот параметр не задан, используется error.

Для работы уровня лога debug необходимо сконфигурировать
nginx с --with-debug,
см. “Отладочный лог”.

Директива может быть указана на
уровне stream
начиная с версии 1.7.11
и на уровне mail
начиная с версии 1.9.0.

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

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

Пример использования:

include mime.types;
include vhosts/*.conf;

Загружает динамический модуль.

Пример:

load_module modules/ngx_mail_module.so;

lock_file logs/nginx.lock;

Для реализации accept_mutex и сериализации доступа к
разделяемой памяти nginx использует механизм блокировок.
На большинстве систем блокировки реализованы с помощью атомарных
операций, и эта директива игнорируется.
Для остальных систем применяется механизм файлов блокировок.
Эта директива задаёт префикс имён файлов блокировок.

master_process on;

Определяет, будут ли запускаться рабочие процессы.
Эта директива предназначена для разработчиков nginx.

multi_accept off;

Если multi_accept выключен, рабочий процесс
за один раз будет принимать только одно новое соединение.
В противном случае рабочий процесс
за один раз будет принимать сразу все новые соединения.

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

pcre_jit off;

Разрешает или запрещает использование JIT-компиляции (PCRE JIT)
для регулярных выражений, известных на момент парсинга конфигурации.

Использование PCRE JIT способно существенно ускорить обработку
регулярных выражений.

Для работы JIT необходима библиотека PCRE версии 8.20 или выше,
собранная с параметром конфигурации --enable-jit.
При сборке библиотеки PCRE вместе с nginx (--with-pcre=),
для включения поддержки JIT необходимо использовать параметр
конфигурации --with-pcre-jit.

pid logs/nginx.pid;

Задаёт файл, в котором будет храниться номер (PID) главного процесса.

Задаёт название аппаратного SSL-акселератора.

thread_pool default threads=32 max_queue=65536;

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

Параметр threads
задаёт число потоков в пуле.

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

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

Пример использования:

timer_resolution 100ms;

Внутренняя реализация интервала зависит от используемого метода:

• фильтр EVFILT_TIMER при использовании kqueue;
• timer_create() при использовании eventport;
• и setitimer() во всех остальных случаях.

Задаёт метод, используемый для
обработки соединений.
Обычно нет необходимости задавать его явно, поскольку по умолчанию
nginx сам выбирает наиболее эффективный метод.

user nobody nobody;

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

worker_aio_requests 32;

При использовании aio
совместно с методом обработки соединений
epoll,
задаёт максимальное число ожидающих обработки операций
асинхронного ввода-вывода для одного рабочего процесса.

worker_connections 512;

Задаёт максимальное число соединений, которые одновременно
может открыть рабочий процесс.

Следует иметь в виду, что в это число входят все соединения
(в том числе, например, соединения с проксируемыми серверами),
а не только соединения с клиентами.
Стоит также учитывать, что фактическое число одновременных
соединений не может превышать действующего ограничения на
максимальное число открытых файлов,
которое можно изменить с помощью worker_rlimit_nofile.

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

Например,

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

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

worker_processes    2;
worker_cpu_affinity 0101 1010;

привязывает первый рабочий процесс к CPU0/CPU2,
а второй — к CPU1/CPU3.
Второй пример пригоден для hyper-threading.

Специальное значение auto (1.9.10) позволяет
автоматически привязать рабочие процессы к доступным процессорам:

worker_processes auto;
worker_cpu_affinity auto;

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

worker_cpu_affinity auto 01010101;

Директива доступна только на FreeBSD и Linux.

worker_priority 0;

Задаёт приоритет планирования рабочих процессов подобно тому,
как это делается командой nice: отрицательное
число
означает более высокий приоритет.
Диапазон возможных значений, как правило, варьируется от -20 до 20.

Пример использования:

worker_priority -10;

worker_processes 1;

Задаёт число рабочих процессов.

Оптимальное значение зависит от множества факторов, включая
(но не ограничиваясь ими) число процессорных ядер, число
жёстких дисков с данными и картину нагрузок.
Если затрудняетесь в выборе правильного значения, можно начать
с установки его равным числу процессорных ядер
(значение “auto” пытается определить его
автоматически).

Параметр auto поддерживается только начиная
с версий 1.3.8 и 1.2.5.

Изменяет ограничение на наибольший размер core-файла
(RLIMIT_CORE) для рабочих процессов.
Используется для увеличения ограничения без перезапуска главного процесса.

Изменяет ограничение на максимальное число открытых файлов
(RLIMIT_NOFILE) для рабочих процессов.
Используется для увеличения ограничения без перезапуска главного процесса.

Задаёт таймаут в секундах для плавного завершения рабочих процессов.
По истечении указанного времени
nginx попытается закрыть все открытые соединения
для ускорения завершения.

Задаёт каталог, который будет текущим для рабочего процесса.
Основное применение — запись core-файла, в этом случае рабочий
процесс должен иметь права на запись в этот каталог.

Configuring Logging

Capture detailed information about errors and request processing in log files, either locally or via syslog.

This article describes how to configure logging of errors and processed requests in NGINX Open Source and NGINX Plus.

Setting Up the Error Log

NGINX writes information about encountered issues of different severity levels to the error log. The error_log directive sets up logging to a particular file, stderr , or syslog and specifies the minimal severity level of messages to log. By default, the error log is located at logs/error.log (the absolute path depends on the operating system and installation), and messages from all severity levels above the one specified are logged.

The configuration below changes the minimal severity level of error messages to log from error to warn :

In this case, messages of warn , error crit , alert , and emerg levels are logged.

The default setting of the error log works globally. To override it, place the error_log directive in the main (top-level) configuration context. Settings in the main context are always inherited by other configuration levels ( http , server , location ). The error_log directive can be also specified at the http, stream, server and location levels and overrides the setting inherited from the higher levels. In case of an error, the message is written to only one error log, the one closest to the level where the error has occurred. However, if several error_log directives are specified on the same level, the message are written to all specified logs.

Note: The ability to specify multiple error_log directives on the same configuration level was added in NGINX Open Source version 1.5.2.

Setting Up the Access Log

NGINX writes information about client requests in the access log right after the request is processed. By default, the access log is located at logs/access.log, and the information is written to the log in the predefined combined format. To override the default setting, use the log_format directive to change the format of logged messages, as well as the access_log directive to specify the location of the log and its format. The log format is defined using variables.

The following examples define the log format that extends the predefined combined format with the value indicating the ratio of gzip compression of the response. The format is then applied to a virtual server that enables compression.

Another example of the log format enables tracking different time values between NGINX and an upstream server that may help to diagnose a problem if your website experience slowdowns. You can use the following variables to log the indicated time values:

• $upstream_connect_time – The time spent on establishing a connection with an upstream server
• $upstream_header_time – The time between establishing a connection and receiving the first byte of the response header from the upstream server
• $upstream_response_time – The time between establishing a connection and receiving the last byte of the response body from the upstream server
• $request_time – The total time spent processing a request

All time values are measured in seconds with millisecond resolution.

When reading the resulting time values, keep the following in mind:

• When a request is processed through several servers, the variable contains several values separated by commas
• When there is an internal redirect from one upstream group to another, the values are separated by semicolons
• When a request is unable to reach an upstream server or a full header cannot be received, the variable contains 0 (zero)
• In case of internal error while connecting to an upstream or when a reply is taken from the cache, the variable contains — (hyphen)

Logging can be optimized by enabling the buffer for log messages and the cache of descriptors of frequently used log files whose names contain variables. To enable buffering use the buffer parameter of the access_log directive to specify the size of the buffer. The buffered messages are then written to the log file when the next log message does not fit into the buffer as well as in some other cases.

To enable caching of log file descriptors, use the open_log_file_cache directive.

Similar to the error_log directive, the access_log directive defined on a particular configuration level overrides the settings from the previous levels. When processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. If one level defines multiple access logs, the message is written to all of them.

Enabling Conditional Logging

Conditional logging allows excluding trivial or unimportant log entries from the access log. In NGINX, conditional logging is enabled by the if parameter to the access_log directive.

This example excludes requests with HTTP status codes 2xx (Success) and 3xx (Redirection):

Usecase: Sampling TLS Parameters

Many clients use TLS versions older than TLS 1.3. Though many ciphers are declared insecure, older implementations still use them; ECC certificates offer greater performance than RSA, but not all clients can accept ECC. Many TLS attacks rely on a “man in the middle” who intercepts the cipher negotiation handshake and forces the client and server to select a less secure cipher. Therefore, it’s important to configure NGINX Plus to not support weak or legacy ciphers, but doing so may exclude legacy clients.

You can evaluate the SSL data obtained from the client and determine what proportion of clients get excluded if support for older SSL protocols and ciphers is removed.

The following configuration example logs the SSL protocol, cipher, and User-Agent header of any connected TLS client, assuming that each client selects the most recent protocol and most secure ciphers it supports.

In this example, each client is identified by its unique combination of IP address and User-Agent.

Define the custom log format sslparams that includes the version of the SSL protocol ( $ssl_protocol ), ciphers used in the connection ( $ssl_cipher ), the client IP address ( $remote_addr ), and the value of standard User Agent HTTP request field ( $http_user_agent ):

Define a key-value storage that will keep the IP address of the client and its User Agent, for example, clients :

Create a variable, for example, $seen for each unique combination of $remote_addr and User-Agent header:

View the log file generated with this configuration:

Process the log file to determine the spread of data:

In this output, low‑volume, less secure ciphers are identified:

Then you can check the logs to determine which clients are using these ciphers and then make a decision about removing these ciphers from the NGINX Plus configuration.

For more information about sampling requests with NGINX conditional logging see the blog post.

Logging to Syslog

The syslog utility is a standard for computer message logging and allows collecting log messages from different devices on a single syslog server. In NGINX, logging to syslog is configured with the syslog: prefix in error_log and access_log directives.

Syslog messages can be sent to a server= which can be a domain name, an IP address, or a UNIX-domain socket path. A domain name or IP address can be specified with a port to override the default port, 514 . A UNIX-domain socket path can be specified after the unix: prefix:

In the example, NGINX error log messages are written to a UNIX domain socket at the debug logging level, and the access log is written to a syslog server with an IPv6 address and port 1234 .

The facility= parameter specifies the type of program that is logging the message. The default value is local7 . Other possible values are: auth , authpriv , daemon , cron , ftp , lpr , kern , mail , news , syslog , user , uucp , local0 . local7 .

The tag= parameter applies a custom tag to syslog messages ( nginx in our example).

The severity= parameter sets the severity level of syslog messages for access log. Possible values in order of increasing severity are: debug , info , notice , warn , error (default), crit , alert , and emerg . Messages are logged at the specified level and all more severe levels. In our example, the severity level error also enables crit , alert , and emerg levels to be logged.

Live Activity Monitoring

NGINX Plus provides a real-time live activity monitoring interface that shows key load and performance metrics of your HTTP and TCP upstream servers. See the Live Activity Monitoring article for more information.

To learn more about NGINX Plus, please visit the Products page.

Источник

Модуль ngx_http_log_module

Модуль ngx_http_log_module записывает логи запросов в указанном формате.

Логи записываются в контексте location’а, где заканчивается обработка. Это может быть location, отличный от первоначального, если в процессе обработки запроса происходит внутреннее перенаправление.

Пример конфигурации

Директивы

Задаёт путь, формат и настройки буферизованной записи в лог. На одном уровне конфигурации может использоваться несколько логов. Запись в syslog настраивается указанием префикса “ syslog: ” в первом параметре. Специальное значение off отменяет все директивы access_log для текущего уровня. Если формат не указан, то используется предопределённый формат “ combined ”.

Если задан размер буфера с помощью параметра buffer или указан параметр gzip (1.3.10, 1.2.7), то запись будет буферизованной.

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

При включённой буферизации данные записываются в файл:

• если очередная строка лога не помещается в буфер;
• если данные в буфере находятся дольше интервала времени, заданного параметром flush (1.3.10, 1.2.7);
• при переоткрытии лог-файла или завершении рабочего процесса.

Если задан параметр gzip , то буфер будет сжиматься перед записью в файл. Степень сжатия может быть задана в диапазоне от 1 (быстрее, но хуже сжатие) до 9 (медленнее, но лучше сжатие). По умолчанию используются буфер размером 64К байт и степень сжатия 1. Данные сжимаются атомарными блоками, и в любой момент времени лог-файл может быть распакован или прочитан с помощью утилиты “ zcat ”.

Для поддержки gzip-сжатия логов nginx должен быть собран с библиотекой zlib.

В пути файла можно использовать переменные (0.7.6+), но такие логи имеют некоторые ограничения:

• пользователь, с правами которого работают рабочие процессы, должен иметь права на создание файлов в каталоге с такими логами;
• не работает буферизация;
• файл открывается для каждой записи в лог и сразу же после записи закрывается. Следует однако иметь в виду, что поскольку дескрипторы часто используемых файлов могут храниться в кэше, то при вращении логов в течение времени, заданного параметром valid директивы open_log_file_cache, запись может продолжаться в старый файл.
• при каждой записи в лог проверяется существование корневого каталога для запроса — если этот каталог не существует, то лог не создаётся. Поэтому root и access_log нужно описывать на одном уровне конфигурации:

Параметр if (1.7.0) включает условную запись в лог. Запрос не будет записываться в лог, если результатом вычисления условия является “0” или пустая строка. В следующем примере запросы с кодами ответа 2xx и 3xx не будут записываться в лог:

Задаёт формат лога.

Параметр escape (1.11.8) позволяет задать экранирование символов json или default в переменных, по умолчанию используется default . Значение none (1.13.10) отключает экранирование символов.

При использовании default символы “ » ”, “ ”, a также символы со значениями меньше 32 (0.7.0) или больше 126 (1.1.6) экранируются как “ xXX ”. Если значение переменной не найдено, то в качестве значения в лог будет записываться дефис (“ — ”).

При использовании json экранируются все символы, недопустимые в JSON строках: символы “ » ” и “ ” экранируются как “ » ” и “ \ ”, символы со значениями меньше 32 экранируются как “ n ”, “ r ”, “ t ”, “ b ”, “ f ” или “ u00XX ”.

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

$bytes_sent число байт, переданное клиенту $connection порядковый номер соединения $connection_requests текущее число запросов в соединении (1.1.18) $msec время в секундах с точностью до миллисекунд на момент записи в лог $pipe “ p ” если запрос был pipelined, иначе “ . ” $request_length длина запроса (включая строку запроса, заголовок и тело запроса) $request_time время обработки запроса в секундах с точностью до миллисекунд; время, прошедшее с момента чтения первых байт от клиента до момента записи в лог после отправки последних байт клиенту $status статус ответа $time_iso8601 локальное время в формате по стандарту ISO 8601 $time_local локальное время в Common Log Format

Строки заголовка, переданные клиенту, начинаются с префикса “ sent_http_ ”, например, $sent_http_content_range .

В конфигурации всегда существует предопределённый формат “ combined ”:

Задаёт кэш, в котором хранятся дескрипторы файлов часто используемых логов, имена которых заданы с использованием переменных. Параметры директивы:

max задаёт максимальное число дескрипторов в кэше; при переполнении кэша наименее востребованные (LRU) дескрипторы закрываются inactive задаёт время, после которого закэшированный дескриптор закрывается, если к нему не было обращений в течение этого времени; по умолчанию 10 секунд min_uses задаёт минимальное число использований файла в течение времени, заданного параметром inactive , после которого дескриптор файла будет оставаться открытым в кэше; по умолчанию 1 valid задаёт, через какое время нужно проверять, что файл ещё существует под тем же именем; по умолчанию 60 секунд off запрещает кэш

Источник