Am o slăbiciune - îmi plac diferitele sisteme de monitorizare. Adică, pentru mine, situația ideală este atunci când puteți vedea starea fiecărei componente a sistemului în orice moment. În timp real, totul este mai mult sau mai puțin clar: puteți agrega date și le puteți afișa pe un tablou de bord frumos. Lucrurile sunt mai complicate cu ceea ce s-a întâmplat în trecut, când trebuie să afli diferite evenimente la un moment dat și să le conectezi între ele.

Sarcina nu este de fapt atât de banală. În primul rând, trebuie să agregați jurnalele de la sisteme complet diferite, care adesea nu au nimic în comun între ele. În al doilea rând, ele trebuie să fie legate de aceeași scară de timp, astfel încât evenimentele să poată fi corelate între ele. Și în al treilea rând, este necesar să se organizeze eficient stocarea și căutarea acestei cantități uriașe de date. Totuși, așa cum se întâmplă de obicei, partea dificilă a fost deja rezolvată înaintea noastră. Încerc câteva opțiuni diferite, așa că voi face o mini-review a ceea ce am lucrat până acum.

Servicii on-line

Cea mai simplă opțiune, care a funcționat excelent pentru mine la început, este să folosesc un serviciu cloud. Astfel de instrumente se dezvoltă activ, oferind suport pentru un număr tot mai mare de stive de tehnologie și fiind adaptate la specificul sistemelor individuale IaaS/PaaS, cum ar fi AWS și Heroku.

Splunk

Atât eu, cât și Alexey Sintsov am scris recent despre acest serviciu într-o rubrică. În general, acesta nu este doar un agregator de jurnal, ci un sistem de analiză puternic, cu o istorie lungă. Prin urmare, sarcina de a colecta bușteni și de a le agrega pentru prelucrare și căutare ulterioară este o simplă pentru el. Există peste 400 de aplicații diferite, inclusiv peste o sută în domeniul managementului operațiunilor IT, care vă permit să colectați informații de pe serverele și aplicațiile dvs.

loggly

Acest serviciu este deja special conceput pentru analiza jurnalelor și vă permite să agregați orice tip de jurnal de text. Ruby, Java, Python, C/C++, JavaScript, PHP, Apache, Tomcat, MySQL, syslog-ng, rsyslog, nxlog, Snare, routere și comutatoare - nu contează. Puteți colecta până la 200 MB pe zi gratuit (ceea ce este destul de mult), iar următorul plan plătit începe de la 49 USD. Funcționează foarte bine.

Un serviciu excelent care agregează jurnalele de aplicații, orice jurnal de text, syslog etc. Ce este interesant: puteți lucra cu date agregate printr-un browser, linie de comandă sau API. Căutarea se efectuează cu interogări simple precum „3pm ieri” (primiți date de la toate sistemele la ora trei dimineața pentru ieri). Toate evenimentele conexe vor fi grupate. Pentru orice condiție, puteți face o alertă pentru a primi avertismente la timp (setările din configurații s-au schimbat). Puteți folosi S3 pentru a stoca jurnalele. În prima lună se oferă 5 GB ca bonus, apoi doar 100 MB pe lună sunt furnizați gratuit.

Un alt serviciu bun pentru colectarea datelor, care vă permite să colectați gratuit până la un gigabyte de jurnale pe lună. Dar capabilitățile sunt în continuare aceleași: căutare puternică, tail în timp real (tot ce „soeste” din jurnal în acest moment este afișat), stocarea datelor în AWS, monitorizarea PaaS, IaaS și a cadrelor și limbilor populare. Planul gratuit vă permite să stocați șapte zile de date.

NewRelic

Da, acest serviciu nu este cu adevărat pentru colectarea jurnalelor. Dar dacă întrebarea este despre monitorizarea performanței serverelor și aplicațiilor, atunci aceasta este una dintre cele mai bune opțiuni. Mai mult, în majoritatea cazurilor poți lucra cu el gratuit, ceea ce am folosit mult timp în redacție pentru a monitoriza aplicațiile și starea serverului.

