I vantaggi di Azure Application Insights

Quando un’applicazione smette di funzionare in produzione, il primo problema spesso non è correggere il bug. È capire cosa è successo.

Azure Application Insights aiuta in questa indagine. Raccoglie la telemetria di un’applicazione e riunisce in Azure Monitor richieste, dipendenze, eccezioni, log e informazioni sulle prestazioni. Invece di consultare file separati e tentare di ricostruire manualmente un errore, offre un unico punto in cui seguire l’operazione, dalla richiesta in entrata alle chiamate effettuate dall’applicazione.

Questa visibilità è utile anche per una piccola applicazione .NET. La configurazione iniziale è semplice e i dati raccolti possono rispondere a domande pratiche come:

Quali endpoint stanno generando errori?
Quali richieste sono lente?
È il database o un’API esterna a causare il ritardo?
Quale eccezione si è verificata durante una richiesta?
Il problema ha interessato una sola operazione o più utenti?

Application Insights non risolve automaticamente questi problemi. Il suo vantaggio principale è sostituire parte delle ipotesi con dati osservabili.

Cosa raccoglie l’integrazione .NET

Microsoft consiglia la distribuzione OpenTelemetry di Azure Monitor per le nuove applicazioni ASP.NET Core. OpenTelemetry utilizza tre segnali principali: trace, metriche e log.

Con la configurazione standard di ASP.NET Core, Application Insights può ricevere:

richieste HTTP in entrata, inclusi durata e stato;
chiamate in uscita effettuate con HttpClient;
chiamate di dipendenza supportate verso SQL e gli SDK di Azure;
eccezioni non gestite e relativi stack trace;
log scritti tramite ILogger;
metriche e dati di correlazione che collegano un’operazione alla telemetria associata.

La correlazione è uno degli aspetti più utili. Una richiesta non riuscita può essere collegata alla relativa eccezione e alla chiamata di dipendenza che ha generato l’errore durante la stessa operazione.

Per i log applicativi, i livelli generalmente più rilevanti in produzione sono:

Information per eventi selezionati dell’applicazione;
Warning quando si verifica qualcosa di inatteso, ma l’operazione può continuare;
Error quando un’operazione non riesce;
Critical quando l’applicazione o una funzionalità essenziale non può continuare in sicurezza.

Debug e Trace sono utili durante lo sviluppo, ma inviarne grandi quantità in produzione può creare rumore e aumentare il volume della telemetria.

I log strutturati rendono inoltre i dati più facili da cercare:

logger.LogWarning(
    "Order {OrderId} could not be sent to provider {Provider}",
    orderId,
    providerName);

In questo esempio, OrderId e Provider diventano proprietà ricercabili invece di rimanere nascosti all’interno di un unico messaggio lungo.

ASP.NET Core continua a controllare quali livelli di log vengono esportati. Una semplice configurazione di produzione può conservare le informazioni dell’applicazione riducendo il normale rumore del framework:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}

Questo è soltanto un punto di partenza. Un servizio può richiedere log più dettagliati per un namespace e meno dettagliati per un altro. L’obiettivo è conservare gli eventi utili a un’indagine ed eliminare i messaggi ripetuti che non cambiano la diagnosi.

Cosa non viene raccolto automaticamente

La strumentazione automatica ha dei limiti. Application Insights non può segnalare informazioni che l’applicazione non ha mai prodotto.

Alcuni esempi:

un’eccezione intercettata e poi ignorata senza essere registrata;
un evento di business privo di log, trace o telemetria personalizzata;
un’operazione eseguita da una libreria senza strumentazione supportata;
i corpi delle richieste e delle risposte;
errori che si verificano prima che il traffico raggiunga l’applicazione;
visualizzazioni di pagina ed errori JavaScript quando il browser SDK non è installato.

Non bisogna aggiungere informazioni sensibili per colmare queste lacune. Password, token di accesso, stringhe di connessione, dati di pagamento e dati personali non devono essere inclusi nella telemetria.

Monitoraggio del backend e del browser

Il monitoraggio del backend viene eseguito all’interno dell’applicazione .NET. Osserva le richieste del server, le eccezioni, i log dell’applicazione, le chiamate al database e le operazioni HTTP in uscita.

Il monitoraggio del browser viene eseguito sul dispositivo del visitatore tramite il JavaScript SDK di Application Insights. Può registrare visualizzazioni di pagina, prestazioni lato client, sessioni ed errori JavaScript.

Queste due prospettive rispondono a domande diverse. La telemetria del backend può mostrare che un’API ha restituito un errore. Quella del browser può mostrare cosa ha visto il visitatore prima che la richiesta venisse effettuata. Un’API potrebbe richiedere soltanto il monitoraggio del backend, mentre un’applicazione Razor Pages, Angular o React può utilizzare entrambi quando il comportamento lato client è importante.

Configurazione di base in ASP.NET Core

Installa il pacchetto Azure Monitor OpenTelemetry nel progetto web:

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

Registra quindi Azure Monitor in Program.cs:

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddOpenTelemetry()
    .UseAzureMonitor();

var app = builder.Build();
app.Run();

Application Insights utilizza una stringa di connessione per stabilire dove inviare la telemetria. In produzione, Microsoft consiglia di fornirla tramite l’ambiente:

APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=...

Il valore proviene dalla risorsa Application Insights nel portale di Azure e deve rimanere fuori dal controllo di versione. Dopo che l’applicazione inizia a ricevere traffico, la telemetria può impiegare alcuni minuti per comparire.

Una prima query KQL

Il portale di Azure include già viste per errori, prestazioni, metriche in tempo reale e dipendenze dell’applicazione. Per domande più specifiche, Log Analytics utilizza il Kusto Query Language.

Questa query elenca le richieste non riuscite nelle ultime 24 ore:

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| project TimeGenerated, Name, ResultCode, DurationMs, OperationId
| order by TimeGenerated desc

L’OperationId aiuta a collegare una richiesta ai relativi trace, dipendenze ed eccezioni.

I log dell’applicazione sono archiviati in AppTraces. Questa query si concentra sulle voci Warning, Error e Critical:

AppTraces
| where TimeGenerated > ago(24h)
| where SeverityLevel >= 2
| project TimeGenerated, SeverityLevel, Message, Properties, OperationId
| order by TimeGenerated desc

Un passo successivo utile consiste nel prendere l’OperationId di un risultato interessante e cercare altra telemetria della stessa operazione. È qui che la correlazione diventa più utile della lettura di messaggi di log isolati.

Costi e volume della telemetria

Application Insights non è semplicemente una funzionalità a costo fisso. Il costo di Azure Monitor dipende soprattutto dalla quantità di telemetria acquisita e dal periodo di conservazione.

Log troppo dettagliati, eccezioni ripetute, traffico elevato e proprietà personalizzate non necessarie possono aumentare questo volume. Il campionamento e il filtraggio possono ridurlo, mentre gli avvisi sui costi e i limiti giornalieri aiutano a individuare un’acquisizione imprevista. Questi controlli richiedono equilibrio: eliminare troppa telemetria può rimuovere anche le informazioni necessarie per indagare su un errore.

Un punto di partenza ragionevole è utilizzare la telemetria automatica del backend, log strutturati con livelli utili e poche query dedicate ai problemi comuni. È possibile aggiungere altra telemetria quando esiste una domanda precisa a cui deve rispondere.