v11 update for OpenTelemetry: ASP.NET Core built-in metrics

[wadepickett]

Description

See #37267, the parent tracking issue for details.

Update this article to reflect the ASP.NET Core for .NET 11 changes related to OpenTelemetry, introduced in Preview 2.
These updates need to be an a .NET 11 >= moniker version.

Suggested updates:

The following are suggested updates to this article to consider:

Proposed updates to aspnetcore/log-mon/metrics/built-in.md

Issue: dotnet/AspNetCore.Docs#37267 — Updates for OpenTelemetry documentation for ASP.NET Core 11
Related upstream issue: open-telemetry/opentelemetry-dotnet#7426 — Custom activities silently dropped when not calling AddAspNetCoreInstrumentation
File under review: aspnetcore/log-mon/metrics/built-in.md
Report date: 2026-06-19

Note: The following are suggestions for review and discussion — not final edits. Please treat each change as a starting point and adjust wording, scoping, and placement to fit the repo's editorial style before applying. The ms.date bump that would normally accompany a content change is omitted here for brevity.

---

Framing

built-in.md is the reference catalog of every ASP.NET Core meter and instrument, and several of these — especially everything under Microsoft.AspNetCore.Hosting (http.server.request.duration, http.server.active_requests) and Microsoft.AspNetCore.Server.Kestrel — are precisely the meters that fulfill the OpenTelemetry HTTP server semantic conventions in ASP.NET Core 11. Because this is the article that the companion file (metrics.md) points readers to ("For details on what's emitted, see ASP.NET Core metrics"), it should also explicitly call out the ASP.NET Core 11 conformance story and direct readers to the tracing-side guidance in metrics.md. The edits below are intentionally light — they layer onto the reference without restructuring it.

---

Change 1 — Add an ASP.NET Core 11 conformance callout to the article intro

Before (lines 10–15)

# ASP.NET Core built-in metrics

