Les avantages d’Azure Application Insights

Lorsqu’une application tombe en panne en production, le premier problème n’est souvent pas de corriger le bug. Il faut d’abord comprendre ce qui s’est passé.

Azure Application Insights facilite cette investigation. Il collecte la télémétrie d’une application et rassemble dans Azure Monitor les requêtes, les dépendances, les exceptions, les journaux et les informations de performance. Au lieu de consulter plusieurs fichiers et de tenter de reconstituer manuellement une panne, il permet de suivre une opération au même endroit, depuis la requête entrante jusqu’aux appels effectués par l’application.

Cette visibilité est utile même pour une petite application .NET. La configuration initiale est simple et les données collectées peuvent répondre à des questions concrètes :

Quels endpoints rencontrent des erreurs ?
Quelles requêtes sont lentes ?
La base de données ou une API externe est-elle à l’origine du ralentissement ?
Quelle exception s’est produite pendant une requête ?
Le problème a-t-il touché une seule opération ou plusieurs utilisateurs ?

Application Insights ne résout pas automatiquement ces problèmes. Son principal avantage est de remplacer une partie des suppositions par des éléments observables.

Ce que collecte l’intégration .NET

Microsoft recommande la distribution OpenTelemetry d’Azure Monitor pour les nouvelles applications ASP.NET Core. OpenTelemetry repose sur trois signaux principaux : les traces, les métriques et les journaux.

Avec la configuration ASP.NET Core standard, Application Insights peut recevoir :

les requêtes HTTP entrantes, avec leur durée et leur statut ;
les appels sortants effectués avec HttpClient ;
les appels de dépendances compatibles vers SQL et les SDK Azure ;
les exceptions non gérées et leurs stack traces ;
les journaux écrits avec ILogger ;
les métriques et les données de corrélation qui relient une opération à sa télémétrie.

La corrélation est l’un des éléments les plus utiles. Une requête en échec peut être reliée à son exception et à l’appel de dépendance qui a échoué pendant la même opération.

Pour les journaux applicatifs, les niveaux les plus pertinents en production sont généralement :

Information pour certains événements de l’application ;
Warning lorsqu’un événement inattendu se produit, mais que l’opération peut continuer ;
Error lorsqu’une opération échoue ;
Critical lorsque l’application ou une fonctionnalité essentielle ne peut plus continuer en toute sécurité.

Debug et Trace sont utiles pendant le développement, mais leur envoi en grande quantité en production peut ajouter du bruit et augmenter le volume de télémétrie.

Les journaux structurés rendent également les données plus faciles à rechercher :

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

Dans cet exemple, OrderId et Provider deviennent des propriétés interrogeables au lieu d’être noyés dans un long message.

ASP.NET Core continue de contrôler les niveaux de journalisation exportés. Une configuration simple pour la production peut conserver les informations de l’application tout en réduisant le bruit habituel du framework :

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

Il ne s’agit que d’un point de départ. Un service peut nécessiter davantage de détails pour un namespace et moins pour un autre. L’objectif est de conserver les événements utiles à une investigation et de supprimer les messages répétés qui ne changent pas le diagnostic.

Ce qui n’est pas collecté automatiquement

L’instrumentation automatique a ses limites. Application Insights ne peut pas signaler une information que l’application n’a jamais produite.

Par exemple :

une exception interceptée puis ignorée sans être journalisée ;
un événement métier qui ne produit ni journal, ni trace, ni télémétrie personnalisée ;
une opération exécutée par une bibliothèque sans instrumentation compatible ;
le corps des requêtes et des réponses ;
une panne qui se produit avant que le trafic n’atteigne l’application ;
les pages vues et les erreurs JavaScript lorsque le SDK du navigateur n’est pas installé.

Il ne faut pas ajouter de données sensibles pour combler ces lacunes. Les mots de passe, jetons d’accès, chaînes de connexion, informations de paiement et données personnelles n’ont pas leur place dans la télémétrie.

Supervision du backend et du navigateur

La supervision du backend s’exécute dans l’application .NET. Elle observe les requêtes du serveur, les exceptions, les journaux de l’application, les appels à la base de données et les opérations HTTP sortantes.

La supervision du navigateur s’exécute sur l’appareil du visiteur grâce au SDK JavaScript d’Application Insights. Elle peut enregistrer les pages vues, les performances côté client, les sessions et les erreurs JavaScript.

Ces deux perspectives répondent à des questions différentes. La télémétrie du backend peut indiquer qu’une API a renvoyé une erreur. Celle du navigateur peut montrer ce que le visiteur a rencontré avant l’envoi de cette requête. Une API peut n’avoir besoin que de la supervision du backend, tandis qu’une application Razor Pages, Angular ou React peut utiliser les deux lorsque le comportement côté client est important.

Configuration de base avec ASP.NET Core

Installez le package Azure Monitor OpenTelemetry dans le projet web :

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

Enregistrez ensuite Azure Monitor dans Program.cs :

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

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

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

Application Insights utilise une chaîne de connexion pour déterminer où envoyer la télémétrie. En production, Microsoft recommande de la fournir par l’intermédiaire de l’environnement :

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

Cette valeur se trouve dans la ressource Application Insights du portail Azure et doit rester en dehors du contrôle de version. Une fois que l’application reçoit du trafic, la télémétrie peut prendre quelques minutes avant d’apparaître.

Une première requête KQL

Le portail Azure propose déjà des vues consacrées aux échecs, aux performances, aux métriques en temps réel et aux dépendances de l’application. Pour des questions plus précises, Log Analytics utilise le Kusto Query Language.

Cette requête répertorie les requêtes en échec au cours des dernières 24 heures :

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

L’OperationId permet de relier une requête aux traces, dépendances et exceptions associées.

Les journaux de l’application sont stockés dans AppTraces. Cette requête se concentre sur les entrées Warning, Error et Critical :

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

L’étape suivante consiste à récupérer l’OperationId d’un résultat intéressant et à rechercher les autres données de télémétrie de la même opération. C’est à ce moment que la corrélation apporte davantage qu’une lecture isolée des messages de journal.

Coût et volume de télémétrie

Application Insights n’est pas une fonctionnalité à coût fixe. La facturation d’Azure Monitor dépend principalement du volume de télémétrie ingéré et de sa durée de conservation.

Des journaux trop détaillés, des exceptions répétées, un trafic important et des propriétés personnalisées inutiles peuvent augmenter ce volume. L’échantillonnage et le filtrage peuvent le réduire, tandis que les alertes de coût et les limites quotidiennes permettent de repérer une ingestion inhabituelle. Un équilibre reste nécessaire : supprimer trop de télémétrie peut également retirer les informations indispensables à l’analyse d’une panne.

Un bon point de départ consiste à utiliser la télémétrie automatique du backend, des journaux structurés aux niveaux appropriés et quelques requêtes dédiées aux problèmes fréquents. D’autres données peuvent être ajoutées lorsqu’elles répondent à une question précise.