Extinde totul acasă

Experimentele mele cu serviciile online s-au încheiat când existau atât de multe date încât ar trebui să plătesc sume de trei cifre pentru agregarea lor. Cu toate acestea, s-a dovedit că puteți implementa singur o astfel de soluție. Există două opțiuni principale.

logstash

Acesta este un sistem deschis de colectare a evenimentelor și jurnalelor, care s-a dovedit bine în comunitate. Implementarea acestuia, desigur, nu este dificilă - dar nu mai este un serviciu gata făcut din cutie. Prin urmare, fiți pregătit pentru erori din documentația rară, erori ale modulelor și altele asemenea. Dar logstash își face față sarcinii: jurnalele sunt colectate și căutările sunt efectuate prin interfața web.

Fluentd

Dacă aleg o soluție de sine stătătoare, Fluentd mi-a plăcut mai mult. Spre deosebire de logstash, care este scris în JRuby și, prin urmare, necesită un JVM (ceea ce nu îmi place), este implementat în CRuby și zonele critice pentru performanță sunt scrise în C. Sistemul este din nou deschis și vă permite să colectați fluxuri mari de jurnalele folosind peste 1500 de pluginuri diferite. Este bine documentat și extrem de clar. Versiunea mea actuală a colectorului de jurnal este implementată pe Fluentd.

Distribuie acest articol prietenilor tăi.

Salutări, cititor al blogului meu. A trecut ceva timp de când am scris un articol. Multe schimbari de viata... Articolul de astazi va fi dedicat syslog, sau mai degrabă rsyslog, care este implementat în mod activ în locul vechiului syslogd (alias sysklogd) în cele mai recente versiuni ale distribuțiilor (de exemplu, etc.). Am oferit o descriere de bază a performanței în articolul corespunzător. Prin urmare, înainte de a citi ceea ce este descris mai jos, vă recomand cu căldură să citiți. Sarcina mea actuală este colectați jurnalele de sistem syslog de la echipamentele de rețeaîn cantitate de ~100 de gazde cu o creștere ulterioară a numărului lor. Voi încerca să implementez această funcționalitate în acest articol, după ce am descris anterior și. Toată chestia asta va fi descrisă pe baza Debian 6, în alte distribuții, dacă aveți experiență, cu un minim de mișcări cu un fișier, cred că nu va fi prea greu de configurat. Deci, să începem...

Introducere în rsyslog

După cum am spus deja, rsyslog a devenit pachetul implicit pe majoritatea distribuțiilor Linux (poate toate). Rsyslog coincide total protocol syslog descris în și conține, de asemenea, câteva caracteristici suplimentare. Cum ar fi transportul TCP, filtrarea și sortarea mesajelor, stocarea mesajelor într-un SGBD, criptarea și multe altele. În articol voi încerca să iau în considerare descrierea, descrierea controlați demonul rsyslogdȘi .

Se instalează rsyslogd

Instalarea rsyslog (dacă din anumite motive nu este instalat implicit) se reduce la o singură comandă:

Aptitude install rsyslog # în red hat, opțiunea yum install rsyslog este posibilă

Directive de configurare

Directivele de configurare sunt uneori numite directive globale și specifică parametrii generali ai demonului rsyslogd. Directiva are formatul $Directive parametru

########################### #### DIRECTIVE GLOBALE #### ############ # ############## # Specifică utilizarea formatului clasic de marcaj temporal (Lună DD HH:MM:SS). # Pentru a activa formatul de marcaje temporale Unix, trebuie să comentați linia. $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Setează valoarea implicită pentru fișierele jurnal. $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Setează locația fișierelor spool și statice (pentru stocarea fișierelor cum ar fi coada de mesaje) $WorkDirectory /var/spool/rsyslog # # Include all config. conf din directorul /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf

Lista cea mai completă a directivelor globale poate fi găsită.

Șabloane rsyslog

