Server memory pool metrics updates

[JamesNK]

Changes:

• Add MemoryPoolOptions so an owner can be specified when creating a memory pool with IMemoryPoolFactory.Create(MemoryPoolOptions). [API Proposal]: PinnedBlockMemoryPool metrics #61594
• Set owner tag on recorded metrics.
• Rename metrics based on feedback at Add ASP.NET Core memory pool metrics open-telemetry/semantic-conventions#2533.
• Add MemoryPoolMetrics to DI and resolve from DI instead of IMeterFactory. This means pools will use a shared instance of MemoryPoolMetrics.
• Change some uint counts in memory pool to ulong to prevent overflow possibility under heavy, sustained usage

[Copilot]

Pull Request Overview

This PR introduces comprehensive improvements to the server memory pool system with enhanced metrics capabilities and configuration options. The key motivation is to provide better observability and tracking of memory pool usage across different components.

• Adds MemoryPoolOptions class to enable specifying an owner for memory pools, improving metrics tagging and diagnostics
• Replaces the old PinnedBlockMemoryPoolMetrics with a new shared MemoryPoolMetrics instance registered in DI, centralizing metric collection
• Updates all metric names based on OpenTelemetry semantic conventions feedback and changes counter types from uint to ulong to prevent overflow

Reviewed Changes

Copilot reviewed 26 out of 26 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
PinnedBlockMemoryPoolMetrics.cs	Removed old metrics class that was specific to pinned block pools
MemoryPoolMetrics.cs	New shared metrics class with owner tagging support and updated metric names
PinnedBlockMemoryPool.cs	Updated to use new metrics system and changed counter types to ulong
IMemoryPoolFactory.cs / MemoryPoolOptions.cs	Added new interface signature and options class for pool configuration
Various transport files	Updated to pass MemoryPoolOptions with appropriate owner identifiers
DI registration files	Added MemoryPoolMetrics to dependency injection containers
Test files	Updated tests to work with new metrics system and verify owner tagging

[BrennanConroy]

I was thinking this should be optional so you don't have to new up options every time you create a pool? Are your thoughts that since you shouldn't be creating a new pool very often it's fine to require the small allocation cost?

[JamesNK]

Sure, it could be optional. That would follow what Channel has:

Do you think there should be two create methods on the interface, or one with the options as optional?

[BrennanConroy]

I think "currently stored by the pool." would be less ambiguous.

[JamesNK]

What do you think of aspnetcore.memory_pool.used vs aspnetcore.memory_pool.pooled?

The used name came from another metric: jvm.memory.used. But if I think about it more, the meaning is different here. jvm.memory.used reports how much memory is used vs this metric which is how much memory is sitting idle in the pool.

For example, name and description could be:

        _usedMemoryCounter = _meter.CreateUpDownCounter<long>(
            "aspnetcore.memory_pool.pooled",
            unit: "By",
            description: "Number of bytes currently held by the pool and available for reuse.");

[BrennanConroy]

Should these be more specific; kestrel_namedpipe?

[JamesNK]

Originally I had them be specific, e.g. "namedpipe", but the memory pool is set on the connection that is created, which is then used throughout Kestrel for other reasons. I think it would be confusing if a memory pool that says it is owned by named pipes transport is then used by HTTPs middleware for example.

[BrennanConroy]

Changes still look good 👍

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).