Indice dei contenuti
Questo articolo è il primo di una serie di approfondimenti che illustrano come implementare un meccanismo di structured logging (registrazione strutturata degli eventi) per una tipica applicazione web realizzata con ASP.NET Core 5 e C# facendo uso di due strumenti che sfruttano le API fornite dall'interfaccia ILogger presente nel namespace Microsoft.Extensions.Logging:
- Azure Application Insights, il servizio di monitoraggio fornito da MS Azure.
- Serilog, una libreria open-source di registrazione diagnostica per applicazioni .NET disponibile su NuGet che consente di memorizzare i suddetti log sui database management system più diffusi, tra cui SQL Server e MariaDB.
In questo approfondimento, prima di addentrarci nel codice di una tipica applicazione ASP.NET 5 Core, ci occuperemo di introdurre la definizione e spiegare il concetto di logging applicativo: cos’è, come funziona e perché è diventata un’esigenza sempre più importante nel corso degli ultimi anni. Si tratta dunque di una serie di informazioni utili a prescindere dal linguaggio di programmazione utilizzato e che saranno fondamentali per affrontare gli articoli successivi.
Definizione
Il punto migliore da cui partire è probabilmente la definizione del termine “log” in un contesto informatico e prima ancora sistemistico: la parola log viene utilizzata per riferirsi alla registrazione sequenziale e cronologica delle operazioni effettuate, man mano che queste vengono eseguite dal sistema. Ovviamente, queste operazioni possono essere effettuate da una pluralità di attori diversi: utenti, amministratori di sistema, o anche automatizzate, quindi dal sistema stesso.
Per esteso, il termine viene utilizzato anche per riferirsi al file o all’insieme di file su cui tali registrazioni vengono memorizzate: in altre parole, talvolta si utilizza la parola log per indicare il file di log o il registro dei log, facendo uso di una figura retorica nota come metonìmia: un pò come quando diciamo “bere una bottiglia”, intendendo ovviamente l’acqua o la bevanda contenuta all’interno della bottiglia.
Dal solcometro al registro dei log
Una cosa che forse non tutti sanno è che questo utilizzo del termine log, il cui significato letterale in lingua inglese è quello di ceppo di legno, non è nato con l’elettronica o con l’informatica, ma in ambito nautico, più o meno intorno al 18esimo secolo. In quel periodo, la parola log era utilizzata in gergo nautico per riferirsi al pezzo di legno che veniva fissato a una fune e lasciato galleggiare fuori dalla nave.
Sulla fune venivano fatti una serie di nodi che potevano essere contati per determinare la velocità della nave: la velocità era pari al numero di nodi che restavano fuori dall’acqua. Questo rudimentale ma efficace strumento di misurazione, noto come solcometro, è il motivo per cui ancora oggi la velocità delle imbarcazioni è espressa in nodi.
Ovviamente, però, la velocità dell’imbarcazione poteva variare anche molto nel corso del tempo, in quanto era inevitabilmente influenzata da circostanze esterne, come ad esempio le condizioni atmosferiche, la forza e la direzione del vento, e così via: per questo motivo le misurazioni del solcometro venivano ripetute a intervalli più o meno regolari e annotate in un apposito registro, insieme a tutte le altre informazioni a corredo: il nome con cui veniva chiamato questo registro è logbook, e costituisce dunque il primo esempio di registro dei log propriamente detto.
L’importazione nel concetto di logbook dal gergo nautico a quello informatico avviene all’inizio degli anni 60 e determina l’introduzione di una serie di definizioni correlate, tra cui i concetti di log in (registrazione in ingresso) e log out (registrazione in uscita). Da quel momento in poi l’importanza dei log in ambito informatico e sistemistico è aumentata esponenzialmente, creando e alimentando un vero e proprio settore di mercato, quello del Log Management, che si calcola arriverà a toccare i 1200 milioni di dollari entro il 2022.
Questa espansione è stata ovviamente determinata dall’importanza crescente degli strumenti informatici, rispetto ai quali i log sono un asset importantissimo in quanto consentono di far fronte a una serie di necessità.
A cosa servono i log?
Proviamo ad elencare gli aspetti più importanti di un'applicazione che possono realisticamente beneficiare della presenza di un sistema di logging:
- Stabilità, in quanto consentono di intervenire in modo efficace su eventuali bug o comportamenti anomali;
- Sicurezza, in quanto consentono di determinare se il sistema presenta delle vulnerabilità e, in caso affermativo, in che misura queste vulnerabilità sono state sfruttate.
- Continuità di servizio, in quanto le attività di monitoring dei log possono essere effettuate anche da altri sistemi automatizzati che possono agire in conseguenza di registrazioni anomale: inviare alert o e-mail, suonare allarmi, applicare automaticamente delle remediation, riavviare servizi difettosi o non funzionanti, e così via.
Per tutti questi motivi, oggi tutte le principali normative internazionali sulla sicurezza informatica prevedono obbligatoriamente la creazione di precise policy di logging. Questo atteggiamento, che negli ultimi anni si è ulteriormente rafforzato a seguito dell’introduzione del GDPR e dell’ingresso delle normative sulla protezione dei dati a livello di compliance aziendale, ci consente di affermare una cosa molto importante: il log management non va visto solo come un utile strumento per tenere sotto controllo i nostri applicativi, ma come un requisito imprescindibile per garantire la loro affidabilità e un asset fondamentale in termini di sicurezza informatica, specialmente in un contesto enterprise.
Conclusioni
Per il momento è tutto: nel prossimo articolo parleremo degli strumenti messi a disposizione dal framework .NET 5 per gestire questo aspetto così importante all’interno dei nostri applicativi. In particolare ci dedicheremo allo studio delle logging API messe a disposizione attraverso l’interfaccia ILogger, che consentono di effettuare registrazioni attraverso una serie di logging provider predefiniti, nonché di terze parti.
Articoli correlati
- Indice degli argomenti
- ASP.NET Core 5 Application Logging: concetti di base
- Application Logging in .NET 5: Logging Provider predefiniti
- Differenze tra Log strutturati e non strutturati
- Structured Logging con Azure Application Insights
- Structured Logging su DBMS con Serilog