Foarte important și cheie caracteristica rsyslogd este capacitatea de a folosi șabloane. Șablonul vă permite să: 1. setați formatul informațiilor de ieșire, 2. utilizați nume dinamice ale fișierelor jurnal pe baza unor reguli. De fapt, Toate Mesajele de ieșire din rsyslogd sunt generate pe baza șabloanelor. Aici poate apărea o întrebare corespunzătoare - cum este generată rezultatul dacă nu specificați niciun șablon rsyslog.conf(la urma urmei, nu sunt specificate șabloane în mod implicit)? E simplu. Există câteva șabloane (luate din cele compatibile și scrise static în sursele rsyslog). Dovada acestui lucru poate fi găsită în fișierul cod sursă syslogd.c căutând „template_” (veți găsi /* șabloane standard codificate hard (utilizate pentru valorile implicite) */). Șabloanele trebuie specificate inainte de utilizarea în reguli.

Șablon de sintaxă

În general, structura șablonului poate fi reprezentată în următoarea sintaxă:

$template template_name , template_description[,opțiuni (după caz)]

Să ne uităm la fiecare punct. $șablon- indică faptul că va urma o descriere a șablonului. Nume șablon- o valoare arbitrară care descrie clar ce este șablonul și de ce (numele va fi folosit pentru a se referi la șablon). Opțiuni- poate căpăta un sens sql Și sqlstd aceasta forțează ca rezultatul final al șablonului să fie formatat într-o formă potrivită pentru MySQL sau, respectiv, SQL standard (de fapt, înlocuiește unele caractere speciale din mesajul syslog într-un format suportat de serverul SQL). Opțiunile se aplică numai șabloanelor pentru ieșire în SQL.

template_description este între ghilimele. Între ghilimele, orice text este luat literal (ca atare), cu excepția textului cuprins în semne de procente ( %text%). Un astfel de text este o variabilă și vă permite să „accesați” conținutul intern al mesajului primit și, prin urmare, să obțineți tot felul de caracteristici distractive de modificare). De asemenea, așa-numitul poate fi folosit între ghilimele. secvențe de evacuare sub forma unei bare oblice inverse și a unui caracter în spatele liniei (de exemplu, \n - linie nouă, \7 - ...).

Utilizarea variabilelor în șabloanele rsyslog

Să sortăm structura valorilor indicate în %%.

%proper_name [:începutul liniei :sfârșitul rândului :opțiuni [:fieldname]]%

nume_propriu(alias numele proprietatii, e la fel nume_variabilă) - specifică numele proprietății (o proprietate în acest context poate fi considerată ca o proprietate/câmp a mesajului syslog care trece prin demon), iată câteva dintre cele mai utilizate cu proprietățile rsyslog:

• msg- Conținutul mesajului
• nume de gazdă- hostname\ip din mesaj
• de la gazdă- numele gazdei de la care a venit mesajul
• fromhost-ip- adresa gazdei de la care au venit mesajele (127.0.0.1 pentru mesajele locale)
• syslogtag- numele și numărul procesului ("rsyslogd:") care a emis mesajul (extras din mesaj)
• numele programului- numele procesului care a emis mesajul (extras din mesaj)
• pri- sursă și prioritate, ca număr
• pri-text- sursa decodata si prioritate ( facilitate.prioritate, de exemplu syslog.emer)
• syslogfacility- doar sursa ca număr
• syslogfacility-text- numai sursa decodata ("local0")
• syslogseverity- numai prioritate ca număr
• syslogseverity-text- doar nivelul decodat ("debug")
• generat în timp- timpul de achiziție (rezoluție înaltă)
• raportat în timp- timpul extras din mesaj
• nume de intrare- numele modulului de intrare
• $oră, $minut- ora curentă
• $myhostname- procesarea numelui de gazdă

După cum puteți vedea, unele proprietăți încep cu semnul dolarului - sunt considerate locale\sistem.

Mai departe - Opțiuni. Opțiunile vă permit să modificați o variabilă în limitele semnului procentual la semnul procentului. Puteți aplica mai multe opțiuni în același timp, separate prin virgule. Dacă specificați mai multe contradictorii (de exemplu, majuscule, minuscule), atunci se va aplica ultimul specificat (minuscule). Iată câteva opțiuni:

