Xakep, nr. 063, pp. 063-108-1
Sistem pentru logarea evenimentelor în detaliu
Conectați-vă la sistemele lor bazate pe Unix, formați PS waux, dacă este Linux sau BSD, sau -ef ps, în cazul în care este orice altă implementare a Sistemului Solaris V. Veți vedea un număr de procese, din care fiecare face ceva. De exemplu, poate fi crond, inetd, ntpd, sendmail, sshd și o serie de alte daemon și procesează kernel. Și ceea ce este interesant este că toate datele de ieșire la fluxurile standard care sunt înregistrate de sistemul de logare. Pentru ce este?
Acest lucru se face în scopul de a găzdui proprietarului, în orice moment se poate afla exact ceea ce face fiecare dintre ele, iar dacă ceva nu merge - afla care este motivul. Bușteni - istoria sistemului de viață, și, uneori, numai în picking lungă / var / log ajută pentru a afla de ce dintr-o dată a pus facturile de furnizor pentru trafic, și că, pentru un clovn toată noaptea scobite toate porturile de server 65535.
În mod tradițional, daemonul syslogd este responsabil pentru menținerea jurnalelor de evenimente. istoria cărora se întoarce la Institutul Berkeley și la BSD acolo. Syslogd este mai mult decât un demon. Trebuie să interacționeze cu toți daemoanele care rulează în sistem, astfel încât să poată înregistra toate evenimentele. Această interacțiune are loc printr-un socket special / dev / log. Prin urmare, orice demon care vrea să lase o amintire a lui însuși în jurnalul evenimentelor scrie pur și simplu în acest fișier anumite argumente. Demonul sistemului syslogd este pornit de la scripturile de inițializare la pornirea sistemului.
Ca orice demon care respectă sine, syslogd are propriul fișier de configurare. Valoarea implicită este /etc/syslog.conf. dar nu există nimic care să nu împiedice să se numească nimic și apoi rulați syslogd cu comutatorul -f /path/to/config.file. În fișierul de configurare ne îndreptăm atenția și despre cheile cu care puteți începe syslogd, puteți învăța de la omul syslogd. binecuvântarea lor nu este suficientă.
Fiecare linie a syslog.conf este alcătuită din două intrări - reguli și acțiuni. Regulile indică ce subsistem generează evenimente, precum și gradul de detaliere, în acțiuni - ce să facem cu aceste evenimente. De fapt, totul este simplu. subsisteme majore douăsprezece - AUTH, authPriv, cron, daemon, Kern, LPR, e-mail, marca, știri, syslog, utilizator, UUCP, dar în practică este folosit în principal următoarele cele AUTh - informații despre jurnalele de utilizator pe ( „utilizator Bob a mers la a doua consolă „), authPriv - informații despre privilegii ridicate asupra sistemului (“ utilizator Vasya a su pentru root pe a doua consolă „), cron - informații despre rularea de locuri de muncă programate (“ nouă dimineața, ca de obicei, script-ul în jos firewall iar utilizatorii INET este de peste „), Kern - mesaje de kernel (“ interfața de rețea a trecut în modul promiscious „), LPR - mesaje de sistem de imprimare, m ail - mesaje ale sistemului de e-mail, etc.
Desemnarea subsistemului este indicată de numele acestuia. Deși această clasificare este convențională. Nu există ftpd, httpd, etc. - și nu este nevoie, deoarece acești demoni înșiși îngrijesc cât de mult și unde să scrie informații. În cazul general, este vorba despre afacerea programatorului - la ce clasă să-i atribuiți demonul și să folosiți argumentul corespunzător funcției openlog (3) atunci când scrieți.
Gradul de detaliere este cantitatea de informații care vor fi procesate. Există opt clase de prioritate: depanare, informatii, notificare, avertizare, err, Crit, alertă, EMERG, fiecare viitoare - mai informative decât cea anterioară. Aceasta este, la nivelul daemon de depanare oferă un număr foarte mare de mesaje, pe care le puteți restabili să lucreze în toate detaliile sale (așa-numitele - depanare), observați nivelul - cel mai bun (daemon oferă numai mesaje relevante), Emerg - doar critică la nivelul sistemului.
În cele din urmă, acțiunea este ceea ce syslogd ar trebui să facă atunci când procesează mesaje. Acțiunile pot include: scrierea într-un fișier (/var/log/file.log) - cel mai popular, și pentru care jurnalele sunt menținute, dar, în plus, jurnalele pot fi trimise la gazda de la distanță (de tip @loghost de înregistrare), redirecționați către alte programe de banda transportoare , trimis către anumiți utilizatori și / sau ieșiri către consolă (/ dev / console). Sub jurnalele de transfer de la o gazdă de la distanță se referă la nimeni altul decât ca le trimite la o altă mașină, care este, de asemenea, execută Syslogd, ascultare pe 514 / portul UDP.
De asemenea, este convenabil să se combine subsistemele și gradul de detaliere prin asocierea unui model cu una dintre acțiunile de mai sus. Intrarea în fiecare linie a configului arată în general:
Există punctul de potrivire a subsistemului la nivel de logare divizat, și mai multe astfel de combinații pot fi asociate o singură acțiune, separate prin punct și virgulă. Am observat că în înregistrarea subsistemului1 al nivelului se definește următoarea: "pentru subsistemul 1, log toate evenimentele de nivel 1 și superior". Care este logic, dacă ne amintim că nivelurile continuă să crească (aici "mai mare" înseamnă mai puține informații). De exemplu, înregistrarea daemon.notice; kern.emerg / var / log / mesaje determină intrarea în / var / log / mesaje tuturor notificare la nivel de mesaj, și mai presus de toți demonii, precum și mesajele kernel critice (și mai sus - dar nu are nimic de mai sus) . Dacă pentru un anumit demon trebuie doar să înregistrați evenimente de un anumit nivel, puneți "=": mail. = Debug înainte de nivelul. În plus, mai multe subsisteme pot fi enumerate cu numere delimitate prin virgulă prin alocarea acestora la un nivel: mail, news.crit. De asemenea, în șabloane puteți utiliza pictograma "*", care are valoarea obișnuită pentru expresiile regulate - "toate". *. * /var/log/all.log - specifică pentru a scrie TOATE ce se întâmplă cu sistemul în /var/log/all.log. Caracterul special "!", Destinat pentru inversarea: mail.! = Debug înseamnă totul, cu excepția depanării.
Și ultimul. Dacă șirul "regulă-acțiune" este precedat de numele programului, atunci această linie se aplică numai pentru programul menționat. Acest lucru este foarte convenabil când trebuie să "cârpești" jurnalele unui anumit program (nu neapărat un daemon) într-un thread separat pentru procesare (scrieți într-un fișier separat). Numele programului ar trebui să înceapă cu "!", De exemplu, printre dialerii, următoarea configurație este populară (toate mesajele ppp trebuie să fie scrise într-un fișier jurnal separat):
Conectați-vă la exemple
Voi da câteva exemple care confirmă faptul că, de fapt, totul este foarte simplu:
# toate mesajele critice pentru funcționarea sistemului, precum și toate mesajele kernel-ului de ieșire pentru / dev / console. Aceasta este, de obicei, prima consolă fizică (/ dev / ttyv0 în FreeBSD)
# altceva decât acest lucru, tot ceea ce este mai mare în prioritate, scrieți, de asemenea, în mesaje
# toate mesajele din subsistemul de securitate scriu într-un fișier separat
#all ca și pentru autentificare - scrieți la auth.log
# toate mesajele de e-mail ale nivelurilor corespunzătoare - în maillog
# Vreau să monitorizez activitatea cron - astfel încât toate mesajele sale sunt scrise separat
# toate mesajele critice pentru a scrie unde este posibil :) pentru ca acestea să nu meargă neobservate
# toate mesajele sunt adăugate la serverul jurnal central
# Vreau să văd toate mesajele programelor mele favorite în fișiere separate.
Pentru ca daemonul syslogd să-și recite configurarea, nu este necesar să reporniți, ci să-i trimiteți semnalul HANGUP:
Pentru Linux și FreeBSD:
# killall -HUP syslogd
Pentru NetBSD, OpenBSD și Solaris:
# pkill -HUP syslogd
# kill - HUP `sed q / var / run / syslogd.pid`
Ne luptăm cu devoratorii discului
Setarea corectă a syslogd - este încă jumătate din bătălie. Fișierele care sunt atașate în mod constant de informații, tind să crească la proporții obscene, iar dacă nu acordă suficientă atenție acestui fapt, o zi, partiția / var va cădea, guițat, care a ocupat 120% din volumul :). Pe Linux, în cazul în care împărțirea în partiții nu este la fel de popular, și puteți găsi de multe ori o partiție mare rădăcină pentru restul fs (tone Mauvais, nu fac acest lucru vreodată), de data aceasta poate fi amânată (pentru o lungă perioadă de timp), dar atunci când este vorba - vine și sfârșitul întregului dosar sistem. Din păcate, nu tratamente Syslogd fișier nu produce, așa că am să vă spun despre cele două cele mai populare fișiere jurnal de control abordare: BSD-shny și Linux.
Luați în rotație
Modul cel mai convenabil de a roti jurnalele este de a folosi newsyslog. Administrată de coroana o dată pe oră / zi / luna, se uită la jurnalele, în căutarea pentru cei care au venit sub conducerea lui, și creează noi fișiere de jurnal goale incremental arhivarea vechi de numele logfile. în cazul în care. - o cifră și opțional stoarcerea acestora pentru a economisi spațiu. Fișierul de configurare implicit este /etc/newsyslog.conf, care constă din următoarele câmpuri principale:
1) numele jurnalului - calea completă la fișierul jurnal, de care aveți nevoie să monitorizați;
2) proprietar: grup și drepturi de acces - atribute ale arhivei create;
3) contra-adâncimea de arhivare incrementală;
4) dimensiunea - dimensiunea maximă a fișierului;
5) timp - momentul în care regula este declanșată.
Dimensiunea sau termenul poate avea valoarea "*" - înseamnă că decizia privind arhivarea este acceptată pe baza unuia dintre cele două argumente. Luați în considerare exemplul:
/var/log/ppp.log rădăcină: rețea 640 3 100 * Z
Această linie spune că trebuie să țină evidența ppp.log viroaga, această arhivă pentru a atribui drepturile la 640, și setați proprietarul rădăcină, iar grupul - rețea A, operațiunea de a efectua un maxim de trei ori, decizia de a efectua arhivarea pe baza dimensiunea fișierului - nu ar trebui Pentru a depăși 100 KB, întotdeauna, plus tuturor pentru a comprima arhiva (tasta Z) de către utilitarul bzip2 (compess / gzip în funcție de sistem).
Newsyslog. începând programată în mod regulat, va fi depășită în cazul în care nu caută dimensiunea ppp.log de 100 KB, iar dacă este depășită - pentru a redenumi jurnal vechi în ppp.log.0, creând un nou ppp.log gol; comprima ppp.log.0 în ppp.log.0.bz2 și să alocați drepturi de fișier 640, proprietarul - rădăcină, de grup - rețea. Când dimensiunea deja noi ppp.log depășește din nou 100 KB, programul redenumește ppp.log.0.bz2 existent în ppp.log.1.bz2 și de a crea un nou ppp.log.0.bz2 pe același algoritm. Și așa mai departe, până când cele mai vechi fișiere jurnal nu va fi numit ppp.log.3.bz2 (am subliniat, de asemenea, contra - 3). După aceasta, este șters, iar al treilea devine al doilea, etc. Întrebare rezonabilă: cât de des trebuie să rulez newsyslog de la cron? Pe o mașină neîncărcată, acest lucru se poate face la fiecare două sau trei zile, pe serverul mediu - în fiecare zi, pe un post ocupat - du-te și o dată pe oră. Newsyslog este un instrument foarte convenabil și flexibil, iar omul newsyslog vă va spune multe lucruri interesante.
Decizia conducătorului auto
Newsyslog este standard în Free / OpenBSD, în timp ce Logrotate este prezent în majoritatea distribuțiilor Linux. Ea este angajată în același mod și cu periodicitate similară este lansată pe coroană. Diferența, ca de obicei, în configurație. Aici configurația principală /etc/logrotate.conf arată astfel:
zilnic
rotiți 1
crea
comprima
include /etc/logrotate.d
Acest lucru înseamnă că - să se angajeze în prelucrarea buștenilor în fiecare zi la lopata noi busteni o dată înainte de a scoate vechi (adâncimea de backup incremental), a crea un nou fișier jurnal gol cu același nume, a început să comprima fișiere. Laconic, nu? Ultimele bază directivă - puncte pentru a viziona toate config suplimentare situate în directorul /etc/logrotate.d. În ele, specificăm parametrii specifici pentru fiecare daemon. De exemplu, creați fișierul /etc/logrotate.d/httpd:
Aici am specificat parametrii rotației jurnalului Apache. Sintaxa secțiunii: calea către fișierul jurnal și în paranteze curbate - parametrii procesării acesteia. Într-o config (cu noi - httpd), puteți introduce cât mai multe dintre aceste secțiuni doriți. Este convenabil pentru a crea mai multe fișiere de configurare, fiecare dintre care descriu jurnalele regulile de alternare un anumit demon (calmar, samba, apache). În cazul nostru, parametrii de procesare a fiecărui fișier, următoarele: de a se angaja într-un tratament săptămânal (în ciuda faptului că logrotate este administrat o dată pe zi), de a dispune de noi conectări de cinci ori și apoi ștergeți vechi, comprima fișierele primite, nimic de-a face cu jurnalul, dacă acesta goale și, în cele din urmă, nu intrați în panică dacă jurnalul specificat nu este găsit.
În cele din urmă - câteva sfaturi pentru gestionarea jurnalelor în rețele serioase. Deoarece informația despre evenimentele este foarte importantă în investigarea incidentelor și primul lucru care face haksory pe o roabă compromis - frecat busteni, atunci am recomandăm insistent să aibă un log-server separat, în cazul în care, în plus față de syslogd, nimic nu se va învârti (un computer vechi va face), și toate jurnalele de la toate mașinile trimit centralizat la ea, pentru că știți acum cum să o faceți. Numai în acest caz veți ști întregul adevăr despre evenimentele din rețea.
Syslog-ng poate procesa jurnalele folosind expresii regulate (bune pentru filtrarea mesajelor individuale, formatare, protocol de logare, etc.) și este capabil să transfere jurnalele într-o gazdă de la distanță prin TCP.
Socklog funcționează împreună cu daemontools și qmail. Conceput pentru cei care au înlocuit deja lega și sendmail și Qmail pe tinydns și vrea să găsească un înlocuitor adecvat pentru syslogd.
Msyslog oferă o arhitectură modulară pentru a facilita scris sislogu toate chips-uri, inclusiv păstrarea buștenilor într-o bază de date, filtrare bazate pe expresii regulate, etc.
Minirsyslogd este un daemon mic și sigur numai pentru acceptarea de jurnale de la gazde de la distanță prin rețea.
Adesea, un fișier nou este adăugat la config, uitând să-l creați (atingeți /var/log/file.log) sau uitați să reporniți syslogd.
Uneori, fișierul jurnal este uitat să fie înregistrat în newsyslogd / logrotate, drept urmare rămâne neprocesat și se extinde.
Trimiteți-le prietenilor: