Puncte:0

syslog-ng: cum se configurează trimiterea de mesaje RFC5424 cu încadrare de numărare a octeților

drapel al

Vă rog să nu vă obosiți să citiți această întrebare. syslog-ng este deja configurat pentru a trimite mesaje RFC5424 cu încadrare de numărare de octeți în mod implicit. Am fost confuz de comportamentul altei componente. Această întrebare este invalidă.


Am o configurație OSE syslog-ng (v3.31.2):

@versiunea: 3.29
@include „scl.conf”
    
sursă s_network {
    udp(ip(0.0.0.0) port(514));
};
    
destinație d_network_telegraf {
    syslog(portul „telegraf”(601) transport(tcp));
};
    
Buturuga {
    sursa(s_network);
    destinație(d_network_telegraf);
};

Intenția este de a transmite RFC3164 mesaje syslog formatate primite pe portul UDP 514 și redirecționați-le ca RFC5424 mesaje formatate la Telegraf pe portul TCP 601.

Cu această configurație, syslog-ng pare să emită mesajele redirecționate ca RFC5424 cu încadrare netransparentă (încărcate cu octet) (mesajul începe cu un caracter ASCII <). Din păcate, Telegraf se așteaptă să primească mesaje cu încadrare care numără octeți (mesajul începe cu o cifră). RFC6587 acoperă acestea.

Deși este posibil să configurați telegraf pentru a se aștepta la încadrare netransparentă, aceasta nu pare să funcționeze corect. Înainte de a pătrunde în asta, aș dori să încerc alternativa, care este să configurez syslog-ng pentru a scoate mesajele RFC5424 cu încadrare de numărare a octeților. Acesta este oricum tipul de încadrare recomandat.

Cu toate acestea, nu pot găsi nimic în documentele syslog-ng despre asta. În aproape toate cazurile, documentația discută despre utilizarea syslog sofer pentru intrare, nu ieșire, și este aproape nici o mențiune de numărare a octeților.

Este posibil să configurați syslog-ng în acest mod?


EDITAȚI | ×

Aceasta este configurația exactă pe care o folosesc:

@versiunea: 3.29
@include „scl.conf”

Opțiuni {
    create-dirs(da);
    linii de culoare (1);
    timp-redeschidere(60);
};

sursă s_local {
    sistem();
    intern();
};

sursă s_network {
    udp(ip(0.0.0.0) port(514));
};

