Nginx error log off

OP’s problem was a syntax error, which is explained in this answer.

As of January 2020, with nginx 1.14.0+ the general problem of disabling access and error logging in nginx is solved as follows:

Access logs

To disable logs on some configuration level, assuming that it has been explicitly enabled on a higher one or are enabled by default (as they are), use this directive*:

access_log off;

(Answers saying that you should redirect this kind of logs to /dev/null are outdated.)

Note that the access_log directive may be set multiple times on a single level but the above entry disables all access log logging on the current level.

Source: nginx docs for access_log

Error logs

Disabling error logs is more tricky as there is NO explicit option to turn it off on a lower configuration level, if it has been enabled on a higher one or it is enabled by default (as it is)!

So in this case you should use what this answer proposed:

error_log /dev/null;

Source: nginx docs for error_log

Caveats

Imagine that you have a single http with access log enabled on this level, and inside multiple server entries and one of these servers is an entry point to all others. Let’s say you have one server with SSL configured that listens for connections from outside with HTTPS and it redirects them to other servers which are various API gateways.

Then it’s not enough to disable access logs in some of the API gateway servers (or their locations) as the request will be still logged in the access log of the external HTTPS server.

Bad example:

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

  server {
    listen 80;
    location /app1 {
      proxy_pass http://localhost:81;
    }
    (...)
  }

  server {
    listen 81;
    access_log off; # <----- this WON'T effectively work - requests will be logged in the access log by the server above
    (...)
  }
  (...)
}

You would have to disable access logs on the whole paths of given requests to make it work in this case. But of course a better solution would be to consider simplifying your config as you may run into many more surprises even after you solve the problem with access logs…

Simpler config example:

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

  server {
    listen 80;
    location /app1 {
      access_log off; # <----- this WILL work
      proxy_pass http://app1server;
    }
    (...)
  }

}

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

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

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-файла, в этом случае рабочий
процесс должен иметь права на запись в этот каталог.

OP’s problem was a syntax error, which is explained in this answer.

As of January 2020, with nginx 1.14.0+ the general problem of disabling access and error logging in nginx is solved as follows:

Access logs

To disable logs on some configuration level, assuming that it has been explicitly enabled on a higher one or are enabled by default (as they are), use this directive*:

access_log off;

(Answers saying that you should redirect this kind of logs to /dev/null are outdated.)

Note that the access_log directive may be set multiple times on a single level but the above entry disables all access log logging on the current level.

Source: nginx docs for access_log

Error logs

Disabling error logs is more tricky as there is NO explicit option to turn it off on a lower configuration level, if it has been enabled on a higher one or it is enabled by default (as it is)!

So in this case you should use what this answer proposed:

error_log /dev/null;

Source: nginx docs for error_log

Caveats

Imagine that you have a single http with access log enabled on this level, and inside multiple server entries and one of these servers is an entry point to all others. Let’s say you have one server with SSL configured that listens for connections from outside with HTTPS and it redirects them to other servers which are various API gateways.

Then it’s not enough to disable access logs in some of the API gateway servers (or their locations) as the request will be still logged in the access log of the external HTTPS server.

Bad example:

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

  server {
    listen 80;
    location /app1 {
      proxy_pass http://localhost:81;
    }
    (...)
  }

  server {
    listen 81;
    access_log off; # <----- this WON'T effectively work - requests will be logged in the access log by the server above
    (...)
  }
  (...)
}

You would have to disable access logs on the whole paths of given requests to make it work in this case. But of course a better solution would be to consider simplifying your config as you may run into many more surprises even after you solve the problem with access logs…

Simpler config example:

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

  server {
    listen 80;
    location /app1 {
      access_log off; # <----- this WILL work
      proxy_pass http://app1server;
    }
    (...)
  }

}

Core functionality

Example Configuration

Directives

If accept_mutex is enabled, worker processes will accept new connections by turn. Otherwise, all worker processes will be notified about new connections, and if volume of new connections is low, some of the worker processes may just waste system resources.

There is no need to enable accept_mutex on systems that support the EPOLLEXCLUSIVE flag (1.11.3) or when using reuseport.

Prior to version 1.11.3, the default value was on .

If accept_mutex is enabled, specifies the maximum time during which a worker process will try to restart accepting new connections if another worker process is currently accepting new connections.

Determines whether nginx should become a daemon. Mainly used during development.

Enables debugging log for selected client connections. Other connections will use logging level set by the error_log directive. Debugged connections are specified by IPv4 or IPv6 (1.3.0, 1.2.1) address or network. A connection may also be specified using a hostname. For connections using UNIX-domain sockets (1.3.0, 1.2.1), debugging log is enabled by the “ unix: ” parameter.

For this directive to work, nginx needs to be built with —with-debug , see “A debugging log”.

This directive is used for debugging.

When internal error is detected, e.g. the leak of sockets on restart of working processes, enabling debug_points leads to a core file creation ( abort ) or to stopping of a process ( stop ) for further analysis using a system debugger.

By default, nginx removes all environment variables inherited from its parent process except the TZ variable. This directive allows preserving some of the inherited variables, changing their values, or creating new environment variables. These variables are then:

• inherited during a live upgrade of an executable file;
• used by the ngx_http_perl_module module;
• used by worker processes. One should bear in mind that controlling system libraries in this way is not always possible as it is common for libraries to check variables only during initialization, well before they can be set using this directive. An exception from this is an above mentioned live upgrade of an executable file.

