Очереди RSyslog: принципы работы и настройка на примере передачи событий NGINX

5 | 21.09.2026 16:27 | #Audit #Nginx #WEB #RSyslog

Общие сведения.

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

В рассматриваемом примере Nginx передаёт события локально в RSyslog через Unix-сокет /dev/log, после чего RSyslog отправляет их на удалённый сервер.

Схема передачи:

Nginx → /dev/log → RSyslog → очередь → удалённый сервер.

Примечание. Указан один из вариантов отправки событий Nginx на удаленный сервер.

Передача событий из Nginx.

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

   access_log syslog:server=unix:/dev/log,facility=local3,tag=nginx_access,severity=info combined;
   error_log  syslog:server=unix:/dev/log,facility=local3,tag=nginx_error warn;

Где:

access_log — директива Nginx для настройки журналирования HTTP-запросов, в данном случае определяет передачу событий Access в Syslog;
error_log — директива Nginx для настройки журнала ошибок, в данном случае определяет передачу событий Error в Syslog;
syslog: — указывает Nginx использовать Syslog в качестве назначения для журнала вместо обычного файла;
server=unix:/dev/log — определяет адрес Syslog-сервера, значение unix:/dev/log указывает на передачу сообщений локальному Syslog-сервису через Unix-сокет /dev/log;
unix: — указывает, что для передачи используется локальный Unix domain socket, а не сетевое соединение TCP/UDP;
/dev/log — стандартный Unix-сокет, через который приложения передают Syslog-сообщения локальной службе журналирования, в данном случае RSyslog;
facility=local3 — задаёт Syslog facility local3, что позволяет классифицировать события и может использоваться RSyslog для их фильтрации и маршрутизации;
tag=nginx_access — задаёт Syslog-тег для событий access_log, позволяющий идентифицировать их в RSyslog;
tag=nginx_error — задаёт Syslog-тег для событий error_log;
severity=info — задаёт Syslog severity info для сообщений access_log;
combined — имя формата access_log;
warn — минимальный уровень ошибок Nginx, которые будут передаваться через указанную директиву error_log.

ПРИМЕЧАНИЕ.
Unix-сокет /dev/log используется только для локальной передачи сообщения в RSyslog и не является дисковой очередью или файлом хранения событий.
Параметры severity=info и warn выполняют разные функции. severity=info в access_log задаёт Syslog severity отправляемого сообщения, тогда как warn в error_log определяет минимальный уровень ошибок NGINX, которые должны журналироваться.

Очередь RSyslog.

Для отправки событий на удалённый сервер может использоваться Disk-Assisted очередь, ниже приведен пример двух параметров двух очередей для access_log и error_log в конфигурационном файле RSyslog в директории /etc/rsyslog.d/:

    action(
		...
        queue.type="LinkedList"
        queue.filename="nginx_access"
        queue.size="50000"
        queue.highWatermark="40000"
        queue.lowWatermark="20000"
        queue.maxdiskspace="1g"
        queue.saveonshutdown="on"
        action.resumeRetryCount="-1"
        action.resumeInterval="5"
    )
   
   ...
   
       action(
		...
        queue.type="LinkedList"
        queue.filename="nginx_error"
        queue.size="20000"
        queue.highWatermark="16000"
        queue.lowWatermark="8000"
        queue.maxdiskspace="512m"
        queue.saveonshutdown="on"
        action.resumeRetryCount="-1"
        action.resumeInterval="5"
    )

Основные параметры.

queue.type — основная очередь типа LinkedList, работающая преимущественно в оперативной памяти;
queue.filename — задает имя файлов дисковой части и позволяет использовать Disk-Assisted Queue;
queue.size — максимальный размер основной очереди (50 000 сообщений);
queue.highWatermark — порог активации Disk-Assisted механизма;
queue.lowWatermark — нижний порог разгрузки основной очереди;
queue.maxDiskSpace — максимальный объём дисковой части очереди;
queue.saveOnShutdown — сохранение сообщений очереди при штатной остановке RSyslog;
action.resumeRetryCount — неограниченное количество попыток восстановления отправки при значении "-1";
action.resumeInterval — базовый интервал повторных попыток восстановления действия (в секундах).

Работа очереди.

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

