Implement disk io metrics for linux

[makazeu]

Closes #6371

Implement the following Disk I/O metrics for Linux:

• system.disk.io
• system.disk.operations
• system.disk.io_time

All these values come from Linux Kernel's procfs-diskstats

Tested with Grafana + Prometheus with WSL2 + Ubuntu 24.04

cc @evgenyfedorov2

Microsoft Reviewers: Open in CodeFlow

[amadeuszl]

Can we add those metrics into documentation once merged https://github.com/dotnet/docs/blob/0d95e86e545ce4cfad2da2fe1e7fcee9da2edc8c/docs/core/diagnostics/built-in-metrics-diagnostics.md ?

[amadeuszl]

Since EnableDiskIoMetrics is experimental we can change the name of the flag to EnableSystemDiskIoMetrics, so in future we can add EnableContainerDiskIoMetrics or something like that, to make both more descriptive of what they add.

EnableDiskIoMetrics did this flag already went through any API review?

[makazeu]

Can we add those metrics into documentation once merged https://github.com/dotnet/docs/blob/0d95e86e545ce4cfad2da2fe1e7fcee9da2edc8c/docs/core/diagnostics/built-in-metrics-diagnostics.md ?

We already support these metrics on Windows: #6181 , #6338. I'll add these to the document as soon as possible

[makazeu]

Since EnableDiskIoMetrics is experimental we can change the name of the flag to EnableSystemDiskIoMetrics, so in future we can add EnableContainerDiskIoMetrics or something like that, to make both more descriptive of what they add.

EnableDiskIoMetrics did this flag already went through any API review?

No, EnableDiskIoMetrics has NOT gone through API review, we can change it as it's experimental.

As I commented in this, on Windows, the system.disk.* metrics have already been reflecting the values inside a "container" or VM, if we enable EnableContainerDiskIoMetrics along with EnableSystemDiskIoMetrics on Windows, what should we expect? Or I guess we should flag EnableContainerDiskIoMetrics as Linux-only?

[amadeuszl]

Since EnableDiskIoMetrics is experimental we can change the name of the flag to EnableSystemDiskIoMetrics, so in future we can add EnableContainerDiskIoMetrics or something like that, to make both more descriptive of what they add.
EnableDiskIoMetrics did this flag already went through any API review?

No, EnableDiskIoMetrics has NOT gone through API review, we can change it as it's experimental.

As I commented in this, on Windows, the system.disk.* metrics have already been reflecting the values inside a "container" or VM, if we enable EnableContainerDiskIoMetrics along with EnableSystemDiskIoMetrics on Windows, what should we expect? Or I guess we should flag EnableContainerDiskIoMetrics as Linux-only?

EnableSystemDiskIoMetrics - should enable system.disk* metrics - VM and container are not the same, so reporting VM from system.* metric makes sense to me
EnableContainerDiskIoMetrics - should enable container.disk.* metrics, for Windows we may check if there're other counters reflecting it instead on VMs, I'm not fully into Windows implementation yet

[makazeu]

Since EnableDiskIoMetrics is experimental we can change the name of the flag to EnableSystemDiskIoMetrics, so in future we can add EnableContainerDiskIoMetrics or something like that, to make both more descriptive of what they add.
EnableDiskIoMetrics did this flag already went through any API review?

No, EnableDiskIoMetrics has NOT gone through API review, we can change it as it's experimental.
As I commented in this, on Windows, the system.disk.* metrics have already been reflecting the values inside a "container" or VM, if we enable EnableContainerDiskIoMetrics along with EnableSystemDiskIoMetrics on Windows, what should we expect? Or I guess we should flag EnableContainerDiskIoMetrics as Linux-only?

EnableSystemDiskIoMetrics - should enable system.disk* metrics - VM and container are not the same, so reporting VM from system.* metric makes sense to me EnableContainerDiskIoMetrics - should enable container.disk.* metrics, for Windows we may check if there're other counters reflecting it instead on VMs, I'm not fully into Windows implementation yet

Makes sense, I have updated renamed the EnableDiskIoMetrics to EnableSystemDiskIoMetrics and I'd like to complete this PR. I will try to implement the container metrics in the future.

[makazeu]

When I was trying to rename EnableDiskIoMetrics to EnableSystemDiskIoMetrics, I got this error in CI pipeline:

.dotnet/sdk/9.0.106/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.ApiCompat.ValidatePackage.targets(39,5): error CP0002: (NETCORE_ENGINEERING_TELEMETRY=Build) Member 'bool Microsoft.Extensions.Diagnostics.ResourceMonitoring.ResourceMonitoringOptions.EnableDiskIoMetrics.get' exists on [Baseline] lib/net462/Microsoft.Extensions.Diagnostics.ResourceMonitoring.dll but not on lib/net462/Microsoft.Extensions.Diagnostics.ResourceMonitoring.dll

Looks like I can not simply rename an existing public API. @amadeuszl What is the correct procedure for making changes to a public API?

[amadeuszl]

I've got recommendation to suppress it since it's experimental. How to suppress exact variable: https://learn.microsoft.com/en-us/dotnet/fundamentals/apicompat/package-validation/baseline-version-validator.

Can we also add a note to the variable

/// <remarks>Previously <c>EnableDiskIoMetrics</c>.</remarks>

[makazeu]

I've got recommendation to suppress it since it's experimental. How to suppress exact variable: https://learn.microsoft.com/en-us/dotnet/fundamentals/apicompat/package-validation/baseline-version-validator.

Can we also add a note to the variable

/// <remarks>Previously <c>EnableDiskIoMetrics</c>.</remarks>

Please help review again, thanks!