• majuscule- conversie în majuscule
• litere mici- conversie în litere mici
• data-mysql- convertiți în formatul de dată MySQL
• spaţiu-cc- înlocuiți caracterele de control cu ​​spații
• drop-cc- elimina caracterele de control

numele domeniului- acest câmp este disponibil din versiunea 6.3.9+ și are un caracter foarte specific. Poți să o uiți...

După cum puteți vedea din șablonul variabil de mai sus, valorile din acolade sunt opționale, adică puteți specifica pur și simplu, de exemplu, %hostname%. Dar dacă sunt folosite opțiuni, atunci trebuie specificate și câmpurile goale anterioare, de exemplu %hostname:::minuscule%. Câmpuri lipsă între două puncte începutul_liniei și sfârșitul_liniei. În același timp, din anumite motive fieldname nu este indicat ca gol.

Șabloane care sunt codificate în rsyslog (dar care pot fi modificate cu o directivă $ActionFileDefaultTemplate):

RSYSLOG_SyslogProtocol23Format- formatul definit în proiectul standardului IETF ietf-syslog-protocol-23 urmează modelul:

"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n\"

RSYSLOG_FileFormat- formatul tradițional de jurnal, cu adăugarea de fracții de secundă și zonă, corespunde șablonului:

„%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\”

RSYSLOG_TraditionalFileFormat- formatul tradițional de jurnal pentru scrierea într-un fișier, corespunde următorului model:

„%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n\"

RSYSLOG_ForwardFormat- formatul tradițional de jurnal pentru transmitere cu adăugarea de fracțiuni de secundă și zonă, urmează modelul:

"<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

RSYSLOG_TraditionalForwardFormat- format tradițional de jurnal pentru transfer pe un server la distanță

"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%\"

reguli de sortare rsyslog (linia regulii)

Fiecare linie de reguli de sortare are un format clasic, la fel ca într-un syslog obișnuit. Pentru a înțelege ce și cum, trebuie să citiți articolul. Pe scurt: regula constă în selector Și actiuni , separate printr-un spațiu sau o tabulatură. Selector constă la rândul său din sursăȘi prioritate. Fiecare mesaj este verificat cu selectorul de la fiecare regulă secvenţial, dacă mesajul şi selectorul de regulă se potrivesc, atunci acţiunea specificată este efectuată. În același timp, după primul meci, procesarea nu se oprește. Inainte de acțiune, mesajul este convertit în conformitate cu șablonul (șablonul implicit specificat în directiva corespunzătoare (înlocuind șablonul implicit), șablonul specificat în această acțiune este unul din trei).

La caracteristicile standard selectoare syslog au fost adăugate câteva caracteristici suplimentare (permiteți-mi să vă reamintesc că, în mod clasic, un selector este sursă.prioritate, aka facilitate.prioritate). În rsyslog puteți folosi valori ca selector. În rsyslog, se apelează la utilizarea variabilelor într-un selector Filtre. Mai sus în articol, precum și în abordarea clasică a filtrarii bazată pe sursă.prioritate(așa-zisul selectoare „tradiționale” de severitate și facilitate). Pe lângă filtrarea tradițională, există următoarele tipuri de filtrare: Filtre bazate pe RainerScript(filtrare bazată pe limbajul RainerScript - de fapt obișnuit dacă - atunci - altfel), filtre bazate pe proprietăți(filtrare bazată pe proprietățile mesajului (ca în)). Să ne uităm la ambele:

Filtre bazate pe RainerScript

După cum am spus, RainerScript este un limbaj clasic, dacă nu se bazează pe altcineva. În rsyslog, RainerScript acceptă imbricarea condițiilor, operațiuni aritmetice, logice și cu șiruri. În general, sintaxa este următoarea:

if condition then action_block else action_block