destinație d_local {
    fisier("/data/syslog-ng/var/log/messages");
    file("/data/syslog-ng/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3 ));
};

destinație d_network_files {
    fisier("/data/syslog-ng/var/log/messages-network");
    fisier("/data/syslog-ng/var/log/messages-network-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits (3));
};

destinație d_network_telegraf {
    syslog(portul „telegraf”(601) transport(tcp));
};

Buturuga {
    sursa(s_network);
    destinație(d_network_telegraf);
    destinație(d_network_files);
};

Iată un mesaj trimis de logger -i -d --server localhost acesta este un test la syslog-ng prin portul UDP 514:

0000 02 42 ac 15 00 09 02 42 69 3a f6 78 08 00 45 00 .B.....Bi:.x..E.
0010 00 a6 79 e7 40 00 40 11 68 2b ac 15 00 01 ac 15 ..y.@[email protected]+......
0020 00 09 b4 bd 02 02 00 92 58 d8 3c 31 33 3e 31 20 ........X.<13>1 
0030 32 30 32 31 2d 31 31 2d 31 38 54 31 32 3a 34 31 2021-11-18T12:41
0040 3a 35 39 2e 39 34 33 39 36 35 2b 31 33 3a 30 30 :59.943965+13:00
0050 20 6b 6f 72 69 6d 61 6b 6f 20 64 61 76 69 64 20 korimako david 
0060 36 38 38 31 34 30 20 2d 20 5b 74 69 6d 65 51 75 688140 - [timeQu
0070 61 6c 69 74 79 20 74 7a 4b 6e 6f 77 6e 3d 22 31 ality tzKnown="1
0080 22 20 69 73 53 79 6e 63 65 64 3d 22 31 22 20 73 " isSynced="1" s
0090 79 6e 63 41 63 63 75 72 61 63 79 3d 22 37 39 37 yncAccuracy="797
00a0 30 30 30 22 5d 20 74 68 69 73 20 69 73 20 61 20 000"] acesta este un 
00b0 74 65 73 74 test

Și iată un mesaj capturat între syslog-ng și telegraf (portul TCP 601):

0000 02 42 ac 15 00 07 02 42 ac 15 00 09 08 00 45 00 .B.....B......E.
0010 00 ec ba 61 40 00 40 06 27 70 ac 15 00 09 ac 15 ...a@.@.'p......
0020 00 07 a7 ab 02 59 be 1c 32 98 d1 f9 90 93 80 18 .....Y..2.......
0030 01 f6 59 19 00 00 01 01 08 0a 0c 3e 2a 2d 7a e2 ..Y........>*-z.
0040 58 de 3c 31 33 3e 31 20 32 30 32 31 2d 31 31 2d X.<13>1 2021-11-
0050 31 37 54 32 33 3a 34 31 3a 35 39 2b 30 30 3a 30 17T23:41:59+00:0
0060 30 20 31 37 32 2e 32 31 2e 30 2e 31 20 31 20 2d 0 172.21.0.1 1 -
0070 20 2d 20 2d 20 32 30 32 31 2d 31 31 2d 31 38 54 - - 2021-11-18T
0080 31 32 3a 34 31 3a 35 39 2e 39 34 33 39 36 35 2b 12:41:59.943965+
0090 31 33 3a 30 30 20 6b 6f 72 69 6d 61 6b 6f 20 64 13:00 korimako d
00a0 61 76 69 64 20 36 38 38 31 34 30 20 2d 20 5b 74 avid 688140 - [t
00b0 69 6d 65 51 75 61 6c 69 74 79 20 74 7a 4b 6e 6f imeQuality tzKno
00c0 77 6e 3d 22 31 22 20 69 73 53 79 6e 63 65 64 3d wn="1" isSynced=
00d0 22 31 22 20 73 79 6e 63 41 63 63 75 72 61 63 79 Sincronizare „1” Precizie
00e0 3d 22 37 39 37 30 30 30 22 5d 20 74 68 69 73 20 ="797000"] aceasta 
00f0 69 73 20 61 20 74 65 73 74 0a este un test.

Puteți vedea că mesajul, care începe cu octetul 66 (0x42), începe cu a < caracter (<13>1 2021...). Conform RFC6587, aceasta este interpretată nu ca o încadrare care numără octeți, ci ca o alternativă: încadrare netransparentă.

Jurnalul complet al syslog-ng pentru acest eveniment este:

[2021-11-17T23:41:59.944928] Intrare jurnal de intrare; line='<13>1 2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="797000"] acesta este un test'
[2021-11-17T23:41:59.987236] Mesaj de ieșire; message='2021-11-17T23:41:59.944+00:00 172.21.0.1 HOST=172.21.0.1 HOST_FROM=172.21.0.1 LEGACY_MSGHDR="1 " MESSAGE="2021-11-11-18:092.21.0.1 korimako david 688140 - [timeQuality tzKnown=\"1\" isSynced=\"1\" syncAccuracy=\"797000\"] acesta este un test" PROGRAM=1 SOURCE=s_network\x0a'
[2021-11-17T23:41:59.987403] Mesaj de ieșire; message='Nov 17 23:41:59 172.21.0.1 1 2021-11-18T12:41:59.943965+13:00 korimako david 688140 - [timeQuality tzKnown="1" isSynced="0"" this syncAccuracy="0"7 este un test\x0a'
[2021-11-17T23:42:31.994550] Conexiune Syslog stabilită; fd='12', server='AF_INET(172.21.0.7:601)', local='AF_INET(0.0.0.0:0)'
[2021-11-17T23:42:31.994946] Mesaj de ieșire; message='<13>1 2021-11-17T23:41:59+00:00 172.21.0.1 1 - - - 2021-11-18T12:41:59.943965+13:00 korimako david 688140="1 - tz " isSynced="1" syncAccuracy="797000"] acesta este un test\x0a'
[2021-11-17T23:42:36.996059] EOF a apărut în timpul inactiv; fd='12'
[2021-11-17T23:42:36.996187] Conexiune Syslog închisă; fd='12', server='AF_INET(172.21.0.7:601)', time_reopen='60'
[2021-11-17T23:43:36.996635] Conexiune Syslog stabilită; fd='12', server='AF_INET(172.21.0.7:601)', local='AF_INET(0.0.0.0:0)'

UPDATE 1: Am găsit valoarea lipsă de numărare a octeților la începutul mesajului - este într-un cadru TCP precedent. Cred că acest lucru înseamnă că rezultatul de la syslog-ng folosește încadrarea cu numărare de octeți, până la urmă. Acum depanez activ sursa telegraf pentru că cred că primește mesajul, dar închide eronat conexiunea după aceea. Voi actualiza asta pe măsură ce descopăr mai multe.


UPDATE 2: Am stabilit că pluginul telegraf syslog are fie o eroare, fie o greșeală în documentația sa și deconectează orice conexiuni TCP de intrare care sunt inactive mai mult de 5 secunde. Nu este o problemă de analiză, ci doar un timeout.

Prin urmare, nu există nicio problemă cu syslog-ng și întreaga întrebare este nulă.

Puncte:0
drapel vn

syslog-ng poate fi configurat să accepte toate combinațiile: formatele RFC3164 sau RFC5424, cu sau fără tehnica de încadrare definită în RFC6587.

syslog() folosește încadrarea RFC6587 (numărarea octetilor) și preferă RFC5424 ca format de mesaj, dar se întoarce la RFC3164 pe partea sursă, când analiza RFC5424 eșuează.

reţea() operează fără cadre (fără numărare octeți - aceasta se numește „Non-Transparent-Framing” în RFC) și implicit este RFC3164, dar aceasta poate fi schimbată (la RFC5424) cu steaguri (protocol-syslog) steag.

drapel al
Când utilizați `syslog()` sau `network(... flags(syslog-protocol))`, cum comutați între modurile de numărare a octeților și cele netransparente (umplutură de octeți)? În prezent, folosesc `syslog()` și pare să fie doar netransparent. Ambele moduri sunt acoperite de RFC6587. Poate că există o opțiune specială pentru a trece la numărarea octeților? Totuși, nu găsesc nimic în documente despre asta.
MrAnno avatar
drapel vn
syslog() ar trebui să utilizeze contorizarea octeților, în timp ce network() folosește vechea metodă „non-transparent-framing” (separă mesajele cu \n).
MrAnno avatar
drapel vn
Dacă nu este cazul, este posibil să fi găsit o eroare. Folosești exact aceeași configurație pe care ai partajat-o?
drapel al
Am actualizat textul întrebării mele pentru a include configurația completă pe care o folosesc, împreună cu câteva capturi wireshark și jurnalele de consolă syslog-ng corespunzătoare. Anunță-mă dacă ar mai fi util să văd ceva.
drapel al
O altă actualizare - am găsit prefixul „[digits]” de numărare a octeților „lipsă” într-un cadru TCP precedent, deci este acolo în flux. Mi-a fost dor de asta. Deci, aceasta înseamnă că syslog-ng *este* scoate la ieșire încadrare de numărare a octeților, așa cum era de așteptat. Cred că există cu siguranță o problemă cu modul în care telegraf gestionează aceste mesaje, deoarece închide în mod activ conexiunea după fiecare mesaj din cauza unui timeout. Depanez asta acum. Oricum, @MrAnno, îți mulțumesc pentru timpul acordat pentru a răspunde la asta și scuze că l-am pierdut.
MrAnno avatar
drapel vn
Plăcerea este de partea mea. Hmm, interesant. Există ceva care ar putea fi interesant pentru tine: În cazul în care telegraf trimite ceva înapoi la syslog-ng, comportamentul implicit este de a închide conexiunea, deoarece driverele network(), syslog() nu așteaptă răspunsuri de la server. Dacă acesta este cazul, puteți încerca următoarea opțiune nedocumentată: `close-on-input(no)`.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.