Il log è il migliore amico del programmatore

Immaginiamo questo scenario: è trascorso po’ di tempo dall’ultimo deploy in produzione della nostra web application e scopriamo che c’è qualcosa che non va. Qual è il primo “strumento” che ci può supportare nell’identicazione e analisi del problema? Il log, ma la nostra applicazione non genera file di log! Ecco persa un’opportunità di risolvere il problema.

La situazione precedentemente descritta, molto spesso è la routine. Infatti, quando uno sviluppatore scrive del codice è difficile che per sua spontanea abitudine introduca il logging nell’applicazione. Quando il logging è un requisito dell’applicazione succede allora che i messaggi di log risultino poco significativi e irrilevanti. Ciò accade perchè al logging non viene data la giusta importanza, anzi la si considera generalmente una perdita di tempo, a maggior ragione quando si tratta di progetti di piccole dimensioni.

Succede che per individuare il problema si faccia ricorso ad altri log, ovviamente non dell’applicazione, ma ad esempio del web server o magari dell’interpetre PHP, con la speranza che su di essi si trovi traccia di qualcosa che non va. La ricerca produce i risultati sperati se il problema genera un errore o una situazione eccezionale tale da essere riportata nei predetti log.

Logging e monitoring di un sistema software in produzione dovrebbero essere la normalità. Anche se il nostro software sembra funzionare egregiamente, l’attività di analisi dei log dovrebbe essere un’attività che accompagna quanto meno i momenti successivi al go live. Leggendo i log e gli errori generati dall’applicazione si trovano molto spesso bug subdoli che a lungo andare possono creare anche danni insapettati in considerazione del dominio applicativo.

Qual è la soluzione al problema? E’ semplice: introdurre all’interno delle applicazioni un utile strato di logging. Il log è il mezzo attraverso il quale la nostra applicazione ci parla. E’ lo “strumento” più utile per risolvere problemi operazionali.

Il log non deve interessare solo i casi negativi delle azioni: ad esempio se l’azione è memorizzare un’informazione sul database il log deve registrare sia quando l’azione va a buon fine, sia quando essa fallisce. In quest’ultimo caso è bene avere quante più informazioni possibili per poter analizzare il caso di errore e prendere le dovute precauzioni affinchè ciò non accada (quindi informazioni dettagliate sull’errore ma anche informazioni sul contesto che ha generato l’errore).

Alcuni sistemi di logging prevedono che in base alla gravità dell’informazione registrata si produca una notifica verso il gestore dell’applicazione attraverso i più disparati mezzi di comunicazione: e-mail, SMS, push notification, Twitter direct message, etc.

Lo standard RFC 5424 definisce il “syslog protocol”. All’interno del documento di IETF si definisce il livello di importanza di ogni messaggio di log. Ecco la tabella che riepiloga “Syslog Message Severities”:

Numerical code = Severity
0 = Emergency: system is unusable
1 = Alert: action must be taken immediately
2 = Critical: critical conditions
3 = Error: error conditions
4 = Warning: warning conditions
5 = Notice: normal but significant condition
6 = Informational: informational messages
7 = Debug: debug-level messages

Il numerical code è un intero da 0 a 7 che indica la gravità del messaggio di log. Più l’errore è grave, più il numerical code tende a 0.

Ogni linguaggio e framework mette a disposizione specifiche librerie per il logging. In PHP ad esempio Symfony2 e Laravel 4/5 sposano il progetto Monolog che è basato sullo standard di logging PSR-3.

Le cose si complicano quando ad esempio se parliamo di un’applicazione web che è servita da più web server. In questi casi è necessario avere un sistema di logging che si presenti all’utente attraverso un unico punto di accesso. Inoltre i tool che supportano la gestione dei log consentono di effettuare un’efficiente ricerca all’interno delle interminabili righe di log.

Esistono poi soluzioni in cloud per il logging come LogEntries.com. Esso prevede persino un piano gratuito per progetti di dimensioni contenute.

Quanto detto fin qui in merito al logging non è da riferirsi solo alle applicazioni tradizionali web e desktop, ma deve essere applicato anche al mondo delle applicazioni mobile e dell’Internet of Things. Si pensi a quanto possa essere utile che la propria mobile app supporti lo sviluppatore nella ricerca e correzione di crash, fornendo stack trace e metadati.