Problem

The test Microsoft.Extensions.Diagnostics.HealthChecks.Test.LinuxResourceHealthCheckTests.TestCpuAndMemoryChecks_WithMetrics is flaky in CI. It fails with:

Assert.Equal() Failure: Values differ
Expected: Healthy
Actual:   Unhealthy

at line 198 in test/Libraries/Microsoft.Extensions.Diagnostics.HealthChecks.ResourceUtilization.Tests/Linux/LinuxResourceHealthCheckTests.cs.

Root Cause

The test creates a Meter with the hardcoded name "Microsoft.Extensions.Diagnostics.ResourceMonitoring" (line 157). The ResourceUtilizationHealthCheck class creates a MeterListener that subscribes to all instruments from any meter with that name via OnInstrumentPublished:

// In ResourceUtilizationHealthCheck.cs line 184-190
private void OnInstrumentPublished(Instrument instrument, MeterListener listener)
{
    if (instrument.Meter.Name == ResourceUtilizationInstruments.MeterName)
    {
        listener.EnableMeasurementEvents(instrument);
    }
}

Since this is a [ConditionalTheory] with [MemberData], multiple test cases run. When test cases overlap in execution (or other tests in the same process also create meters with the same name), one test's MeterListener picks up instruments from another test's LinuxUtilizationProvider, receiving wrong measurement values. A test case expecting Healthy can receive high CPU/memory values from a concurrently-running test case that expects Unhealthy.

Note that line 155 generates a unique name var meterName = Guid.NewGuid().ToString() but it is never used — the meter on line 157 uses the hardcoded constant instead. However, simply using a unique meter name would break the test because ResourceUtilizationHealthCheck.OnInstrumentPublished would reject instruments whose meter name doesn't match the hardcoded ResourceUtilizationInstruments.MeterName.

Fix

The fix should be a test-only change in test/Libraries/Microsoft.Extensions.Diagnostics.HealthChecks.ResourceUtilization.Tests/Linux/LinuxResourceHealthCheckTests.cs.

Instead of relying on ResourceUtilizationHealthCheck's MeterListener (which matches by meter name globally), the test should use its own local MeterListener that filters by meter reference using ReferenceEquals(instrument.Meter, meter). This is the same isolation pattern already used in this repo by:

• WindowsCountersTests.cs — uses ReferenceEquals(meter, instrument.Meter) in InstrumentPublished
• AcceptanceTest.cs — uses ReferenceEquals(instrument.Meter.Scope, meterScope) in OnInstrumentPublished

The test should:

1. Remove the unused meterName variable.
2. Replace the ResourceUtilizationHealthCheck instance with a local MeterListener scoped via ReferenceEquals to the specific meter instance created in the test.
3. Collect cpuUsedPercentage and memoryUsedPercentage from the local listener's measurement callback (multiplying by 100 since Linux gauges are in [0,1] range), matching what ResourceUtilizationHealthCheck.OnMeasurementRecorded does.
4. Call listener.RecordObservableInstruments() to trigger observation.
5. Call ResourceUtilizationHealthCheck.EvaluateHealthStatusAsync(cpuUsedPercentage, memoryUsedPercentage, options) to evaluate health status. Note: EvaluateHealthStatusAsync is private static — if it cannot be accessed from the test, the test should instead inline the equivalent health evaluation logic, or use the same thresholds comparison that EvaluateHealthStatusAsync performs to construct and verify the expected HealthCheckResult.

The key instruments to listen for are:

• ResourceUtilizationInstruments.ProcessCpuUtilization and ContainerCpuLimitUtilization → _cpuUsedPercentage = measurement * 100
• ResourceUtilizationInstruments.ProcessMemoryUtilization and ContainerMemoryLimitUtilization → _memoryUsedPercentage = measurement * 100

After collecting the measurements, the test should evaluate health status using the same logic as EvaluateHealthStatusAsync in ResourceUtilizationHealthCheck.cs (lines 42-90) which compares the percentages against the CpuThresholds and MemoryThresholds from ResourceUtilizationHealthCheckOptions.

If making EvaluateHealthStatusAsync accessible is too invasive, an alternative simpler approach: keep the ResourceUtilizationHealthCheck but add [Collection("ResourceMonitoring Meter Tests")] to serialize with other tests that create meters with the same name. This is the pattern used in this repo for "Tcp Connection Tests", "StdoutUsage", and "EnvironmentVariableTests" collections. However, this only prevents intra-collection parallelism and may not fully prevent contamination from other test classes.

The preferred approach is the ReferenceEquals-based local listener since it provides complete isolation regardless of parallelism.