.NET-Monitoring und APM

Warum .NET-Monitoring wichtig ist

.NET treibt eine große Bandbreite produktiver Systeme an, von ASP.NET-Core-APIs in Linux-Containern bis zu langlebigen .NET-Framework-Anwendungen unter Windows und IIS. Beide teilen sich eine Managed Runtime mit eigenem Garbage Collector, Thread-Pool und JIT-Compiler. .NET-Monitoring bedeutet, diese Runtime-Interna gemeinsam mit Request-Traces zu beobachten. Nur so lässt sich erklären, warum ein Endpoint langsam ist oder die Fehlerrate nach einem Release steigt.

Modernes .NET bringt Observability bereits mit: System.Diagnostics.Activity ist der native Span-Typ, System.Diagnostics.Metrics liefert Counter und Histogramme. OpenTelemetry baut auf beidem auf. Die automatische Instrumentierung von OpenTelemetry .NET aktiviert sie beim Start Ihrer Anwendung, sodass .NET APM ohne Neukompilierung funktioniert.

Die wichtigsten Runtime-Signale

• Latenz und Fehler: http.server.request.duration je Route und Statuscode liefert die RED-Sicht auf jeden ASP.NET-Core-Service.
• Garbage Collection: dotnet.gc.collections je Generation und dotnet.gc.pause.time. Gen-2-Collections sind teuer und sollten selten sein.
• Heap-Größe: dotnet.gc.last_collection.heap.size je Generation, inklusive Large Object Heap. Stetiges Wachstum bedeutet, dass Objekte am Leben gehalten werden.
• Thread-Pool: dotnet.thread_pool.queue.length und dotnet.thread_pool.thread.count. Eine wachsende Warteschlange ist das deutlichste Zeichen für Thread-Pool-Starvation.
• Exceptions: dotnet.exceptions je Typ. Auch abgefangene Exceptions kosten CPU und deuten oft auf eine ausfallende Abhängigkeit hin.

Typische Performance-Probleme in .NET

Thread-Pool-Starvation

Blockierende Aufrufe wie .Result oder .Wait() auf asynchronem Code binden Threads des Thread-Pools. Der Pool fügt nur langsam neue Threads hinzu, Requests stauen sich, und die Latenz steigt sprunghaft, während die CPU moderat bleibt. Die Lösung ist meist ein durchgängig asynchroner Aufrufpfad; die Metriken zeigen Ihnen, wo und wann das Problem auftritt.

Memory Leaks und LOH-Fragmentierung

Statische Caches, nie abgemeldete Event-Handler und große Puffer auf dem Large Object Heap halten Speicher fest. Beobachten Sie Heap-Größe nach GC und Working Set gemeinsam, besonders in Containern mit knappen Memory-Limits. So erkennen Sie, ob der Managed Heap oder nativer Speicher wächst.

Gesprächiger Datenbankzugriff

Entity Framework Core erzeugt mitunter viele kleine Queries pro Request. Traces zeigen jeden SQL-Span mit Dauer, sodass N+1-Muster und fehlende Indizes ohne separate Profiler-Sitzung sichtbar werden.

Exceptions als Kontrollfluss

Code, der in heißen Pfaden Exceptions wirft und wieder fängt, verbrennt CPU. Eine hohe Rate bei dotnet.exceptions bei unveränderter Fehlerrate ist das typische Muster.

Socket-Erschöpfung durch falsch genutzten HttpClient

Wer für jeden Request einen neuen HttpClient erzeugt, hinterlässt viele Sockets im Zustand TIME_WAIT und kann unter Last die lokalen Ports erschöpfen. Ausgehende Client-Spans, die mit Verbindungsfehlern scheitern, obwohl der Zielservice gesund ist, sind ein deutlicher Hinweis. Die Lösung ist IHttpClientFactory oder ein gemeinsam genutzter, langlebiger Client.

Langsame Abhängigkeiten hinter Retries

Resilience-Bibliotheken wiederholen fehlgeschlagene Aufrufe transparent. Das hält die Fehlerrate niedrig, kostet aber Latenz. Traces zeigen jeden Wiederholungsversuch als eigenen Client-Span. So erkennen Sie, dass ein nachgelagerter Service schwächelt, lange bevor er vollständig ausfällt, und können rechtzeitig gegensteuern.

Container-Limits und Server-GC

Der Server-GC von .NET legt pro CPU-Kern einen eigenen Heap an. In Containern mit wenig Speicher führt das ohne passende Konfiguration schnell zu OOM-Kills. Vergleichen Sie Working Set und Container-Limit, bevor Pods unerwartet neu starten.

Best Practices für .NET APM

1. Nutzen Sie die Autoinstrumentierung für breite Abdeckung und ergänzen Sie eigene ActivitySource-Spans für wichtige Geschäftsvorgänge.
2. Setzen Sie service.name und service.version, um Deployments direkt vergleichen zu können.
3. Aktivieren Sie die Log-Korrelation: OpenTelemetry ergänzt ILogger-Ausgaben um Trace- und Span-IDs.
4. Alarmieren Sie auf Thread-Pool-Queue und Gen-2-Rate, nicht nur auf CPU und Speicher.
5. Setzen Sie eine aktuelle .NET-Version ein, deren Runtime die standardisierten dotnet.*-Metriken nativ ausgibt.

So unterstützt Obseria das .NET Performance Monitoring

Obseria verarbeitet OpenTelemetry-Traces, -Metriken und -Logs aus .NET per OTLP. Ihre Instrumentierung bleibt herstellerneutral, und Daten lassen sich jederzeit exportieren. Der Obseria Agent ergänzt Host-, IIS- und Container-Kontext und kann die Autoinstrumentierung auf Hosts und in Kubernetes ausrollen. TopoGraph zeigt, wie jeder .NET-Service mit SQL Server, Caches und Message Brokern verbunden ist. Continuous Profiling mit unter 1 % Overhead deckt heiße Methoden und Allokationen auf. Im Fehlerfall korreliert Obseria Intelligence Thread-Pool-Starvation, Deployments oder ausfallende Abhängigkeiten und erklärt die Ursache mit einer Beweiskette. Dashboards, Alerts und SLOs sind inklusive.