Überwachung von C#-Anwendungen: Metriken und Alarme auf fortgeschrittenem Niveau

Überwachung von C#-Anwendungen: Metriken und Alarme auf fortgeschrittenem Niveau

In der modernen C#-Entwicklung (.NET) ist eine "einfach funktionierende" Anwendung kein ausreichendes Qualitätskriterium mehr. Produktionssysteme erfordern eine ständige Beobachtung: Man muss wissen, wie viel Speicher der Dienst verbraucht, wie schnell Anfragen verarbeitet werden, ob die Warteschlange im Message Broker wächst. Ohne ein Überwachungs- und Alarmsystem riskieren Sie, erst von den Benutzern von einem Problem zu erfahren. In diesem Artikel werden wir fortgeschrittene Techniken zur Metrikenerfassung, -visualisierung und Alarmkonfiguration für C#-Anwendungen mit modernen Tools wie Prometheus, Grafana und OpenTelemetry behandeln.

Warum ist fortgeschrittenes Monitoring notwendig?

Basis-Monitoring (CPU, RAM, Festplatte) liefert kein vollständiges Bild. Für C#-Anwendungen sind spezifische Metriken kritisch: Anzahl der Garbage Collections (GC), Dauer von Thread-Sperren, Größe des Datenbank-Verbindungspools. Alarme für diese Metriken ermöglichen es, zu reagieren, bevor ein Ausfall eintritt. Ein fortgeschrittener Ansatz umfasst drei Ebenen:

\n
• Infrastructure level — Standard-Servermetriken.
\n
• Application level — Metriken der Geschäftslogik (Latenzen, Fehler, Aufrufhäufigkeit).
\n
• Business level — domänenspezifische Metriken (Anzahl der Bestellungen, Konversion).
\n

Wir konzentrieren uns auf die Application-Ebene, die für C#-Entwickler den größten Nutzen bringt.

Metrikenerfassung mit OpenTelemetry und Prometheus

OpenTelemetry (OTel) ist der De-facto-Standard für die Instrumentierung von .NET-Anwendungen. Es ermöglicht die Erfassung von Metriken, Traces und Logs über eine einheitliche API. Betrachten wir ein Beispiel für die Integration mit Prometheus.

Installieren Sie die NuGet-Pakete:

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

Konfiguration in Program.cs:

using OpenTelemetry.Metrics;\n\nvar builder = WebApplication.CreateBuilder(args);\n\nbuilder.Services.AddOpenTelemetry()\n    .WithMetrics(metrics => metrics\n        .AddAspNetCoreInstrumentation()\n        .AddRuntimeInstrumentation()\n        .AddPrometheusExporter());\n\nvar app = builder.Build();\n\napp.MapPrometheusScrapingEndpoint(); // Endpoint für Prometheus\n\napp.Run();

Unter der Adresse /metrics stellt Ihr Dienst nun Metriken im Prometheus-Format bereit. Darunter sind die Anzahl der HTTP-Anfragen, deren Bearbeitungszeit, GC- und Speichermetriken.

Benutzerdefinierte Metriken

Für Geschäftsmetriken verwenden Sie Meter und Counter:

using System.Diagnostics.Metrics;\n\npublic class OrderMetrics\n{\n    private readonly Counter<int> _ordersCreated;\n\n    public OrderMetrics(IMeterFactory meterFactory)\n    {\n        var meter = meterFactory.Create("MyApp.Orders");\n        _ordersCreated = meter.CreateCounter<int>("orders.created.count");\n    }\n\n    public void OrderCreated() => _ordersCreated.Add(1);\n}\n\n// Registrierung in DI:\nbuilder.Services.AddSingleton<OrderMetrics>();

Diese Metriken werden automatisch an Prometheus übermittelt und stehen für die Erstellung von Dashboards in Grafana zur Verfügung.

Alarmkonfiguration: Von einfachen Regeln zu einem mehrstufigen System

Metriken allein sind ohne Alarme nutzlos. In Prometheus werden Alarme über den Alertmanager konfiguriert. Betrachten wir ein fortgeschrittenes Szenario: einen Alarm für eine anomale API-Antwortzeit.

Regel in Prometheus (alert.rules.yml)

groups:\n  - name: csharp_app_alerts\n    rules:\n      - alert: HighRequestLatency\n        expr: |\n          histogram_quantile(0.95, \n            rate(http_server_duration_seconds_bucket[5m])\n          ) > 2\n        for: 2m\n        labels:\n          severity: critical\n        annotations:\n          summary: "Hohe Anforderungslatenz ({{ $value }}s)"\n          descr