Respectiv, daca atunci- sunt operatori obligatorii care definesc construcția stării, altfel- de necesitate. action_block - poate conține o acțiune (), sau un bloc imbricat de condiții. Dacă un bloc de condiții conține mai multe acțiuni, acesta este inclus în paranteze. condiție- conține o condiție pentru selectarea mesajelor pentru action_block. In starea puteti folosi:

1. expresii logice(și, sau, nu), precum și gruparea acestor expresii sub forma: nu condiția0 și (condiția1 și condiția2).
2. proprietăți- variabilele sunt specificate sub forma $variable_name (de exemplu $hostname sau $msg)
3. operatii de comparatie(== - egal, != - nu este egal, > - mai mare,< - меньше, <= - меньше или равно, >= - mai mare sau egal cu, (!)conține - (nu) conține, (!)începe cu - (nu) începe cu)
4. comentarii /* comentarii */(punct îndoielnic... trebuie scăpat ca în bash???)

Cisco

as53xx231#conf t Introduceți comenzile de configurare, una pe linie. Încheiați cu CNTL/Z. as53xx231(config)#logging 10.0.0.1 as53xx231(config)#exit

VMware ESXi

Pentru un hipervizor vechi:

Trebuie să adăugați următoarele în /etc/syslog.conf:

*.* @10.0.0.1 # în firewall trebuie să permiteți syslog și să îl salvați: esxcfg-firewall -o 514,udp,out,syslog esxcfg-firewall -l # restart syslog service syslog restart

În cele mai recente versiuni ale hypervisorului, totul se face prin clientul GUI. În setările hypervisorului Advansed -> Syslog -> remote, specificați adresa serverului rsyslog.

Stocarea jurnalului rsyslog în SGBD-ul MySQL

În Debian, configurarea stocării într-o bază de date este foarte simplă (aproape ca într-un automat automat)). În general, este suficient să instalați pachetul rsyslog-mysql. În acest caz, instalatorul plasează modulul ommysql.so în directorul /usr/lib/rsysloul/spang/ și lansează vrăjitorul de configurare, care solicită parola de administrator MySQL, creează un utilizator separat și solicită o parolă pentru acesta. Creează baza de date corespunzătoare din scriptul /usr/share/dbconfig-common/data/rsyslog-mysql/install/mysql. Setările rezultate sunt plasate în /etc/rsyslog.d/mysql.conf. Configurația constă din 2 linii::

# conexiune la modul: $ModLoad ommysql # trimiteți toate mesajele către MySQL (rețineți Acțiunile de mai sus) *.* :ommysql:adresa_server, nume_bază de date, nume_utilizator, parolă

Interfață web pentru rsyslog

