Split ASP.NET Core built-in metrics reference into topic-focused pages

[Copilot]

The built-in metrics reference (log-mon/metrics/built-in) had grown too large and will grow further as .NET 10 authentication, authorization, and Identity metrics are added. This restructures it into focused pages by audience/topic while keeping the original page as a stable landing/index so existing inbound links to uid: log-mon/metrics/built-in don't break.

New reference pages (aspnetcore/log-mon/metrics/)

• built-in-http.md — Hosting, Routing, RateLimiting, HeaderParsing, Server.Kestrel, Http.Connections (SignalR)
• built-in-diagnostics.md — Diagnostics
• built-in-components.md — Blazor Components, Components.Lifecycle, Components.Server.Circuits (whole page gated >= aspnetcore-10.0 via front-matter monikerRange)
• built-in-security.md — Authorization, Authentication (whole page gated >= aspnetcore-10.0)

Metric content, tables, Usage: notes, HTML comments, and moniker blocks (including the inner = aspnetcore-9.0 block in Kestrel connection.duration) are moved verbatim. Each page carries a consistent "See also" footer.

Index page (built-in.md)

Converted from a monolithic reference into a landing page: reference table (Page | Namespaces | Example metrics), a "How to read this reference" legend, and a version-availability note for the 10.0-only pages.

Placement rule (documented on the index)

The split is by topic, but the current page is organized by namespace. Namespaces that don't map cleanly — SignalR (Http.Connections), HeaderParsing, RateLimiting — are grouped under HTTP since they all relate to serving HTTP/real-time connections. Rule is stated on the index so it's easy to extend.

Cross-references & TOC

• toc.yml — new pages nested under the Built-in metrics node.
• Repointed the two links that targeted moved anchors: Kestrel anchor in kestrel/security-considerations.md, Authorization anchor in release-notes/aspnetcore-10.0.md. Links to the index (no moved anchor) are unchanged.

Nits fixed in-place

Typo "metic" → "metric" (Kestrel TLS handshake) and stray leading | in the rate-limiting active_request_leases row.

Docs-only; no sample code changes. All :::moniker blocks balance and the four new uids are unique and referenced from both the index and TOC.

Open question for reviewers

Page boundaries and file/uid names — confirm the HTTP grouping of SignalR/HeaderParsing/RateLimiting and whether a dedicated SignalR page is preferable as metrics grow.

• Fixes Consider splitting up ASP.NET Core metrics page #35726

---

Internal previews

File	Preview link
aspnetcore/fundamentals/servers/kestrel/security-considerations.md	aspnetcore/fundamentals/servers/kestrel/security-considerations
aspnetcore/log-mon/metrics/built-in-components.md	aspnetcore/log-mon/metrics/built-in-components
aspnetcore/log-mon/metrics/built-in-diagnostics.md	aspnetcore/log-mon/metrics/built-in-diagnostics
aspnetcore/log-mon/metrics/built-in-http.md	aspnetcore/log-mon/metrics/built-in-http
aspnetcore/log-mon/metrics/built-in-security.md	aspnetcore/log-mon/metrics/built-in-security
aspnetcore/log-mon/metrics/built-in.md	aspnetcore/log-mon/metrics/built-in
aspnetcore/release-notes/aspnetcore-10.0.md	aspnetcore/release-notes/aspnetcore-10.0
aspnetcore/toc.yml	aspnetcore/toc

[Copilot]

Pull request overview

This PR restructures the ASP.NET Core built-in metrics reference by splitting the previously large log-mon/metrics/built-in page into multiple topic-focused reference pages, while keeping built-in.md as a stable landing/index page to preserve inbound links.

Changes:

• Added four new topic pages for HTTP, diagnostics, Blazor components, and security-related metrics (authn/authz) and updated the original built-in.md into an index/landing page.
• Updated the ASP.NET Core TOC to nest the new pages under the existing Built-in metrics node.
• Repointed existing documentation links to the new page anchors where content moved.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
aspnetcore/toc.yml	Nests new built-in metrics topic pages under the existing Built-in metrics TOC node.
aspnetcore/release-notes/aspnetcore-10.0.md	Updates the authorization metrics reference link to point to the new security page anchor.
aspnetcore/log-mon/metrics/built-in.md	Converts the original monolithic reference into a landing/index page for the split content.
aspnetcore/log-mon/metrics/built-in-http.md	Adds the HTTP-focused metrics reference content (hosting/routing/rate limiting/header parsing/Kestrel/SignalR).
aspnetcore/log-mon/metrics/built-in-diagnostics.md	Adds the diagnostics-focused metrics reference content.
aspnetcore/log-mon/metrics/built-in-components.md	Adds the Blazor components-focused metrics reference content (>= ASP.NET Core 10).
aspnetcore/log-mon/metrics/built-in-security.md	Adds the authn/authz-focused metrics reference content (>= ASP.NET Core 10).
aspnetcore/fundamentals/servers/kestrel/security-considerations.md	Repoints the Kestrel metrics reference link to the new HTTP metrics page anchor.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (3)

aspnetcore/log-mon/metrics/built-in-http.md:61

• The attribute description includes a footnote marker ([1]), but this page doesn't define the footnote anywhere, leaving a dangling reference in the rendered table.

`http.request.method` | string | HTTP request method. [1] | `GET`; `POST`; `HEAD` | Always

aspnetcore/log-mon/metrics/built-in.md:35

• This placement rule mentions Identity metrics, but the table and linked pages currently cover only authentication and authorization. This can mislead readers into expecting Identity content on the security page.

* Authentication, authorization, and Identity metrics are grouped together as security-related metrics.

aspnetcore/log-mon/metrics/built-in.md:48

• This sentence repeats the same guidance already stated earlier on the page (line 15), which makes the landing page more repetitive than necessary.

For guidance on how to collect, report, enrich, and test with these metrics, see <xref:log-mon/metrics/metrics>.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (2)

aspnetcore/log-mon/metrics/built-in-http.md:79

• The example value for the boolean aspnetcore.routing.is_fallback_route attribute is True, but other boolean examples in this reference use lowercase (true/false). Use true here for consistency and to match typical .NET boolean literal casing.

`aspnetcore.routing.is_fallback_route` | boolean | A value that indicates whether the matched route is a fallback route. | `True` | If a route was successfully matched.

aspnetcore/log-mon/metrics/built-in-security.md:35

• The Presence column values in this table are inconsistently capitalized ("Conditionally required" vs "Conditionally Required") and are wrapped in code formatting, unlike the other metrics tables in this PR. Standardize the casing and use plain text for these Presence values for consistency.

`user.is_authenticated` | boolean | Whether the request came from an authenticated user. | `true` | `Required`
`aspnetcore.authorization.policy` | string | The name of the authorization policy. | `AtLeast21`; `EmployeeOnly` | `Conditionally required` if an authorization policy is used.
`aspnetcore.authorization.result` | string | Whether the authorization succeeded or failed. | `success`; `failure` | `Conditionally Required` if an exception is not thrown during authorization.
`error.type` | string | The full name of the exception type. | `System.InvalidOperationException`; `Contoso.MyException` | `Conditionally Required` if the request has ended with an error.

[wadepickett]

@copilot, fix the two latest issues you discovered in your reivew that have not been addressed yet.

[Copilot]

@copilot, fix the two latest issues you discovered in your reivew that have not been addressed yet.

Addressed in 20cf2f9: normalized the fallback-route Boolean example and conditional-presence terminology.

[wadepickett]

TOC isn't working correctly.

[wadepickett]

Closing and reopening to get a fresh build. The TOC has some erratic behaviour.

[wadepickett]

Fixed TOC by closing re-opening and forcing a new build.