Если удалённый сервер становится недоступен, сообщения начинают накапливаться в основной очереди RSyslog (RAM или memory queue).

При достижении queue.highWatermark="40000" активируется Disk-Assisted механизм, и RSyslog начинает использовать дисковую часть очереди (запись в файл в директории /var/spool/rsyslog).

Разница между queue.size="50000" и queue.highWatermark="40000" составляет 10 000 сообщений (emergency buffer). Этот запас позволяет основной очереди продолжать принимать события, в том числе при кратковременном всплеске нагрузки, пока работает механизм переноса сообщений в дисковую очередь.

Параметр queue.lowWatermark="20000" определяет нижний порог разгрузки основной очереди и позволяет избежать слишком частого переключения Disk-Assisted механизма.

После восстановления доступности удалённого сервера RSyslog продолжает передачу накопленных событий.

Ограничение дискового пространства.

Параметр queue.maxDiskSpace="1g" ограничивает максимальный объём дисковой части очереди значением 1 Гбайт.

Размер очереди необходимо выбирать с учётом:

- количества событий в секунду (EPS);
- среднего размера события;
- доступного дискового пространства;
- возможных всплесков нагрузки;
- максимально допустимого времени недоступности удалённого сервера.

ВАЖНО! Disk-Assisted Queue предназначена для временной буферизации событий и не заменяет контроль свободного дискового пространства. Необходимо контролировать заполнение раздела, содержащего рабочую директорию RSyslog, а также объём локальных журналов Nginx.

Последовательность обработки событий в очереди.

В пределах одной очереди RSyslog события обрабатываются по принципу FIFO (First In, First Out) — события, поступившие в очередь раньше, обрабатываются раньше последующих событий.

Достижение queue.highWatermark и активация Disk-Assisted Queue не должны изменять логическую последовательность обработки событий. Дисковая часть является продолжением механизма очереди и используется для временного хранения накопившихся сообщений.

После восстановления доступности удалённого сервера накопленные события продолжают обрабатываться в порядке очереди.

Несколько независимых очередей.

Следует учитывать, что FIFO применяется в пределах конкретной очереди, а не ко всем событиям RSyslog в целом. Например, в рассматриваемой конфигурации Nginx используются две независимые очереди: для access_log и для error_log. При этом общая последовательность между двумя независимыми очередями не гарантируется. Каждая очередь имеет собственный механизм обработки, состояние, буферизацию и отправку.

ВАЖНО! При анализе последовательности событий необходимо ориентироваться на временную метку самого события. FIFO обеспечивает порядок обработки внутри отдельной очереди, но не формирует единую общую последовательность между несколькими независимыми очередями RSyslog.

Сводная информация.

Практический пример.

Удаленный сервер недоступен. Выполняем рестарт сервиса RSyslog и проверяем статус:

На скриншоте RSyslog успешно запущен, но есть важные сообщения о дисковых очередях:

nginx_access queue[DA]: queue files exist on disk, re-starting with 15 messages.
This will keep the disk queue file open

nginx_error queue[DA]: queue files exist on disk, re-starting with 4 messages.
This will keep the disk queue file open

Это означает, что при предыдущей работе RSyslog в дисковой очереди остались необработанные события:

nginx_access — 15 событий;
nginx_error — 4 события.

Содержимое директории /var/spool/rsyslog:

Примеры записей событий в файле nginx_access.00000001:

