Log: A cosa servono?

Come sta il paziente?
I suoi parametri dicono che risponde, quindi è vivo
Bene

Questa conversazione me la sono immaginata pensando come se un software online fosse un paziente in ospedale. Viene tenuto costantemente monitorato e quindi, se ci fossero problemi qualcuno viene allertato, senza dover stare a guardarlo continuamente nella speranza che faccia qualcosa.

Dalla sopravvivenza alla conoscenza totale

I log più base che si possa avere è il semplice fatto che risponda alle chiamate (per un servizio web).
Quando viene messo in cloud, come in kubernates, la prima chiamata fondamentale è il health-check. Se risponde a quello, almeno in generale il sistema potrà rispondere ad altre richieste e il sistema che lo tiene su sa di non doverlo riavviare.

Ma questo è solo la base, ma ci sono altre mille sfaccettature che ci permettono di capire la situazione del nostro software sia per le operazioni che fa internamente, sia relative ad altri sistemi esterni.

I livelli

Ogni libreria di log ha generalmente questi livelli:

  • Debug
  • Info
  • Warning
  • Error
  • Critical

L’utilizzo ci permette di riuscire a filtrare meglio gli errori e capire su cosa ci dobbiamo preoccupare di più.

Dal libro “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”, una frase per capire bene la differenza tra il livello di warning ed error diceva questo:

Se compare un log di error alle 2 di notte, bisogna andare a fixarlo, ma il livello del toner di una stampante non è un emergenza da affrontare

Durante l’esecuzione di un software in produzione, avevo notato che un livello di log troppo alto che avevo messo (e che racchiudeva più casistiche) non mi permetteva di capire bene quello che stava succedendo e soprattutto come comportarmi.

Sii specifico!

Questo è quello che cerco di fare con i log, così da poter avere subito un quadro della situazione.

Rispetto alla risposta da dare indietro, dove a volte è necessario essere generici anche per questioni di sicurezza, specificare tutti i casi del software ci permette di capire meglio la situazione in qualunque momento.

Da quando si inizia a fare una richiesta a un servizio esterno, a quando si sta processando molti dati o altre interazioni, aggiungere log per capire lo stato ci permette di tenerlo sotto controllo e capire che cosa non va bene.

Per fare un esempio, se ogni elemento che andiamo a inserire è importante e “pesante” a livello computazionale, si potrebbe loggare l’inizio e la fine di ogni operazione, per permetterci di capire a che punto si è interrotto e che cosa ci aspettiamo.

E ma costa?

Come tutto quello che si fa, anche questo potrebbe costare a livello di tempo per il codice e implementazione operazionale.

Più log, più spazio usato, più tempo d’esecuzione e anche più banda usata.

Ma non dovrebbe arrivare a una scala di costi così alto rispetto al tempo che risparmiamo durante un emergenza e soprattutto la riduzione del numero di emergenze visto che possiamo essere pro attivi e così l’utente non vedrà neanche il problema.

Con cosa lo abbiniamo?

Ovviamente da soli i log potrebbero non bastano.
Potremmo stare tutto il giorno a guardarli, ma non è lo scopo del nostro lavoro, soprattuto visto che automatizziamo tutto.

Quello che possiamo fare è anche quello di aggiungere il monitoraggio, per permetterci di avere un allerta in caso di situazioni particolari.

Un esempio è che una funzione, che generalmente viene usata 100 volte all’ora, ci troviamo, al pari di altre condizioni, con un uso di 1k all’ora.
Questa informazione, che di per se non è un errore, ci potrebbe far attivare per indagare sull’accaduto, capendo meglio la situazione e agendo in caso questo sia diventato un problema.

Oppure, molto più semplicemente, per ogni log di errore ci arriva una notifica, così da prendere in carico il problema ancora prima che l’utente ci avverta.

Conclusione

Come per i test automatici, questo strumento ci aiuta nel capire come in produzione il nostro software sta andando, stando più tranquilli sul risultato.

Più dati abbiamo e meglio capiamo cosa sta succedendo, per poter decidere che cosa fare.

Articoli correlati: