[OpenTelemetry.Instrumentation.Process] Multiple provider dispose issue

[CodeBlanch]

Issue with OpenTelemetry.Instrumentation.Process

process.cpu.utilization requires tracking of the last collection time. When multiple providers are used, it needs to track it based on the provider. There isn't a really good way to do this. What we're doing is creating a Meter instance for each provider. But each instance has the same name for Meter & Instruments so SDK is probably just treating everything as one data stream. To compound that problem, when a provider is disposed it should dispose its instrumentation. Due to the same name issue this leads to all providers being unsubscribed if one provider is disposed.

Update: There is a failing test which demonstrates the disposal problem.

[alanwest]

process.cpu.utilization requires tracking of the last collection time. When multiple providers are used, it needs to track it based on the provider. There isn't a really good way to do this.

Agreed, this seems like a spec limitation.

The semantics define process.cpu.utilization as:

Difference in process.cpu.time since the last measurement, divided by the elapsed time and number of CPUs available to the process.

I don't think instrumentation can maintain state like this without violating the spec in some way. This definition seems be be geared toward an out-of-proc implementation like the collector's host metrics receiver.

I haven't found other languages that have implemented process.cpu.utilization. Java appears to to have introduced their own utilization metrics with different semantics.

For example, process.runtime.jvm.cpu.utilization is defined as:

Recent CPU utilization for the process

with a footnote

These utilizations are not defined as being for the specific interval since last measurement

Some reasoning for this is presented here. I think it gets the same problem we're bumping up against.

Should we consider doing something similar? That is, just compute utilization based on some fixed recent interval?

[alanwest]

Commented here as well open-telemetry/opentelemetry-specification#2439 (comment)