Surveillance des applications C# : métriques et alertes de A à Z

Introduction : Pourquoi la surveillance est cruciale pour les applications C#

Dans le développement logiciel moderne, écrire du code n'est que la moitié du travail. Pour qu'une application fonctionne de manière stable, rapide et prévisible, une surveillance constante est nécessaire. Pour les applications C# (.NET), souvent utilisées dans les systèmes d'entreprise à forte charge, le secteur bancaire, le e-commerce et les services cloud, la surveillance devient non pas une option, mais une exigence obligatoire.

Sans surveillance, vous travaillez à l'aveugle : les fuites mémoire passent inaperçues jusqu'à la panne du serveur, les requêtes lentes s'accumulent et les utilisateurs se tournent vers les concurrents. Dans cet article, nous allons détailler le cycle complet de configuration de l'observabilité pour les applications C# : de la collecte des métriques de base à la configuration d'alertes intelligentes en temps réel.

1. Bases de la surveillance : quelles métriques collecter dans .NET

Avant de configurer les outils, il est important de comprendre quelles métriques sont réellement importantes pour les applications C#. Nous les diviserons en trois groupes :

1.1. Métriques système (niveau infrastructure)

\n
• CPU et Mémoire — charge du processeur et consommation de mémoire vive par le processus dotnet.
\n
• GC (Garbage Collection) — fréquence et durée des collectes de déchets, taille des tas (Gen0, Gen1, Gen2, LOH).
\n
• Thread Pool — nombre de threads actifs, libres et en attente.
\n
• E/S disque et Réseau — lecture/écriture sur le disque, connexions réseau.
\n

1.2. Métriques métier (niveau application)

\n
• Taux de requêtes — nombre de requêtes par seconde (RPS).
\n
• Latence — temps de réponse (percentiles p50, p95, p99).
\n
• Taux d'erreur — pourcentage d'erreurs 4xx et 5xx.
\n
• Utilisateurs actifs — nombre d'utilisateurs simultanés.
\n

1.3. Métriques du Runtime .NET

\n
• Compilation JIT — temps de compilation des méthodes.
\n
• Chargement d'assemblages — nombre d'assemblages chargés.
\n
• Exceptions — nombre d'exceptions levées par seconde.
\n

Pour collecter ces métriques dans .NET, on utilise un outil puissant : System.Diagnostics.Metrics (API intégrée depuis .NET 6+) et la bibliothèque OpenTelemetry.

2. Configuration de la collecte de métriques avec OpenTelemetry et Prometheus

La meilleure façon d'organiser la surveillance d'une application C# est d'utiliser la combinaison OpenTelemetry (collecte de métriques) + Prometheus (stockage) + Grafana (visualisation). Voyons la configuration étape par étape.

2.1. Installation des packages NuGet

Ajoutez les packages suivants à votre projet :

dotnet add package OpenTelemetry.Extensions.Hosting\ndotnet add package OpenTelemetry.Exporter.Prometheus.AspNetCore\ndotnet add package OpenTelemetry.Instrumentation.AspNetCore\ndotnet add package OpenTelemetry.Instrumentation.Runtime

2.2. Configuration dans Program.cs

Configurez OpenTelemetry pour la collecte automatique des métriques ASP.NET Core et .NET Runtime :

using OpenTelemetry.Metrics;\n\nvar builder = WebApplication.CreateBuilder(args);\n\nbuilder.Services.AddOpenTelemetry()\n    .WithMetrics(metrics => metrics\n        .AddAspNetCoreInstrumentation() // métriques des requêtes HTTP\n        .AddRuntimeInstrumentation()    // métriques GC, JIT, ThreadPool\n        .AddPrometheusExporter());      // export vers Prometheus\n\nvar app = builder.Build();\n\napp.UseOpenTelemetryPrometheusScrapingEndpoint(); // endpoint /metrics\n\napp.Run();

Désormais, à l'adresse http://localhost:5000/metrics, un endpoint avec les métriques au format Prometheus sera disponible.

2.3. Création de métriques personnalisées

Ajoutons une métrique métier — un compteur de commandes traitées :

public class OrderMetrics\