Make ResourceUtilizationInstruments class public

[evgenyfedorov2]

The Microsoft.Extensions.Diagnostics.ResourceMonitoring.ResourceUtilizationInstruments class contains only constants which represent metric names. Those metric names are used internally in the library, but they also might be used by customers in their code, and since metric names are internal, currently customers are forced to use hard-coded strings. Therefore, I propose to make the ResourceUtilizationInstruments class public, which will expose all its members (they are already public const).

Proposed API

-internal static class ResourceUtilizationInstruments
+public static class ResourceUtilizationInstruments
{
    public const string CpuUtilization = "process.cpu.utilization";
    public const string MemoryUtilization = "dotnet.process.memory.virtual.utilization";
}

Usage Examples

    InstrumentPublished = (instrument, meter) =>
    {
        if (instrument.Name == ResourceUtilizationInstruments.CpuUtilization)
        {
            meter.EnableMeasurementEvents(instrument, state: this);
        }
    }

[RussKie]

This proposal makes sense to me as otherwise consumers migrating from Microsoft.R9.Extensions.Diagnostics.ResourceUtilization to Microsoft.Extensions.Diagnostics.ResourceMonitoring will have to change their code and reference metric names explicitly (essentially hard-code those in their code). E.g., in a sample I had to do the following:

It'd be great if we could keep the original instrument names, however the underlying metric names have changed, so it doesn't make much sense.

Making this type public will also enable us to obsolete instruments, if that becomes necessary for one reason or another. That is, will be able to do something like this:

public static class ResourceUtilizationInstruments
{
+   [Obsolete("Use XYZ instrument instead", UrlFormat = "aka.ms/docs/...")]
    public const string CpuUtilization = "process.cpu.utilization";

    public const string MemoryUtilization = "dotnet.process.memory.virtual.utilization";
}

@joperezr @geeknoid @mwierzchowski: I'm inclinde to approve this proposal unless there are objections.

[joperezr]

It makes me a bit nervous if we are the first ones to ever expose these constants in the sense of: Why hasn't this been done elsewhere with other meters? In general I'm not really opposed to it, but I'd be curious to hear what either @JamesNK or @noahfalk think about this given I don't think there is a lot of precedent of strong-typing meter names.

[JamesNK]

I don't know anywhere we do this for other metrics. Or telemetry in general. Meters, instruments, activity source names, activity names, tag names, event counters, etc.

If folks want to use telemetry in a .NET app, then they likely copy the name into a string from docs.

I don't think you should expose constants. It's possible to add it in the future if there is demand for it.

[noahfalk]

I feel the same as James. We haven't exposed these strings as public API constants for any other built-in telemetry and I've never seen any criticism/requests related to it.

Making this type public will also enable us to obsolete instruments, if that becomes necessary for one reason or another

Most references to the names of telemetry occur in config files or out-of-process tooling so I'd expect plenty of editing whether API constants are available or not.

[RussKie]

Thank you for your feedback. Closing as "rejected".