Introduction : Pourquoi la surveillance des applications C# est un art
Dans le développement moderne en C# (.NET), la surveillance a cessé d'être une simple option. C'est un élément obligatoire de l'environnement de production qui permet non seulement de détecter les pannes, mais aussi de les prédire. À un niveau avancé, la surveillance se transforme en un système d'alerte précoce : vous ne vous contentez pas de regarder des tableaux de bord, vous configurez des alertes basées sur des métriques complexes.
Dans cet article, nous verrons comment aller au-delà des compteurs standard de CPU et de mémoire. Vous apprendrez à collecter des métriques métier personnalisées, à configurer des alertes avec Prometheus et Alertmanager, ainsi qu'à utiliser OpenTelemetry pour le tracing. Tous les exemples seront en C#.
1. Instrumentation avancée : App Metrics et Prometheus
1.1. Connexion de Prometheus à ASP.NET Core
La surveillance de base dans .NET est souvent limitée au PerformanceCounter intégré. Cependant, pour une architecture de microservices, la norme est devenue Prometheus. Installez le package :
dotnet add package prometheus-net.AspNetCoreAjoutez ensuite le middleware dans Program.cs :
using Prometheus;
var builder = WebApplication.CreateBuilder(args);var app = builder.Build();
// Activation du point de terminaison des métriquesapp.UseHttpMetrics();app.UseRouting();app.MapMetrics(); // /metrics
app.Run();Cela vous donnera des métriques de base : nombre de requêtes, durée, erreurs. Mais pour un niveau avancé, cela ne suffit pas.
1.2. Métriques métier personnalisées
Supposons que vous souhaitiez suivre le nombre de commandes créées ou le temps d'exécution d'une opération métier critique. Utilisez Counter et Histogram :
using Prometheus;
public class OrderMetrics{ private static readonly Counter OrdersCreated = Metrics .CreateCounter("orders_created_total", "Total number of created orders");
private static readonly Histogram OrderProcessingTime = Metrics .CreateHistogram("order_processing_seconds", "Histogram of order processing time");
public void RecordOrderCreation(double elapsedSeconds) { OrdersCreated.Inc(); OrderProcessingTime.Observe(elapsedSeconds); }}Désormais, dans n'importe quel service, vous pouvez injecter OrderMetrics et enregistrer des données. Cela vous permettra de construire des tableaux de bord dans Grafana avec une précision à la seconde.
2. Alertes : des déclencheurs simples aux règles orientées SLO
2.1. Configuration d'Alertmanager pour les métriques C#
Collecter des métriques n'est que la moitié du travail. L'autre moitié, ce sont les alertes. Créez une règle pour Prometheus (alerts.yml) :
groups: - name: csharp_app_alerts rules: - alert: HighErrorRate expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05 for: 2m labels: severity: critical annotations: summary: "Taux d'erreur élevé dans l'application C#" description: "Le taux d'erreur est de {{ $value }} pour les 5 dernières minutes"Ceci est un exemple de base. À un niveau avancé, il convient d'ajouter des alertes SLO. Par exemple, si 99% des requêtes ne tiennent pas dans 200 ms, c'est une raison de paniquer.
2.2. Alertes basées sur des métriques métier
Utilisez les compteurs personnalisés de la section précédente. Si le nombre de commandes chute brutalement, cela signifie que quelque chose est cassé :
- alert: OrdersStopped expr: rate(orders_created_total[10m]) == 0 for: 5m labels: severity: warning annotations: summary: "Aucune commande créée dans les 10 dernières minutes"Une telle alerte ne peut pas être obtenue à partir des métriques standard du système d'exploitation — elle nécessite une compréhension approfondie de la logique métier.
3. OpenTelemetry : tracing distribué en C#
3.1. Intégration du SDK OpenTelemetry
Lorsque vous avez 10 microservices en C#, les métriques individuelles ne suffisent pas. Le tracing est nécessaire. Inst