Logging…. mistery

Come si deve scrivere un file di log? cosa si deve loggare? Sono due domande non da poco se ci si pensa bene, che di solito si trascurano e si deve poi correre ai ripari con lunghe sessioni di debug, sperando di aver capito veramente dove è il problema. Provo quindi a dare una risposta un po articolata su come la vedo.

Il perchè del logging
Con la parola logging cosa viene in mente? la prima cosa che mi viene in mente è forse la più ovvia, per tenere traccia dei malfunzionamenti del sistema (ES. E_ERROR, E_WARNING in php, Exception in java), quindi un utile strumento per fare la diagnosi in caso di errori; subito dopo mi vengono in mente i sistemi di logging per tenere traccia di quanti accessi avvengono su un sito, quanto un utente vi naviga, quello insomma che sta dietro a servizi come Shinystat o a Lloogg. Se poi penso ai database in Mysql nelle tabelle InnoDB i log vengono usati per poter fare recovery e transizioni; si hanno quindi più ambienti in cui servirsi dei log file, e soprattutto cose diverse di cui tenere conto nei log.

Come loggare
Visto che è importante loggare la prima cosa da pensare è : c’è una metodologia da applicare per avere dei buoni log? Non so se esistono delle metodologie formali (eccezzione fatta per problematiche come il real time) scriverò quindi qui di seguito quello che uso io (dopo ben 9 anni di programmazione); gli aspetti che ho analizzato sono:

  • Location
  • Content
  • Final….Destination

Location
I file di log non si possono mettere tutti assieme, dopo poco tempo senno si ha il caos, vanno messi in cartelle in maniera struttura divisi per applicazione (Es. httpd,samba,mioApp,… ); i log sono legati al tempo, è quindi opportuno salvare i log dando una struttura a cartelle basata sul tempo: Es. 2008/07/29 [aaaa/mm/gg] e poi al suo interno i log della giornata; trovo poco utile suddividere anche per ore, il tutto cmq. dipende dalle esigenze dell’applicazione si potrebbe decidere di ruotare i log anche mensilmente! Se i log superano una certa dimensione (Es. 5Mb) è utile splittarli per non avere rallentamenti nella fase di scrittura; nasce quindi il problema dell’estensione da dare al file, solitamente si fa .log , .log.001 , .log.002 , etc, etc. (Lo si può notare nei log di *nix). Se il nostro applicativo inoltre è modulare sarebbe carino che dentro la cartella temporale ci fosse un file per modulo in modo da avere una visione sia locale che globale ( o si fa la join delle parti o si crea cmq. un file che recepisce tutto direttamente) del sistema.

Content
Cosa deve contenere un file di log?

  • Solo quello che serve, essere troppo verbosi può rendere difficile la lettura del file;
  • Ogni riga del log dovrebbe avere la stessa struttura, l’occhio vuole la sua parte, mentre legge ne trarrà beneficio.
  • Timestamp su ogni riga per avere una visione temporale; meglio cose come “Jun 19, 2008 4:20:13 PM Errore da notificare [File,Riga]” è sicuramente più utile di “108992371 Errore da notificare” (Io i timestamp non li so ancora convertire al volo)
  • Se l’errore è fatale uno stack trace forse è opportuno, e magari non va messo nel log file ma in un file a parte scrivendo nel log il file che si è creato Es:
    Jun 19, 2008 4:20:13 PM Errore da notificare [File,Riga]
    Jun 19, 2008 4:20:14 PM Created stacktrace file : stacktrace.001.log

    o direttamente
    Jun 19, 2008 4:20:13 PM Errore da notificare [File,Riga] [stacktrace.001.log]
  • Mai mettere nei log informazioni sensibili come password o username/email meglio identificativi interni (Es: id tabella)
  • Usare i \t o i ; (stile csv) per dare una struttura tabellare, facilita la auto-lettura da parte di software di analisi

Final….Destination
Per ultima ma sicuramente la cosa più importante è: capire a chi va il log, ossia chi lo sfruttera! lo sviluppatore? l’amministratore di sistema? Ogni destinatario predilige certe informazioni su altre, è quindi importante pensare 5 minuti a chi sarà destinato il file di log per poter applicare i tip sopra descritti al meglio.

PS: sicuramente qualcosa ho tralasciato… vedro in caso di aggiornare nei prossimi giorni.

Tags:

Comments are closed.