Nello scorso script (https://www.aspitalia.com/script/1348/Correlare-Log-Applicazione-Distribuita-ASP.NET-Core.aspx) abbiamo visto come il correlation ID sia utilissimo nel caso di architetture a microservizi, in quanto ci permette di correlare tra loro trace di applicazioni differenti.
In realtà, si tratta di uno strumento che può tornare incredibilmente utile anche in architetture più semplici: immaginiamo il tipico caso di un sito in produzione, che restituisca un errore 500. Come sappiamo, per motivi di sicurezza, non è saggio ritornare dettagli dell'errore al browser, perché potrebbero essere utilizzati per scoprire vulnerabilità applicative. Quello che possiamo fare, però, è ritornare un codice univoco, che possiamo utilizzare poi per filtrare i nostri log: il correlation ID, per l'appunto.
Come farlo in maniera centralizzata? In ASP.NET Core è sufficiente creare un middleware che si occupi di catturare tutte le eccezioni non gestite - del tutto analogo a quello di default, utilizzato per mostrare un messaggio generico nella risposta.
Il nostro punto di partenza è il metodo Configure della classe Startup:
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseHttpsRedirection(); app.UseExceptionHandler(builder => { builder.Run(async context => { var response = new ErrorResponse() { ErrorMessage = "There was an error while processing your request.", CorrelationId = Activity.Current?.RootId }; context.Response.ContentType = "application/json"; await context.Response.WriteAsync(JsonSerializer.Serialize(response)); }); }); app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapControllers(); }); }
Il metodo UseExceptionHandler è quello tramite cui possiamo registrare un middleware da mandare in esecuzione nel caso di eccezioni non gestite. Al suo interno, non facciamo altro che costruire un oggetto ErrorResponse (una semplice classe POCO con due proprietà ErrorMessage e CorrelationId) tramite il quale possiamo restituire il RootId della Activity corrente che, come abbiamo visto nello script precedente, altri non è che un indicatore univoco dell'intera catena delle chiamate. Successivamente serializziamo l'oggetto e lo inviamo nello stream di risposta.
In questo modo, il body ritornato con uno status code 500 sarà simile al seguente:
{ "ErrorMessage":"There was an error while processing your request.", "CorrelationId":"1e28e3c4-48c00f784e55e309" }
Questo codice, se opportunamente incluso nei log, ci permetterà di identificare immediatamente le righe relative all'eccezione che si è verificata.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare Hybrid Cache in .NET 9
Eseguire query in contemporanea con EF
Fornire parametri ad un Web component HTML
Combinare Container Queries e Media Queries
Collegare applicazioni server e client con .NET Aspire
Gestione degli eventi nei Web component HTML
Introduzione ai web component HTML
Integrare un servizio esterno con .NET Aspire
Utilizzare Container Queries nominali
Usare i servizi di Azure OpenAI e ChatGPT in ASP.NET Core con Semantic Kernel
Creare agenti facilmente con Azure AI Agent Service
Utilizzare l'espressione if inline in una pipeline di Azure DevOps
I più letti di oggi
- Gestione ciclo di vita in .NET Aspire
- Sfruttare i nuovi overload di TimeSpan.From* per creare timespan usando numeri interi
- vuoi scoprire tutte le novità per #wpdev in #wp81? iscriviti subito al nostro evento dell'08/07 a Milano! https://aspit.co/wp81-day
- #MAUI per sviluppare applicazioni #Windows e #XPlatf con #net5 con @leoncini117 Seguiteci live su #aspilive da https://aspit.co/ReBuild-20
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Centralizzare gli endpoint AI Foundry con Azure API Management