Indice dei contenuti
Questo articolo è il secondo di una serie di approfondimenti che illustrano come implementare un meccanismo di structured logging (registrazione strutturata degli eventi) all'interno di 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 secondo approfondimento ci dedicheremo all'analisi degli strumenti che ci mette a disposizione il 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. Questa interfaccia è stata introdotta con la prima versione di .NET Core, quindi è stata integrata all’interno di .NET Standard, ed è oggi disponibile anche in .NET 5.
Logging Provider
Con il termine Logging Provider intendiamo quei componenti che si occupano della registrazione dei log all’interno di determinati contenitori o visualizzatori di dati. Ad esempio, il Console Provider si occupa della visualizzazione dei log all’interno della console di sistema, ovvero a schermo; l’Azure Application Insights Provider si occupa della memorizzazione dei log all’interno di Azure Application Insights; e così via.
Questo è l’elenco dei logging provider messi a disposizione dal framework attraverso una serie di estensioni ad-hoc:
-
- Console (log scritti all’interno della console di sistema)
- Debug (log visualizzabili all’interno dell’ambiente di debug, come ad esempio la output window di Visual Studio, quando è collegato un debugger)
- EventSource (log “emessi” a livello di runtime e catturabili mediante event tracing per mezzo di strumenti appositi a seconda del sistema operativo del server (ETW su Windows, LTTng su Linux, etc.)
- EventLog (registro eventi - solo su server Windows)
- AzureAppServicesFile
- AzureAppServicesBlob
- ApplicationInsights
Ciascuno di questi provider può essere attivato singolarmente e autonomamente rispetto agli altri.
Ad esempio, quando istanziamo la nostra applicazione utilizzando il Generic Host e chiamiamo il metodo CreateDefaultBuilder, come previsto dalla quasi totalità dei template predefiniti per le applicazioni ASP.NET Core 5, vengono automaticamente abilitati i provider Console, Debug, EventSource ed EventLog, quest’ultimo ovviamente solo nel caso in cui la nostra applicazione giri su server Windows in quanto si tratta del provider che scrive nel registro eventi di Windows.
Per comprendere meglio questo concetto, diamo un'occhiata al codice sorgente di una tipica Web Application in ASP.NET Core 5 creata utilizzando il template predefinito presente in Visual Studio, selezionando il framework ASP.NET Core 5.0.
Se diamo un’occhiata al codice già presente nel template possiamo vedere, nel file Program.cs, che il GenericHost viene creato utilizzando il metodo CreateDefaultBuilder, quindi configurando i logging provider di cui abbiamo parlato sopra.
|
1 2 3 4 5 6 7 8 9 |
/// <summary> /// Creates a HostBuilder with default configuration settings /// </summary> public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }); |
Un esempio molto embrionale di configurazione dei suddetti log è presente nel file appsettings.json, che contiene i principali parametri di configurazione dell’applicazione.
|
1 2 3 4 5 6 7 8 9 10 |
{ "Logging": { "LogLevel": { "Default": "Information", "Microsoft": "Warning", "Microsoft.Hosting.Lifetime": "Information" } }, "AllowedHosts": "*" } |
Come possiamo vedere, è stato definito un LogLevel uguale per tutti i provider, che peraltro resta il medesimo a prescindere dall’environment con cui viene eseguita l’applicazione. Il Log Level, come suggerisce il nome, rappresenta la tipologia di log che viene emesso dal sistema: vediamo di fornire qualche informazione in più su questo importantissimo parametro di configurazione.
LogLevel
I Log Level messi a disposizione dal framework sono i seguenti:
- Trace: registrazioni relative alle attività interne dell’applicazione e utili soltanto per il debug delle operazioni a basso livello. Si tratta di un loglevel raramente utilizzato, anche perché può contenere dati riservati (come il controllo di chiavi di crittografia o altre informazioni “sensibili” che è bene non memorizzare o visualizzare).
- Debug: registrazioni utili per per l'analisi interattiva durante lo sviluppo, ovvero per il debug: anche in questo caso, si tratta di log che è bene disabilitare negli ambienti di produzione in quanto potrebbero contenere informazioni che è bene non divulgare. Da non confondere con il Debug Provider.
- Information: messaggi informativi, ovvero che descrivono eventi relativi al normale comportamento del sistema.
- Warning: registrazioni che descrivono comportamenti anomali o imprevisti ma che non causano l’arresto dell’esecuzione dell’applicazione.
- Error: registrazioni che evidenziano il momento in cui il flusso di esecuzione corrente viene interrotto a causa di un errore: si tratta quindi di messaggi di errore relativi all’attività corrente e non a livello di applicazione.
- Critical: registrazioni relative a eventi che descrivono un arresto anomalo irreversibile dell’applicazione.
- None: nessuna registrazione.
Ovviamente, il LogLevel che andremo a impostare all’interno del file appsettings rappresenta il livello minimo inclusivo di registrazione che ci interessa effettuare, trascurando quindi tutti gli eventi di minor entità e registrando anche tutti quelli di entità maggiore. In questa configurazione stiamo quindi dicendo al sistema che siamo interessati a vedere più o meno tutti i log relativi al funzionamento normale o anomalo della nostra applicazione, escludendo soltanto quelli utili per il debug.
Abilitare e disabilitare i Logging Provider
Ovviamente, oltre a decidere cosa loggare, le logging API di .NET Core consentono anche di abilitare o disabilitare ciascun logging provider in modo selettivo.
Ad esempio, qualora volessimo eliminare dalla configurazione dell’Host Generico i logging provider aggiunti dal metodo CreateDefaultBuilder, potremmo utilizzare il metodo ConfigureLogging per rimuoverli, in questo modo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
/// <summary> /// Create a HostBuilder with custom logging configuration settings /// </summary> /// <param name="args"></param> /// <returns></returns> public static IHostBuilder CreateHostBuilder_WithCustomLogging(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureLogging(logging => { // removes all logging providers from the configuration logging.ClearProviders(); // adds the "Console" logging provider to the configuration logging.AddConsole(); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }); |
In questo modo andremo a definire un override della configurazione predefinita, prima disabilitando tutti i Logging Provider e poi riabilitando soltanto quello relativo alla Console.
Conclusioni
Per il momento è tutto: questa breve panoramica, che non proseguiremo ulteriormente per ragioni di tempo, dovrebbe darci una idea di massima sul funzionamento delle logging API messe a disposizione da .NET 5. Nel prossimo articolo parleremo dei vantaggi dello Structured Application Logging, ovvero delle tecniche che consentono di registrare questo tipo di informazioni in modo strutturato... ad esempio all'interno di un Database relazionale come Microsoft SQL Server o MariaDB.
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
