.NET Agent Metrics

The CodeXray .NET Agent is primarily a distributed-tracing agent — its main output is traces, not Prometheus metrics. But it does emit runtime telemetry about the CLR, and additional .NET runtime metrics are contributed by the Node Agent. This page lays out what comes from where.

Two sources of .NET telemetry

Depending on your deployment, .NET metrics can come from either:

• The .NET Agent itself — CLR health and application-level telemetry, emitted alongside the traces
• The Node Agent — container-level runtime metrics via the .NET diagnostic port

Together they cover request-level, process-level, and host-level .NET visibility.

---

What the .NET Agent Emits

The .NET Agent attaches to your application (IIS app pool, Windows Service, or standalone executable) and captures:

Traces (primary output)

Every request handled by an instrumented app produces a trace. See Distributed Traces Overview for how traces appear in the UI.

CLR runtime metrics

Emitted alongside traces via the agent's backend channel:

Metric	Type	Description
dotnet_cpu_usage_percent	Gauge	CPU usage of the monitored .NET process
dotnet_memory_usage_bytes	Gauge	Total memory used by the monitored process
dotnet_gc_count_total	Counter	GC events per generation — label generation (0 / 1 / 2)
dotnet_gc_pause_seconds_total	Counter	Cumulative GC pause time
dotnet_heap_size_bytes	Gauge	Heap size per generation — label generation
dotnet_thread_count	Gauge	Current thread count
dotnet_handle_count	Gauge	Current OS handle count

Common labels across runtime metrics:

• application — the logical service name configured in codexray.ini
• app_pool — the IIS application pool (if applicable)
• hostname — the host machine name

Per-application health

Metric	Type	Description
dotnet_exceptions_total	Counter	Exceptions thrown — label exception_type
dotnet_error_rate_percent	Gauge	Computed error rate across recent traces
dotnet_request_rate	Gauge	Request rate
dotnet_request_duration_seconds	Histogram	Request duration percentiles

These are derived from the trace stream as the spans are processed — they appear on the Overview tab of each .NET service in the UI.

---

What the Node Agent Adds

When the Node Agent is running on the same host (Linux or Windows) as your .NET app, it additionally collects runtime metrics from the .NET diagnostic port. These have a container_ prefix and flow through the Node Agent's ingestion path.

Each of these metrics has the application label (distinguishes multiple apps in the same container) and the standard container_id label.

Metric	Type	Description
container_dotnet_info	Gauge	Meta — application, runtime_version
container_dotnet_memory_allocated_bytes_total	Counter	Bytes allocated
container_dotnet_exceptions_total	Counter	Exceptions that have occurred
container_dotnet_memory_heap_size_bytes	Gauge	Heap size — label generation
container_dotnet_gc_count_total	Counter	GC occurrences — label generation
container_dotnet_heap_fragmentation_percent	Gauge	Heap fragmentation
container_dotnet_monitor_lock_contentions_total	Gauge	Monitor lock contentions
container_dotnet_thread_pool_completed_items_total	Counter	ThreadPool work items completed
container_dotnet_thread_pool_queue_length	Gauge	ThreadPool queue length
container_dotnet_thread_pool_size	Gauge	Current thread pool size

The full reference for these lives on the Node Agent Metrics page under ".NET Runtime".

---

OpenTelemetry Auto-Instrumentation Metrics

If you're on a modern runtime and using OpenTelemetry auto-instrumentation (Path B) instead of the CodeXray .NET Agent, your metrics come through OTLP using standard OpenTelemetry .NET metric names:

• http.server.request.duration — HTTP request latency
• http.client.request.duration — Outbound HTTP latency
• process.runtime.dotnet.gc.* — GC event metrics
• process.runtime.dotnet.jit.* — JIT compilation metrics
• process.runtime.dotnet.thread_pool.* — ThreadPool state
• process.runtime.dotnet.exceptions.count — Exception count
• db.client.operations.* — Database client operations

These follow the OpenTelemetry Semantic Conventions for .NET. If your goal is a fully OTel-native metric schema, Path B gets you there.

---

Where These Metrics Appear in the UI

Where	What you see
Applications → service → Overview	Request rate, error rate, latency — derived from the trace stream and CLR runtime signals
Applications → service → Runtime	GC, heap, threadpool, handle, and exception metrics — comes from either the .NET Agent or the Node Agent's .NET diagnostic port
Applications → service → Traces	Full request traces
Applications → service → Deployments	Trace-rate and error-rate deltas across deploys

---

Next Steps

• Authentication & Multi-Tenancy — the next category: sign-in, tenants, and projects
• CodeXray .NET Agent — install and configure the agent
• Node Agent Metrics — the full container/runtime metric reference
• Distributed Traces Overview — what the .NET Agent's trace output looks like in the UI