The TZ variable is always inherited and available to the ngx_http_perl_module module, unless it is configured explicitly.

The NGINX environment variable is used internally by nginx and should not be set directly by the user.

Configures logging. Several logs can be specified on the same configuration level (1.5.2). If on the main configuration level writing a log to a file is not explicitly defined, the default file will be used.

The first parameter defines a file that will store the log. The special value stderr selects the standard error file. Logging to syslog can be configured by specifying the “ syslog: ” prefix. Logging to a cyclic memory buffer can be configured by specifying the “ memory: ” prefix and buffer size , and is generally used for debugging (1.7.11).

The second parameter determines the level of logging, and can be one of the following: debug , info , notice , warn , error , crit , alert , or emerg . Log levels above are listed in the order of increasing severity. Setting a certain log level will cause all messages of the specified and more severe log levels to be logged. For example, the default level error will cause error , crit , alert , and emerg messages to be logged. If this parameter is omitted then error is used.

For debug logging to work, nginx needs to be built with —with-debug , see “A debugging log”.

The directive can be specified on the stream level starting from version 1.7.11, and on the mail level starting from version 1.9.0.

Provides the configuration file context in which the directives that affect connection processing are specified.

Includes another file , or files matching the specified mask , into configuration. Included files should consist of syntactically correct directives and blocks.

This directive appeared in version 1.9.11.

Loads a dynamic module.

nginx uses the locking mechanism to implement accept_mutex and serialize access to shared memory. On most systems the locks are implemented using atomic operations, and this directive is ignored. On other systems the “lock file” mechanism is used. This directive specifies a prefix for the names of lock files.

Determines whether worker processes are started. This directive is intended for nginx developers.

If multi_accept is disabled, a worker process will accept one new connection at a time. Otherwise, a worker process will accept all new connections at a time.

The directive is ignored if kqueue connection processing method is used, because it reports the number of new connections waiting to be accepted.

This directive appeared in version 1.1.12.

Enables or disables the use of “just-in-time compilation” (PCRE JIT) for the regular expressions known by the time of configuration parsing.

PCRE JIT can speed up processing of regular expressions significantly.

The JIT is available in PCRE libraries starting from version 8.20 built with the —enable-jit configuration parameter. When the PCRE library is built with nginx ( —with-pcre= ), the JIT support is enabled via the —with-pcre-jit configuration parameter.

Defines a file that will store the process ID of the main process.

Defines the name of the hardware SSL accelerator.

This directive appeared in version 1.7.11.

Defines the name and parameters of a thread pool used for multi-threaded reading and sending of files without blocking worker processes.

The threads parameter defines the number of threads in the pool.

In the event that all threads in the pool are busy, a new task will wait in the queue. The max_queue parameter limits the number of tasks allowed to be waiting in the queue. By default, up to 65536 tasks can wait in the queue. When the queue overflows, the task is completed with an error.

Reduces timer resolution in worker processes, thus reducing the number of gettimeofday() system calls made. By default, gettimeofday() is called each time a kernel event is received. With reduced resolution, gettimeofday() is only called once per specified interval .

Internal implementation of the interval depends on the method used:

• the EVFILT_TIMER filter if kqueue is used;
• timer_create() if eventport is used;
• setitimer() otherwise.

Specifies the connection processing method to use. There is normally no need to specify it explicitly, because nginx will by default use the most efficient method.

Defines user and group credentials used by worker processes. If group is omitted, a group whose name equals that of user is used.

This directive appeared in versions 1.1.4 and 1.0.7.

When using aio with the epoll connection processing method, sets the maximum number of outstanding asynchronous I/O operations for a single worker process.

Sets the maximum number of simultaneous connections that can be opened by a worker process.

It should be kept in mind that this number includes all connections (e.g. connections with proxied servers, among others), not only connections with clients. Another consideration is that the actual number of simultaneous connections cannot exceed the current limit on the maximum number of open files, which can be changed by worker_rlimit_nofile.

Binds worker processes to the sets of CPUs. Each CPU set is represented by a bitmask of allowed CPUs. There should be a separate set defined for each of the worker processes. By default, worker processes are not bound to any specific CPUs.

binds each worker process to a separate CPU, while

binds the first worker process to CPU0/CPU2, and the second worker process to CPU1/CPU3. The second example is suitable for hyper-threading.

The special value auto (1.9.10) allows binding worker processes automatically to available CPUs:

The optional mask parameter can be used to limit the CPUs available for automatic binding:

The directive is only available on FreeBSD and Linux.

Defines the scheduling priority for worker processes like it is done by the nice command: a negative number means higher priority. Allowed range normally varies from -20 to 20.

Defines the number of worker processes.

The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “ auto ” will try to autodetect it).

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

Changes the limit on the largest size of a core file ( RLIMIT_CORE ) for worker processes. Used to increase the limit without restarting the main process.

Changes the limit on the maximum number of open files ( RLIMIT_NOFILE ) for worker processes. Used to increase the limit without restarting the main process.

This directive appeared in version 1.11.11.

Configures a timeout for a graceful shutdown of worker processes. When the time expires, nginx will try to close all the connections currently open to facilitate shutdown.

Defines the current working directory for a worker process. It is primarily used when writing a core-file, in which case a worker process should have write permission for the specified directory.

Источник