This article describes the built-in metrics for ASP.NET Core produced using the
<xref:System.Diagnostics.Metrics?displayProperty=nameWithType> API. For a listing of metrics based on the older [EventCounters](/dotnet/core/diagnostics/event-counters) API, see [Available counter[...]

For information on how to collect, report, enrich, and test with ASP.NET Core metrics, see <xref:log-mon/metrics/metrics>.

After Update

# ASP.NET Core built-in metrics

This article describes the built-in metrics for ASP.NET Core produced using the
<xref:System.Diagnostics.Metrics?displayProperty=nameWithType> API. For a listing of metrics based on the older [EventCounters](/dotnet/core/diagnostics/event-counters) API, see [Available counter[...]

For information on how to collect, report, enrich, and test with ASP.NET Core metrics, see <xref:log-mon/metrics/metrics>.

:::moniker range=">= aspnetcore-11.0"

> [!NOTE]
> Starting in ASP.NET Core 11, the built-in HTTP server meters listed in this article (most notably `Microsoft.AspNetCore.Hosting` and `Microsoft.AspNetCore.Server.Kestrel`) emit data that's fully compliant with the required parts of the [OpenTelemetry HTTP server semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/). As a result, the [`OpenTelemetry.Instrumentation.AspNetCore`](https://www.nuget.org/packages/OpenTelemetry.Instrumentation.AspNetCore) NuGet package is **optional** for collecting HTTP server metrics — register these meters directly with the OpenTelemetry SDK. For an end-to-end example and tracing-specific guidance (including a common pitfall when the instrumentation package isn't used), see <xref:log-mon/metrics/metrics>.

:::moniker-end

Why: This is the single most discoverable spot to land the ASP.NET Core 11 message in a reference article. Readers who arrive here from a cross-link, a search engine, or the "see [ASP.NET Core metrics]" pointer in metrics.md immediately learn three things: (1) the meters cataloged below are OTel-conventions-compliant in .NET 11, (2) the instrumentation package is optional, and (3) where to go for setup and the tracing gotcha. Wrapping in :::moniker range=">= aspnetcore-11.0"::: keeps the scoping consistent with the other moniker-gated blocks already in this file (>= aspnetcore-10.0, = aspnetcore-9.0).

---

Change 2 — Add a focused callout under Microsoft.AspNetCore.Hosting

Before (lines 134–140)

## `Microsoft.AspNetCore.Hosting`

The `Microsoft.AspNetCore.Hosting` metrics report high-level information about HTTP requests received by ASP.NET Core:

* [`http.server.request.duration`](#metric-httpserverrequestduration)
* [`http.server.active_requests`](#metric-httpserveractive_requests)

### Metric: `http.server.request.duration`

After Update

## `Microsoft.AspNetCore.Hosting`

The `Microsoft.AspNetCore.Hosting` metrics report high-level information about HTTP requests received by ASP.NET Core:

* [`http.server.request.duration`](#metric-httpserverrequestduration)
* [`http.server.active_requests`](#metric-httpserveractive_requests)

:::moniker range=">= aspnetcore-11.0"

> [!NOTE]
> In ASP.NET Core 11 and later, the instruments under `Microsoft.AspNetCore.Hosting` are the framework's primary implementation of the [OpenTelemetry HTTP server semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/). Register this meter directly with the OpenTelemetry SDK — for example, `builder.AddMeter("Microsoft.AspNetCore.Hosting")` — without adding the [`OpenTelemetry.Instrumentation.AspNetCore`](https://www.nuget.org/packages/OpenTelemetry.Instrumentation.AspNetCore) package.

:::moniker-end

### Metric: `http.server.request.duration`

Why: Microsoft.AspNetCore.Hosting is the meter that owns http.server.request.duration and http.server.active_requests — the exact instruments named in the OpenTelemetry HTTP server semantic conventions. Calling that out at this section heading (rather than only in the intro) gives readers who deep-link to this section the same "you can skip the instrumentation package" guidance, and it pre-empts the common confusion behind issue #37267: customers seeing the meter name in their telemetry pipeline and not knowing whether they still need the contrib instrumentation package.

---

Change 3 — Add the same scoping clarity under Microsoft.AspNetCore.Server.Kestrel

Before (lines 310–322)

## `Microsoft.AspNetCore.Server.Kestrel`

The `Microsoft.AspNetCore.Server.Kestrel` metrics report HTTP connection information from [ASP.NET Core Kestrel web server](/aspnet/core/fundamentals/servers/kestrel):

* [`kestrel.active_connections`](#metric-kestrelactive_connections)
* [`kestrel.connection.duration`](#metric-kestrelconnectionduration)
* [`kestrel.rejected_connections`](#metric-kestrelrejected_connections)
* [`kestrel.queued_connections`](#metric-kestrelqueued_connections)
* [`kestrel.queued_requests`](#metric-kestrelqueued_requests)
* [`kestrel.upgraded_connections`](#metric-kestrelupgraded_connections)
* [`kestrel.tls_handshake.duration`](#metric-kestreltls_handshakeduration)
* [`kestrel.active_tls_handshakes`](#metric-kestrelactive_tls_handshakes)

### Metric: `kestrel.active_connections`

After Update

## `Microsoft.AspNetCore.Server.Kestrel`

The `Microsoft.AspNetCore.Server.Kestrel` metrics report HTTP connection information from [ASP.NET Core Kestrel web server](/aspnet/core/fundamentals/servers/kestrel):

* [`kestrel.active_connections`](#metric-kestrelactive_connections)
* [`kestrel.connection.duration`](#metric-kestrelconnectionduration)
* [`kestrel.rejected_connections`](#metric-kestrelrejected_connections)
* [`kestrel.queued_connections`](#metric-kestrelqueued_connections)
* [`kestrel.queued_requests`](#metric-kestrelqueued_requests)
* [`kestrel.upgraded_connections`](#metric-kestrelupgraded_connections)
* [`kestrel.tls_handshake.duration`](#metric-kestreltls_handshakeduration)
* [`kestrel.active_tls_handshakes`](#metric-kestrelactive_tls_handshakes)

:::moniker range=">= aspnetcore-11.0"

> [!NOTE]
> In ASP.NET Core 11 and later, the Kestrel meter conforms to the [OpenTelemetry semantic conventions for Kestrel web server metrics](https://opentelemetry.io/docs/specs/semconv/dotnet/dotnet-kestrel-metrics/). Register it directly with the OpenTelemetry SDK — for example, `builder.AddMeter("Microsoft.AspNetCore.Server.Kestrel")` — without adding the [`OpenTelemetry.Instrumentation.AspNetCore`](https://www.nuget.org/packages/OpenTelemetry.Instrumentation.AspNetCore) package.

:::moniker-end

### Metric: `kestrel.active_connections`

Why: The sample code in metrics.md already adds both Microsoft.AspNetCore.Hosting and Microsoft.AspNetCore.Server.Kestrel directly to OpenTelemetry. To keep the reference article in lockstep with that sample — and to give Kestrel users the same scoping confidence as the hosting users get in Change 2 — the same callout pattern should appear here. The Kestrel instruments link out to the OpenTelemetry Kestrel-specific conventions page (which is the spec they map to), rather than the broader HTTP server conventions page used in Changes 1 and 2.

---

Summary of why these three edits together resolve the issue

Edit	Issue concern it addresses
1. Article-intro ASP.NET Core 11 callout	Gives every reader of this reference the headline message: the cataloged meters are OTel-conventions-compliant in .NET 11 and the instrumentation package is optional. Also routes them to metrics.md for setup and the tracing pitfall.
2. Microsoft.AspNetCore.Hosting callout	Targets the meter that owns the HTTP server semantic-convention instruments (http.server.request.duration, http.server.active_requests) so deep-linkers see the same guidance in context.
3. Microsoft.AspNetCore.Server.Kestrel callout	Mirrors the sample in metrics.md, confirming that the Kestrel meter is also intended to be registered directly with the OpenTelemetry SDK in ASP.NET Core 11.

No PR was opened and the source issue wasn't modified, as requested.

Page URL

https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/built-in?view=aspnetcore-10.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/log-mon/metrics/built-in.md

Document ID

eb916896-e92c-9a7f-b74d-813a11be339c

Platform Id

60bee8c0-95f0-1122-0c75-99dde6fedc20

Article author

@guardrex

Metadata

• ID: eb916896-e92c-9a7f-b74d-813a11be339c
• PlatformId: 60bee8c0-95f0-1122-0c75-99dde6fedc20
• Service: aspnet-core

Related Issues

---

Associated WorkItem - 626786