Vom configura Loganalizer din adiscon ca interfață web. Instalarea interfeței web este destul de simplă. Constă în descărcarea arhivei, despachetarea acesteia în directorul serverului web și lansarea vrăjitorului de configurare grafică. Deci, de aici (http://loganalyzer.adiscon.com/downloads) descărcați arhiva cu fișierele (De exemplu: http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz). Înainte de configurare, desigur, trebuie instalate serverul Web și modulul php5 (aptitude install apache2 libapache2-mod-php5). Și da, și php5-gd pentru afișarea rapoartelor.

~ # # Descărcați arhiva: ~ # wget http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz ~ # # Despachetați arhiva: ~ # tar xf loganalyzer-3.5.6.tar. gz

Directorul loganalyzer-3.5.6 va apărea în directorul curent, care conține câteva informații care merită citite:

~ # ls -l total 12 drwxr-xr-x 3 rădăcină rădăcină 4096 20 septembrie 22:51 . drwx------ 13 root root 4096 Sep 20 23:01 .. drwxrwxr-x 5 root root 4096 Sep 10 17:26 loganalyzer-3.5.6 ~ # ls -l loganalyzer-3.5.6/ total 112 -rw -rw-r-- 1 rădăcină rădăcină 41186 10 septembrie 17:26 ChangeLog drwxrwxr-x 2 rădăcină rădăcină 4096 20 septembrie 23:01 contribuție -rw-rw-r-- 1 rădăcină rădăcină 35497 10 septembrie 17:26 COPYING drwx 2 rădăcină rădăcină 4096 10 septembrie 17:34 doc -rw-rw-r-- 1 rădăcină rădăcină 8449 10 septembrie 17:26 INSTALARE drwxrwxr-x 14 rădăcină rădăcină 4096 10 septembrie 17:34 src ~ # # directorul src de la s pentru a copia conținutul în /var/www/loganalyzer: ~ # mkdir /var/www/loganalyzer ~ # cp -r loganalyzer-3.5.6/src/* /var/www/loganalyzer ~ # # apoi, trebuie să creați un fișier de configurare gol, ~ # # care va fi completat automat de către instalator ~ # atingeți /var/www/loganalyzer/config.php ~ # # setați permisiunile de scriere (după instalare, aceste drepturi pot fi eliminate) ~ # chmod 666 / var/www/loganalyzer/config.php

click aici

Vedem de ce am dat permisiunile 666, faceți clic pe Următorul

Aici selectăm setările dorite. Parametrul Enable User Database necesită o atenție specială. Dacă îl selectați, va fi creată o bază de date separată pentru a stoca setările interfeței Web. De asemenea, va fi disponibilă și posibilitatea de a crea utilizatori și grupuri. Faceți clic pe următorul.

Există o mică adăugare - serverul web nu are acces la fișierele obișnuite din directorul /var/log/. Prin urmare, este posibil ca jurnalul să nu fie afișat. Pentru a rezolva această problemă, trebuie să adăugați utilizatorul www-data la grupul adm:

~ # usermod -G adm www-data

Pe lângă Loganalyzer, există și Logzilla, care are aceeași funcționalitate. De asemenea, merită să încerci să-l instalezi dacă vrei.

Câteva sfaturi și trucuri pentru rsyslog

Uneori, când rsyslog este un serviciu de rețea pentru colectarea jurnalelor de la distanță, stocarea mesajelor după numele de gazdă este incomod sau neproductiv sau altceva. Pentru a dezactiva rezolvarea adreselor IP în nume de gazdă, trebuie să adăugați parametrul -x:

~ # cat /etc/default/rsyslog RSYSLOGD_OPTIONS="-c5 -x"

Pentru a permite pachetelor UDP să treacă, trebuie să utilizați comanda:

~ # iptables -A INPUT -p udp -s source_subnet --dport 514 -i interface -j ACCEPT

Câteva exemple de reguli cu comentarii:

# dacă creați un selector ca acesta: dacă $fromhost-ip începe cu „10.0.1”. atunci /ceva/ # ar trebui să acordați atenție ultimului punct din adresă, # altfel adresele din subrețeaua 10.0.111.0, 10.0.12.0 și altele vor intra sub regulă

Pentru un server centralizat pentru colectarea jurnalelor de la dispozitivele de rețea, puteți seta sursa (facilitatea) pe dispozitivele de rețea la orice valoare de la local0-local7. Acest lucru vă va permite să sortați convenabil mesajele, de exemplu:

# cisco: net-device-cisco#conf t Introduceți comenzile de configurare, una pe linie. Încheiați cu CNTL/Z.<...>net-device-cisco(config)#logging facilitate local2<...># rsyslog-server local2.* /var/log/remote-cisco.log & ~

În acest fel, puteți filtra convenabil mesajele locale de la cele de la distanță.

Iată câteva configurații care vă permit să trimiteți notificări prin e-mail despre evenimente (!!! serverul de mail trebuie să accepte mesaje fără autentificare):

$ModLoad ommail $ActionMailSMTPServer smtp_address $ActionMailSMTPPort 25 $ActionMailFrom sender@address $ActionMailTo recipient@address $template mail_subject,"Pe gazda %hostname%, nivel de eroare de server" $template mail_body,"Facility.Serverfacility%. syslogpriority% la %timegenerated% pe gazdă: %HOSTNAME%\r\n %msg%" $ActionMailSubject mail_subject # interval de timp (pauză între litere) $ActionExecOnlyOnceEveryInterval 10 # filtru de selecție și acțiune dacă nu ($msg conține „ceva”\ sau $msg conține „altceva”\ sau $msg conține „poate_altceva”)\ și ($syslogseverity-text =="err"\ sau $syslogseverity-text =="crit"\ sau $syslogseverity-text =="alertă „\ sau $syslogseverity-text =="emerg”)\ apoi:ommail:;mail_body

Depanare

Pentru diagnosticarea funcționării syslog, un exemplu de comandă pentru monitorizare este foarte util:

~ # tcpdump -vvv -nn -i interfață udp portul 514

Și, desigur, /var/log/syslog însuși.

Nu am văzut nimic neobișnuit.

15 februarie 17:47:23 log-n1 yum: Instalat: syslog-ng-3.5.6-3.el7.x86_64
15 februarie 17:47:36 log-n1 systemd: Reîncărcare.

15 februarie 17:47:40 log-n1 syslog-ng: pornirea syslog-ng; versiune=’3.5.6′
15 februarie 17:47:40 log-n1 systemd: Ascultare pe socket Syslog.
15 februarie 17:47:40 log-n1 systemd: Se pornește Socket Syslog.
15 februarie 17:47:40 log-n1 systemd: Se pornește demonul System Logger...
15 februarie 17:47:40 log-n1 systemd: Daemonul de înregistrare a sistemului a pornit.
15 februarie 17:52:41 log-n1 syslog-ng: syslog-ng se închide; versiune=’3.5.6′
15 februarie 17:52:41 log-n1 systemd: Oprirea demonului System Logger...


15 februarie 17:52:41 log-n1 systemd: syslog-ng.service holdoff time over, programarea repornirii.
15 februarie 17:52:41 log-n1 systemd: Se pornește Daemonul System Logger...
15 februarie 17:52:41 log-n1 systemd: syslog-ng.service: proces principal ieșit, cod=ieșit, stare=2/INVALIDARGUMENT
15 februarie 17:52:41 log-n1 systemd: Nu s-a pornit System Logger Daemon.
15 februarie 17:52:41 log-n1 systemd: Unitatea syslog-ng.service a intrat în starea eșuată.
15 februarie 17:52:41 log-n1 systemd: syslog-ng.service a eșuat.



15 februarie 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, programarea repornirii.
15 februarie 17:52:42 log-n1 systemd: Se pornește demonul System Logger...
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service: proces principal ieșit, cod=ieșit, stare=2/INVALIDARGUMENT
15 februarie 17:52:42 log-n1 systemd: Nu s-a pornit System Logger Daemon.
15 februarie 17:52:42 log-n1 systemd: Unitatea syslog-ng.service a intrat în starea eșuată.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service a eșuat.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, programarea repornirii.
15 februarie 17:52:42 log-n1 systemd: Se pornește demonul System Logger...
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service: proces principal ieșit, cod=ieșit, stare=2/INVALIDARGUMENT
15 februarie 17:52:42 log-n1 systemd: Nu s-a pornit System Logger Daemon.
15 februarie 17:52:42 log-n1 systemd: Unitatea syslog-ng.service a intrat în starea eșuată.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service a eșuat.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service holdoff time over, programarea repornirii.
15 februarie 17:52:42 log-n1 systemd: Nu s-a pornit System Logger Daemon.
15 februarie 17:52:42 log-n1 systemd: Unitatea syslog-ng.service a intrat în starea eșuată.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service a eșuat.
15 februarie 17:52:42 log-n1 systemd: cererea de pornire s-a repetat prea repede pentru syslog-ng.service
15 februarie 17:52:42 log-n1 systemd: Nu s-a pornit System Logger Daemon.
15 februarie 17:52:42 log-n1 systemd: Unitatea syslog.socket a intrat în starea eșuată.
15 februarie 17:52:42 log-n1 systemd: syslog-ng.service a eșuat.
15 februarie 17:53:11 log-n1 systemd: Ascultare pe socket Syslog.