How to Instrument .NET Apps with OpenTelemetry

What to observe in a .NET service

For a .NET service you watch per-endpoint latency and error rate, database and downstream call latency, and the CLR runtime: garbage collection, the thread pool, and exceptions. The .NET-specific failure that trips teams up is thread-pool starvation, usually from blocking on async code (sync-over-async), which makes a service slow and unresponsive while CPU and memory look fine.

The correlation that pinpoints most .NET incidents is endpoint latency against thread-pool queue length and GC: latency that rises with a growing thread-pool queue is starvation, and latency that lines up with gen-2 collections is heap pressure.

How OpenTelemetry collects it

.NET has first-class OpenTelemetry support. The SDK integrates with the built-in Activity tracing and the .NET metrics APIs, and instrumentation packages cover ASP.NET Core, HttpClient and common data access, so you add them and configure an OTLP exporter with AddOpenTelemetry(). For zero-code, the OpenTelemetry .NET automatic instrumentation agent injects the same instrumentation without editing the app.

The runtime metrics, GC collections and heap size, thread-pool thread and queue counts, and exception counts, come from the runtime instrumentation and are the .NET-specific half of the picture. The detail to watch is not double-emitting metrics if you run both the agent and manual SDK registration; pick one source per signal.

Key metrics to watch

The signals that explain most .NET service incidents:

What to put on a dashboard

A .NET dashboard should separate thread-pool starvation from GC pressure from a slow dependency. Row one: endpoint p95/p99 and 5xx by route. Row two: thread-pool queue length and available threads, and GC heap size by generation with collection frequency. Row three: database latency and exception rate.

# p99 latency by endpoint
histogram_quantile(0.99, http.server.request.duration) by (http.route)

# thread-pool starvation: queue length climbing
process.runtime.dotnet.thread_pool.queue.length

# gen-2 heap after GC: a rising floor = leak
process.runtime.dotnet.gc.heap.size{generation="gen2"}

Reading the signals: common failure modes

Thread-pool starvation

The service becomes slow and unresponsive while CPU and memory look healthy, because blocking calls on async paths have exhausted the thread pool and new work queues. Thread-pool queue length climbing while available threads drop is the signature. Fix the sync-over-async call rather than raising the thread-pool limit.

GC pressure

Latency spikes line up with gen-2 collections because the service allocates heavily. Collection frequency and pause behaviour confirm it. Reduce large or frequent allocations on the hot path (pooling, spans, avoiding LOH allocations).

Gen-2 heap leak

Gen-2 heap size grows over hours and never returns to baseline after collection, ending in high memory and eventual failure. Static caches and undisposed resources are the usual causes; the heap-size trend is the tell.

Example alert conditions

Starting thresholds to tune:

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps ingests .NET OpenTelemetry data natively, and Sentinel AI resolves the incidents it reveals through governed Action Tickets. Explore TelemetryOps.