.NET monitoring and APM

Why .NET monitoring matters

.NET powers a wide range of production systems, from ASP.NET Core APIs on Linux containers to long-lived .NET Framework applications on Windows and IIS. Both share a managed runtime with its own garbage collector, thread pool and JIT compiler. .NET monitoring means watching these runtime internals together with request traces, so you can explain why an endpoint is slow or why error rates rise after a release.

Modern .NET has observability built in: System.Diagnostics.Activity is the native span type, and System.Diagnostics.Metrics provides counters and histograms. OpenTelemetry builds on both. The OpenTelemetry .NET automatic instrumentation adds them to your app at startup, so .NET APM works without recompiling.

Runtime signals that matter

• Request latency and errors: http.server.request.duration per route and status code gives the RED view of every ASP.NET Core service.
• Garbage collection: dotnet.gc.collections by generation and dotnet.gc.pause.time. Gen 2 collections are expensive and should be rare.
• Heap size: dotnet.gc.last_collection.heap.size per generation, including the large object heap. Steady growth means objects are kept alive.
• Thread pool: dotnet.thread_pool.queue.length and dotnet.thread_pool.thread.count. A growing queue is the clearest signal of thread pool starvation.
• Exceptions: dotnet.exceptions by type. Even handled exceptions cost CPU and often hint at a failing dependency.

Common .NET performance problems

Thread pool starvation

Blocking calls such as .Result or .Wait() on async code tie up thread pool threads. The pool injects new threads slowly, requests queue up and latency explodes while CPU stays moderate. The fix is usually to make the call path fully asynchronous; the metrics tell you where and when it happens.

Memory leaks and LOH fragmentation

Static caches, event handlers that are never unsubscribed and large buffers on the large object heap keep memory alive. Watch heap size after GC and the working set together, especially in containers with tight memory limits.

Chatty database access

Entity Framework Core can generate many small queries per request. Traces show each SQL span with its duration, so N+1 patterns and missing indexes become visible without a profiler session.

Exceptions as control flow

Code that throws and catches exceptions in hot paths burns CPU. A high dotnet.exceptions rate with an unchanged error rate is the typical sign.

Socket exhaustion from HttpClient misuse

Creating a new HttpClient for every request leaves many sockets in the TIME_WAIT state and can exhaust local ports under load. Outbound client spans that fail with connection errors while the target service is healthy are a strong hint. Using IHttpClientFactory or a shared, long-lived client resolves it.

Slow dependencies hidden behind retries

Resilience libraries retry failed calls transparently. That keeps error rates low but adds latency. Traces show every retry attempt as its own client span, so you can see when a downstream service degrades long before it fails completely.

Best practices for .NET APM

1. Use automatic instrumentation for broad coverage, then add custom ActivitySource spans for important business operations.
2. Set service.name and service.version so you can compare deployments side by side.
3. Enable log correlation: OpenTelemetry adds trace and span IDs to ILogger output, so logs and traces line up.
4. Alert on thread pool queue length and Gen 2 collection rate, not only on CPU and memory.
5. Run on a current .NET version where the runtime emits the standard dotnet.* metrics natively.

How Obseria helps with .NET performance monitoring

Obseria ingests OpenTelemetry traces, metrics and logs from .NET over OTLP, so you keep vendor-neutral instrumentation and can export data at any time. The Obseria Agent adds host, IIS server and container context and can roll out the automatic instrumentation on hosts and Kubernetes. TopoGraph shows how each .NET service connects to SQL Server, caches and message brokers. Continuous profiling with under 1% overhead reveals hot methods and allocations. When something breaks, Obseria Intelligence correlates thread pool starvation, a deployment or a failing dependency and explains the root cause with a chain of evidence. Dashboards, alerts and SLOs are included.