pentru ca administratorul de sistem să identifice sau să depaneze o problemă pe un sistem server CentOS 7 sau RHEL 7, acesta trebuie să cunoască și să vizualizeze evenimentele care au avut loc pe sistem într-o anumită perioadă de timp din fișierele jurnal stocate în sistem în directorul /var/log.
serverul syslog de pe o mașină Linux poate acționa ca un punct central de monitorizare într-o rețea în care toate serverele, dispozitivele de rețea, routerele, comutatoarele și majoritatea serviciilor lor interne care generează jurnale, indiferent dacă sunt legate de o problemă internă specifică sau doar mesaje informative pot trimite jurnalele lor.
pe un sistem CentOS/RHEL 7, daemonul Rsyslog este serverul principal de jurnal preinstalat, urmat de daemonul Jurnalului Systemd (journald).
Rsyslog server în construi ca un serviciu de arhitectura client/server și poate realiza ambele roluri simultan. Se poate rula ca un server și să colecteze toate jurnalele transmise de alte dispozitive din rețea sau se poate rula ca un client prin trimiterea toate evenimentele de sistem intern conectat la un server syslog Endpoint la distanță.
când rsyslog este configurat ca un client, jurnalele pot fi stocate local în fișiere de pe sistemul de fișiere local sau pot fi trimise de la distanță, mai degrabă decât să le scrie în fișiere stocate pe mașină sau scrie evenimente fișiere jurnal local și trimite-le la un server syslog la distanță, în același timp.
serverul Syslog operează orice mesaj de jurnal utilizând următoarea schemă:
type (facility).priority (severity) destination(where to send the log)
A. Datele facilității sau tipului sunt reprezentate de procesele interne ale sistemului care generează mesajele. În procesele interne Linux (facilități) care generează jurnalele sunt standardizate după cum urmează:
- auth = mesaje generate de procesele de autentificare (autentificare).
- cron= mesaje generate de procesele programate (crontab).
- daemon = mesaje generate de demoni (servicii interne).
- kernel = mesaje generate de nucleul Linux în sine.
- mail = mesaje generate de un server de mail.
- syslog = mesaje generate de demonul rsyslog în sine.
- LPR = mesaje generate de imprimante locale sau de un server de imprimare.
- local0 – local7 = mesaje personalizate definite de un administrator (local7 este de obicei atribuit pentru Cisco sau Windows).
B. nivelurile de prioritate (severitate) sunt, de asemenea, standardizate. Fiecare prioritate este atribuită cu o abreviere standard și un număr așa cum este descris mai jos. Prioritatea 7 este nivelul superior al tuturor.
- emerg = urgență-0
- alert = alerte-1
- err = erori-3
- warn = avertismente-4
- notice = notificare-5
- info = Informații – 6
- debug = depanare– 7
cuvinte cheie speciale Rsyslog:
- * = toate facilitățile sau prioritățile
- none = facilitățile nu au priorități date de ex: mail.niciuna
C. A treia parte pentru schema syslog este reprezentată de Directiva destinație. Daemonul Rsyslog poate trimite mesaje de jurnal pentru a fi scrise într-un fișier din sistemul de fișiere local (mai ales într-un fișier din /var/log/ director) sau pentru a fi transmise către un alt proces local sau pentru a fi trimise către o consolă de utilizatori locali (către stdout) sau pentru a trimite mesajul către un server syslog la distanță prin protocolul TCP/UDP sau chiar aruncați mesajul către /dev/null.
pentru a configura CentOS/RHEL 7 ca server central de jurnal, mai întâi trebuie să verificăm și să ne asigurăm că partiția /var în care sunt înregistrate toate fișierele jurnal este suficient de mare (minim câțiva GB) pentru a putea stoca toate fișierele jurnal care vor fi trimise de alte dispozitive. Este o decizie bună să utilizați o unitate separată (LVM, RAID) pentru a monta directorul /var/log/.
cerințe
- CentOS 7.3 procedura de instalare
- RHEL 7.3 procedura de instalare
cum se configurează Rsyslog în CentOS/RHEL 7 Server
1. În mod implicit, serviciul Rsyslog este instalat automat și ar trebui să ruleze în CentOS/RHEL 7. Pentru a verifica dacă daemonul este pornit în sistem, emiteți următoarea comandă cu privilegii root.
# systemctl status rsyslog.service
dacă serviciul nu rulează în mod implicit, executați comanda de mai jos pentru a porni demonul rsyslog.
# systemctl start rsyslog.service
2. Dacă pachetul rsyslog nu este instalat pe sistemul pe care intenționați să îl utilizați ca server de logare centralizat, emiteți următoarea comandă pentru a instala pachetul rsyslog.
# yum install rsyslog
3. Primul pas pe care trebuie să-l facem pe sistem pentru a configura daemonul rsyslog ca server de jurnal centralizat, astfel încât să poată primi mesaje de jurnal pentru clienți externi, este să deschidem și să edităm, folosind editorul de text preferat, fișierul principal de configurare din /etc/rsyslog.conf, așa cum este prezentat în extrasul de mai jos.
# vi /etc/rsyslog.conf
în fișierul principal de configurare rsyslog, căutați și decomentați următoarele linii (eliminați semnul hashtag # la începutul liniei) pentru a furniza recepția de transport UDP către serverul Rsyslog prin portul 514. UDP este protocolul standard utilizat pentru transmiterea jurnalului de către Rsyslog.
$ModLoad imudp $UDPServerRun 514
4. Protocolul UDP nu are aeriene TCP, ceea ce face mai rapid pentru transmiterea datelor decât protocolul TCP. Pe de altă parte, Protocolul UDP nu asigură fiabilitatea datelor transmise.
cu toate acestea, dacă trebuie să utilizați protocolul TCP pentru recepția jurnalului, trebuie să căutați și să decomentați următoarele linii din /etc/rsyslog.fișier conf pentru a configura daemonul Rsyslog pentru a lega și asculta un soclu TCP pe portul 514. Prizele de ascultare TCP și UDP pentru recepție pot fi configurate simultan pe un server Rsyslog.
$ModLoad imtcp $InputTCPServerRun 514
5. La pasul următor, nu închideți încă fișierul, creați un șablon nou care va fi utilizat pentru primirea mesajelor la distanță. Acest șablon va instrui serverul local Rsyslog unde să salveze mesajele primite trimise de clienții rețelei syslog. Șablonul trebuie adăugat înainte de începerea blocului directive globale, așa cum este ilustrat în extrasul de mai jos.
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" . ?RemoteLogs & ~
directiva $template RemoteLogs de mai sus instruiește daemonul Rsyslog să colecteze și să scrie toate mesajele de jurnal primite în fișiere distincte, pe baza numelui mașinii client și a facilității clientului la distanță (aplicație) care a generat mesajele bazate pe proprietățile definite prezentate în configurația șablonului: %HOSTNAME% și %PROGRAMNAME%.
toate aceste fișiere jurnal vor fi scrise în sistemul de fișiere local într-un fișier dedicat numit după numele de gazdă al mașinii client și stocate în directorul /var/log/.
regula de redirecționare & ~ instruiește serverul Rsyslog local să oprească procesarea mesajului jurnal primit și să elimine mesajele (nu le scrie în fișierele jurnal interne).
numele RemoteLogs este un nume arbitrar dat acestei directive șablon. Puteți utiliza orice nume puteți găsi cel mai potrivit pentru șablonul dvs.
pentru a scrie toate mesajele primite de la clienți într-un singur fișier jurnal numit după adresa IP a Clientului la distanță, fără a filtra facilitatea care a generat mesajul, utilizați extrasul de mai jos.
$template FromIp,"/var/log/%FROMHOST-IP%.log" . ?FromIp & ~
un alt exemplu de șablon în care toate mesajele cu pavilion facilitate auth va fi conectat la un șablon numit „TmplAuth”.
$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" authpriv.* ?TmplAuth
mai jos este un fragment forma o definiție șablon de Rsyslog 7 server:
template(name="TmplMsg" type="string" string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" )
extrasul de șablon de mai sus poate fi scris și ca:
template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") }
pentru a scrie șabloane Rsyslog complexe, citiți manualul fișierului de configurare Rsyslog prin emiterea man rsyslog.conf comanda sau consulta rsyslog documentație on-line.
6. După ce ați editat fișierul de configurare Rsyslog cu propriile setări, așa cum este explicat mai sus, reporniți demonul Rsyslog pentru a aplica modificările prin emiterea următoarei comenzi:
# service rsyslog restart
7. Până acum, serverul Rsyslog ar trebui să fie configurat pentru a acționa un server de jurnal centralizat și pentru a înregistra mesaje de la clienții syslog. Pentru a verifica prize de rețea Rsyslog, executați comanda netstat cu privilegii de root și de a folosi grep pentru a filtra șir rsyslog.
# netstat -tulpn | grep rsyslog
8. Dacă aveți SELinux activat în CentOS / RHEL 7, emiteți următoarea comandă pentru a configura SELinux pentru a permite traficul rsyslog în funcție de tipul de soclu de rețea.
# semanage -a -t syslogd_port_t -p udp 514# semanage -a -t syslogd_port_t -p tcp 514
9. Dacă firewall-ul este activat și activ, executați comanda de mai jos pentru a adăuga regulile necesare pentru deschiderea porturilor rsyslog în Firewalld.
# firewall-cmd --permanent --add-port=514/tcp# firewall-cmd --permanent --add-port=514/udp# firewall-cmd –reload
asta e tot! Rsyslog este acum configurat în modul server și poate centraliza jurnalele de la clienți la distanță. În articolul următor, vom vedea cum să configurați clientul Rsyslog pe serverul CentOS / RHEL 7.
utilizarea Rsyslog server ca punct central de monitorizare pentru mesajele jurnal de la distanță puteți inspecta fișierele jurnal și să respecte starea de sănătate a clienților sau problemele clientului depanare mai ușor atunci când sistemele de accident sau sunt sub un fel de atac.