Contact me sending an e-mail (antispam defense activated) |
Title: Gestione dei file di log Author: Sandro Tosi Last modified: 2007-05-27 Verranno qui presentati alcuni tool o tecniche per gestire i file di log. syslog, il log di sistema (anche in remoto) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ syslog e` lo strumento principale di raccolta e scrittura log su un sistema Linux. Il suo file di configurazione e` /etc/syslog.conf , e molte informazioni sono disponibili nelle manpage relative: man 3 syslogd man 8 syslogd (equivalente a man 8 syslogd) man 5 syslog.conf syslog puo` riceve messaggi sia tramite ``logger'', un tool per inviare messaggi a syslog (tramite Unix socket, spesso presente in /dev/log), oppure tramite network socket; quest'ultima possibilita` consente di creare un log server. Per fare cio`, si installa una macchina (dedicata sarebbe meglio, soprattutto in funzione del numero di nodi che loggeranno li` sopra) con syslog configurato per ricevere i log via socket (quindi avviando il deamon con l'opzione -r ``...receive message from the network...') che fungera` da log server. Lato client, la configurazione e` come segue (operando su /etc/syslog.conf): <facility>.* @<logserver_ip> per ogni facility che si vuole loggare sul logserver. Ulteriori e piu` approfonditi dettagli sono disponibili nella manpage, nella sezione ``SUPPORT FOR REMOTE LOGGING'' Un consiglio, soprattutto se i client sono su internet: cifrate la connessione. Per facilitare questa operazione, ed in quanto molto piu` evoluto e flessibile, e` vivamente consigliato installare syslog-ng e cifrare le comunicazioni con stunnel (che tunnellizza e wrappa in ssl un solo endpoint TCP, una porta per intendersi). Al posto di stunnel si puo` anche instaurare una vpn con openvpn, tra client e server. Inoltre, con syslog-ng, si evita di esporre su internet (se c'e` questa necessita`) un servizio che gira con i permessi di root. Liberare spazio cancellando i log ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Quando si ha carenza di spazio sul disco, la prima cosa che si puo` "sacrificare" sono i file di log. E` importante fare attenzione a NON cancellare un file ancora in uso da un processo. Linux rilascia lo spazio su disco solo quando tutti i link e tutti i file-descriptor ad un certo blocco sono 0. Se un processo sta scrivendo in un file di log, allora avra` un file-descriptor aperto verso quel logfile; effettuando $ rm logfile quello che si ottiene e` la cancellazione della entry nell'inode della directory corrente, ma in realta` i blocchi (e quindi lo spazio su disco) sono ancora in uso. Per recupera lo spazio, e` quindi molto meglio eseguire $ > logfile che redirige la stringa vuota su logfile, di fatto azzerandone la dimensione. Se il processo resetta i file-descriptor ai logfile tramite l'invio di SIGHUP (come syslog o apache, per esempio) allora si puo` anche eseguire # rm -f /var/log/messages && touch /var/log/messages && \ kill -SIGHUP `cat /var/run/syslogd.pid` Se si effettua il mv del file di log, il processo scrivera` nel file ``spostato'', perche' in realta` punta agli stessi inode. Una soluzione un po` piu` ``elegante'' a questo problema e` l'utilizzo di logrotate per gestire i logfile. logrotate per tenere sotto controllo la dimensione ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ logrotate e` in grado di ``ruotare'' i log per dimensioni o per ``eta`''; e` anche in grado di comprimere i file in automatico e/o eseguire apposite funzioni prima o dopo la rotazione. Tipicamente logrotate applica un semplice meccanismo di rotazione ai log per cui: - rinomina il file corrente applicando una numerazione progressiva, per cui app.log diventa app.0 e poi app.1.gz, app.2.gz ecc. (dal momento che spesso viene compresso con gzip) - si riparte con un nuovo logfile fino al successivo tempo/dimensione di rotazione (definito in logrotate.conf) Per configurare logrotate ci sono due posti: il file /etc/logrotate.conf o la directory /etc/logrotate.d/ . All'interno di /etc/logrotate.conf ci sono parametri generici che vengono applicati nel caso in cui non siano specificati parametri particolari. I file nella directory /etc/logrotate.d/ sono regole aggiuntive per le applicazioni che hanno necessita` di ruotare i propri log. Per aggiungere una regola di rotazione, prendete come esempio una di quelle gia` presenti. logrotate e` spesso eseguito da cron: per sapere l'orario della schedulazione, controllare crontab -l -u root, /etc/crontab e/o nelle directory /etc/cron.daily. Se la macchina non e` accesa quando dovrebbero girare gli script di logrotate, allora i log non verranno ruotati; conviene quindi utilizzare anacron (tipica situazione per i portatili). analisi e monitoring dei log ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Spesso nei log possono venir registrati molti eventi, e solitamente non siamo interessati a tutti essi, ma solo a quelli "anomali"; l'utilizzo di tool di analisi dei log diventa quindi molto comodo. Per i file di log di sistema, o comunque log in generale (per quanti consentono customizzazioni), possiamo utilizzare i seguenti tool: - logwatch ogni mattina invia un report dei messaggi di log del giorno precedente; e` customizzabile per applicazione e verbosita` - swatch un analizzatore real-time dei log che invia alert in base a certi filtri preimpostati per condizioni particolari - logcheck - colorize <http://colorize.raszi.hu/> piu` che un analizzatore e` un tool per colorare il log in modo da migliorarne la leggibilita` In particolare per Apache, abbiamo diversi tool specifici: - webalizer <http://www.mrunix.net/webalizer/> Molto bello esteticamente, veloce e facile. - analog <http://www.analog.cx/> un po' piu` spartano di webalizer - awstats <http://awstats.sourceforge.net/> Conviene disabilitare la possibilita` di aggiornamento online, altrimenti si sovraccarica la macchina con continue esecuzioni in automatico - modlogan <http://jan.kneschke.de/projects/modlogan/> Scrivere (o evitare) i log su una console ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oltre ai gia` visti strumenti di analisi e reporting dei log, alcuni amministratori di sistema decidono di stampare i messaggi di log su una console o su un terminale. La soluzione piu` semplice e`: # tail -f /var/log/kern.log # tail -f /var/log/messages ma questo richiede di avere una sessione aperta (tipicamente come root). Allora si puo` ridirigere i messaggi su un terminale virtuale: # tail -f /var/log/syslog > /dev/tty12 & (in questo caso il 12esimo), ma anche qui abbiamo il problema di avere permessi amministrativi (per poter leggere i logfile) e di avere un terminale aperto con un utente admin loggato. In realta`, la soluzione piu` elegante e` sfruttare le capacita` di syslog (o syslog-ng). Per esempio si puo` aggiungere a /etc/syslog.conf una entry come la seguente: # I like to have messages displayed on the console, but only on a # virtual console I usually leave idle. # daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty12 dove al posto di /dev/tty12 si puo` mettere una console a scelta (magari non una di login...). Per syslog-ng si puo` usare la sintassi: source local { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); }; destination tty12 { file("/dev/tty12" template("$FULLDATE $HOST $FACILITY.$PRIORITY $MSG\n") ); }; log { source(local); destination(tty12); }; Un altro utile tool per tenere sotto controllo i log e` ``root-tail'', che mette i log sullo sfondo del desktop; l'unica cosa e` stare attenti agli ambienti grafici, come kde o Gnome, che ``disegnano il desktop'': in questo caso root-tail non funzionera` in quanto l'ambiente grafico ``ridisegna'' il desktop sovrascrivendo root-tail. Esiste, pero`, anche il problema opposto: evitare che dei messaggi di log finiscano nei terminali/console (quanto e` fastidioso editare un file con vi e ricevere questi messaggi...). Molto dipende da che sorgente sono generati questi messaggi; un primo punto dove andare ad agire e` /etc/init.d/klog mettendo KLOGD="-c 4" in modo da forzare klogd (il daemon che raccoglie i messaggi del kernel) a stampare i messaggi con priorita` <= 4; le priorita` sono valori compresi tra 0 e 7, con un decrescente valore di criticalita`, come indicato in /usr/include/linux/kernel.h: [...] #define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ [...] |