<Obj:1:msg:1:
+iProtocolVersion:2:1:0:
+iSeverity:2:1:6:
+iFacility:2:2:19:
+msgFlags:2:2:36:
+ttGenTime:2:10:1789990825:
+tRcvdAt:3:34:2:2026:9:21:16:40:25:85085:6:+:5:0:
+tTIMESTAMP:3:34:2:2026:9:21:16:40:25:85085:6:+:5:0:
+pszTAG:1:10:ubuntu-web:
+pszRawMsg:1:680:<158>Sep 21 16:40:25 ubuntu-web nginx_access: LEEF:1.0|NGINX|NGINX|1.28.3|200|devTime=21/Sep/2026:16:40:25 +0500#011devTimeFormat=dd/MMM/yyyy:HH:mm:ss Z#011src=192.168.0.146#011dst=192.168.0.219#011dstPort=443#011proto=HTTP/2.0#011usrName=-#011request=GET /account/login/?next=/studies/use-cases/ HTTP/2.0#011body_bytes_sent=2924#011http_referer=https://192.168.0.219/account/roles/#011http_true_client_ip=-#011http_user_agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:156.0) Gecko/20100101 Firefox/156.0#011http_x_header=-#011http_x_forwarded_for=-#011request_time=0.022#011upstream_response_time=0.022#011pipe=.#011uri_query=next=/studies/use-cases/#011uri_path=/account/login/#011:
+pszInputName:1:8:imuxsock:
+pszRcvFrom:1:10:ubuntu-web:
+pszRcvFromIP:1:9:127.0.0.1:
+localvars:1:642:{ "nginx_leef": "LEEF:1.0|NGINX|NGINX|1.28.3|200|devTime=21\/Sep\/2026:16:40:25 +0500\tdevTimeFormat=dd\/MMM\/yyyy:HH:mm:ss Z\tsrc=192.168.0.146\tdst=192.168.0.219\tdstPort=443\tproto=HTTP\/2.0\tusrName=-\trequest=GET \/account\/login\/?next=\/studies\/use-cases\/ HTTP\/2.0\tbody_bytes_sent=2924\thttp_referer=https:\/\/192.168.0.219\/account\/roles\/\thttp_true_client_ip=-\thttp_user_agent=Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:156.0) Gecko\/20100101 Firefox\/156.0\thttp_x_header=-\thttp_x_forwarded_for=-\trequest_time=0.022\tupstream_response_time=0.022\tpipe=.\turi_query=next=\/studies\/use-cases\/\turi_path=\/account\/login\/\t" }:
+offMSG:2:2:31:
>End
.
<Obj:1:msg:1:
+iProtocolVersion:2:1:0:
+iSeverity:2:1:6:
+iFacility:2:2:19:
+msgFlags:2:2:36:
+ttGenTime:2:10:1789990826:
+tRcvdAt:3:35:2:2026:9:21:16:40:26:911130:6:+:5:0:
+tTIMESTAMP:3:35:2:2026:9:21:16:40:26:911130:6:+:5:0:
+pszTAG:1:10:ubuntu-web:
+pszRawMsg:1:655:<158>Sep 21 16:40:26 ubuntu-web nginx_access: LEEF:1.0|NGINX|NGINX|1.28.3|302|devTime=21/Sep/2026:16:40:26 +0500#011devTimeFormat=dd/MMM/yyyy:HH:mm:ss Z#011src=192.168.0.146#011dst=192.168.0.219#011dstPort=443#011proto=HTTP/2.0#011usrName=-#011request=POST /account/login/ HTTP/2.0#011body_bytes_sent=0#011http_referer=https://192.168.0.219/account/login/?next=/studies/use-cases/#011http_true_client_ip=-#011http_user_agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:156.0) Gecko/20100101 Firefox/156.0#011http_x_header=-#011http_x_forwarded_for=-#011request_time=0.252#011upstream_response_time=0.252#011pipe=.#011uri_query=-#011uri_path=/account/login/#011:
+pszInputName:1:8:imuxsock:
+pszRcvFrom:1:10:ubuntu-web:
+pszRcvFromIP:1:9:127.0.0.1:
+localvars:1:614:{ "nginx_leef": "LEEF:1.0|NGINX|NGINX|1.28.3|302|devTime=21\/Sep\/2026:16:40:26 +0500\tdevTimeFormat=dd\/MMM\/yyyy:HH:mm:ss Z\tsrc=192.168.0.146\tdst=192.168.0.219\tdstPort=443\tproto=HTTP\/2.0\tusrName=-\trequest=POST \/account\/login\/ HTTP\/2.0\tbody_bytes_sent=0\thttp_referer=https:\/\/192.168.0.219\/account\/login\/?next=\/studies\/use-cases\/\thttp_true_client_ip=-\thttp_user_agent=Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:156.0) Gecko\/20100101 Firefox\/156.0\thttp_x_header=-\thttp_x_forwarded_for=-\trequest_time=0.252\tupstream_response_time=0.252\tpipe=.\turi_query=-\turi_path=\/account\/login\/\t" }:
+offMSG:2:2:31:
>End
.

Примечание. В файле nginx_access.00000001 события отправляются в формате LEEF.