RSyslog кезектері: жұмыс істеу принциптері және NGINX оқиғаларын жіберу мысалындағы баптау

4 | 21.09.2026 16:27 | #Audit #Nginx #WEB #RSyslog AI

Жалпы мәліметтер.

Журналдарды қашықтағы серверге жібергенде сервердің уақытша қол жетімсіз болуы ықтималдығын ескеру қажет. Оқиғалардың жоғалу қаупін азайту үшін RSyslog кезектер механизмін қолдайды.

Осы қарастырылып отырған мысалда Nginx оқиғаларды жергілікті түрде Unix-сокеті арқылы RSyslog-қа жібереді /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 — HTTP-сұраныстарды журналдауды баптауға арналған Nginx директивасы, осы жағдайда Access оқиғаларын Syslog-қа жіберуді анықтайды;
error_log — қате журналын баптауға арналған Nginx директивасы, осы жағдайда Error оқиғаларын Syslog-қа жіберуді анықтайды;
syslog: — Nginx-ке журнал мақсаты ретінде кәдімгі файл орнына Syslog қолдануды көрсетеді;
server=unix:/dev/log — Syslog-сервердің мекенжайын анықтайды, мәні unix:/dev/log жергілікті Syslog-қызметке Unix-сокеті арқылы хабарламаларды жіберуді көрсетеді /dev/log;
unix: — жіберу үшін желілік TCP/UDP байланысы емес, жергілікті Unix domain socket пайдаланылады дегенді көрсетеді;
/dev/log — қолданбалар жергілікті журналдау қызметіне Syslog-хабарламаларды беретін стандартты Unix-сокеті, осы жағдайда 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 қағидасы бойынша өңдейді — FIFO (First In, First Out) — кезекке ертерек түскен оқиғалар кейінгі оқиғалардан ертерек өңделеді.

Қол жеткізу queue.highWatermark және Disk-Assisted Queue іске қосылғанда оқиғалардың логикалық өңдеу реттілігі өзгермеуі тиіс. Дискілік бөлік кезек механизмің жалғасы болып табылады және жиналған хабарларды уақытша сақтау үшін қолданылады.

Қашықтағы сервер қолжетімділігі қалпына келгеннен кейін жиналған оқиғалар кезектік тәртіппен өңделуді жалғастырады.

Бірнеше тәуелсіз кезектер.

FIFO нақты бір кезек шеңберінде қолданылады, RSyslog-тың барлық оқиғалары үшін жалпы тәртіп қамтамасыз етілмейді. Мысалы, қарастырылып отырған Nginx конфигурациясында екі тәуелсіз кезек қолданылады: біреуі access_log үшін және екіншісі error_log. Осыған орай екі тәуелсіз кезек арасындағы жалпы реттілік кепілдендірілмейді. Әр кезектің өз өңдеу механизмі, күйі, буферленуі және жіберу процесі бар.

ВАЖНО! Оқиғалардың реттілігін талдағанда, негізгі назарды оқиғаның уақыт белгiсіне аудару қажет. 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

Бұл өткен жұмыста дискілік кезекте өңделмеген оқиғалардың қалғанын білдіреді:

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.

Файл nginx_access.00000001 ішіндегі оқиға жазбалары мысалдары:

<Obj:1:msg:1:
+iProtocolVersion:2:1:0:
+iSeverity:2:1:3:
+iFacility:2:2:19:
+msgFlags:2:2:36:
+ttGenTime:2:10:1789990902:
+tRcvdAt:3:35:2:2026:9:21:16:41:42:581529:6:+:5:0:
+tTIMESTAMP:3:35:2:2026:9:21:16:41:42:581529:6:+:5:0:
+pszTAG:1:10:ubuntu-web:
+pszRawMsg:1:377:<155>Sep 21 16:41:42 ubuntu-web nginx_error: 2026/09/21 16:41:42 [error] 35655#35655: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.146, server: 192.168.0.219, request: "GET /account/groups/ HTTP/2.0", upstream: "http://127.0.0.1:8001/account/groups/", host: "192.168.0.219", referrer: "https://192.168.0.219/app/insight/events/catalog/":
+pszInputName:1:8:imuxsock:
+pszRcvFrom:1:10:ubuntu-web:
+pszRcvFromIP:1:9:127.0.0.1:
+localvars:1:379:{ "nginx_error": "2026\/09\/21 16:41:42 [error] 35655#35655: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.146, server: 192.168.0.219, request: \"GET \/account\/groups\/ HTTP\/2.0\", upstream: \"http:\/\/127.0.0.1:8001\/account\/groups\/\", host: \"192.168.0.219\", referrer: \"https:\/\/192.168.0.219\/app\/insight\/events\/catalog\/\"" }:
+offMSG:2:2:31:
>End
.
<Obj:1:msg:1:
+iProtocolVersion:2:1:0:
+iSeverity:2:1:3:
+iFacility:2:2:19:
+msgFlags:2:2:36:
+ttGenTime:2:10:1789990904:
+tRcvdAt:3:35:2:2026:9:21:16:41:44:554737:6:+:5:0:
+tTIMESTAMP:3:35:2:2026:9:21:16:41:44:554737:6:+:5:0:
+pszTAG:1:10:ubuntu-web:
+pszRawMsg:1:377:<155>Sep 21 16:41:44 ubuntu-web nginx_error: 2026/09/21 16:41:44 [error] 35655#35655: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.146, server: 192.168.0.219, request: "GET /account/groups/ HTTP/2.0", upstream: "http://127.0.0.1:8001/account/groups/", host: "192.168.0.219", referrer: "https://192.168.0.219/app/insight/events/catalog/":
+pszInputName:1:8:imuxsock:
+pszRcvFrom:1:10:ubuntu-web:
+pszRcvFromIP:1:9:127.0.0.1:
+localvars:1:379:{ "nginx_error": "2026\/09\/21 16:41:44 [error] 35655#35655: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.146, server: 192.168.0.219, request: \"GET \/account\/groups\/ HTTP\/2.0\", upstream: \"http:\/\/127.0.0.1:8001\/account\/groups\/\", host: \"192.168.0.219\", referrer: \"https:\/\/192.168.0.219\/app\/insight\/events\/catalog\/\"" }:
+offMSG:2:2:31:
>End
.

Ескерту. Қашықтағы сервердің қолжетімділігі қалпына келгеннен кейін кезек файлдары келесі каталогта /var/spool/rsyslog/ дереу өшірілмеуі мүмкін. Бұл файлдардың болуы өздігінен кезекте жіберілмеген оқиғалар бар дегенді білдірмейді. Disk-Assisted Queue Қызметтік файлдар кезек босатылғаннан кейін де сақталуы мүмкін және, мысалы, RSyslog қызметін кейінірек қайта іске қосқан кезде жойылуы әбден мүмкін.