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 */
[...]