In tutti i progetti di sviluppo software ai quali si partecipa occorre eseguire una pratica comune: scrivere i log applicativi.
Laggare vuol dire monitorare il comportamento del sistema e permettere un’analisi delle attività registrate per migliorare i sistemi sviluppati o reperire informazioni relative ad un comportamento anomalo dell’applicazione.
Esistono diverse librerie e diversi tool per loggare un sistema e tutte dipendono dal linguaggio di programmazione che si usano, inoltre ogni libreria di log prevedere una configurazione specifica (semplice a piacere).
Lavorando con architetture a microservizi è stato notato che è possibile utilizzare i microservizi stessi per ottimizzare i log da inoltrare ad un qualunque tool che viene utilizzato per la raccolta e l’analisi, un esempio potrebbe essere un sistema come ELK (Elasticsearch, Logstash, e Kibana).
Di seguito un’architettura a microservizi che prevede la possibilità di inoltrare i log delle singole attività sfruttando la potenza dei microservizi stessi. La gestione dei log avviene attraverso le code utilizzando un qualunque sistema AMQ (Advanced Message Queuing), nel nostro esempio utilizzeremo RabbitMQ:
Supponendo di utilizzare RabbitMQ come software open-source di message-broker, possiamo utilizzare una componente del software chiamata exchange che permette di inoltrare i messaggi in code specifiche se etichettati nel modo opportuno. Nel nostro caso possiamo etichettare i singoli messaggi come “logger” e quindi inoltrarli tutti in un’unica coda dalla quale uno o più microservizi ( nel gergo delle code definiti consumatori) catturano il messaggio e lo inoltrano al sistema ELK designato. Il livello di log può essere definito tramite configurazione del microservizio che inoltrerà al sistema ELK i log di diverso livello seguendo la gerarchia già nota a tutti gli sviluppatori e riportati in figura (la X rappresenta l’attivazione dei livelli di log):
| Fatal | Error | Warn | Info | Debug | Trace | All | |
| OFF | |||||||
| Fatal | X | ||||||
| Error | X | X | |||||
| Warn | X | X | X | ||||
| Info | X | X | X | X | |||
| Debug | X | X | X | X | X | ||
| Trace | X | X | X | X | X | X | |
| All | X | X | X | X | X | X | X |
Così implementato il sistema permette di gestire i log anche utilizzando delle modalità proprietarie definita da un possibile Cliente che per esigenze interne non può richiedere particolari strisce di log che rispettano lo standard interno già definito.
Migliorato e tradotto in inglese ecco il mio stesso articolo nel blog della società dove lavoro https://insights.kdmforce.com/2020/03/10/custom-logging/