Runtime instrumentation: Can time-in-gc metric be published ?

[davidkvc]

Issue with OpenTelemetry.Instrumentation.Runtime

List of all OpenTelemetry NuGet
packages and version that you are
using (e.g. OpenTelemetry 1.3.2):

• OpenTelemetry.Exporter.Prometheus.AspNetCore 1.5.0-alpha.1
• OpenTelemetry.Extensions.Hosting 1.5.0-alpha.2
• OpenTelemetry.Instrumentation.Runtime 1.1.0-rc.2

Runtime version:

net6.0

Is this a feature request or a bug?

• Feature Request
• Bug

What is the expected behavior?

I was expecting that % Time in GC since last GC (time-in-gc) metric would be published since it is documented as available Well-Known EventCounter. I am just starting with metrics analysis in general and I thought this metric would be useful. Is there any reason why that is not published ?

What is the actual behavior?

time-in-gc metric is not published by the package

Additional Context

When this was not working as I expected I also tried to use OpenTelemetry.Instrumentation.EventCounters but that package is not allowing subscribing to System.Runtime event source.

[xiang17]

The time-in-gc metric was not published was because:

1. time-in-gc was based on an internal API GC.GetLastGCPercentTimeInGC(), which, or an equivalent, was not available as a public API at the moment (but was later introduced starting from .NET 7): [API Proposal]: APIs to expose existing runtime EventCounter data dotnet/runtime#65989
2. The percent-time-in-gc metric is a bit messy design-wise because the computation depends on how long it has been since the API was last called. For more information refer to Runtime instrumentation #207 (comment)

It would be a good idea to add a metric on GC.GetTotalPauseDuration() for people who need to figure out how much time has been spent on GC, now that those blockers are gone, with the new API System.GC.GetTotalPauseDuration() available on .NET 7.

It is also a better design and should be recommended for use over a percentage metric like time-in-gc.

On the legacy time-in-gc specifically, #404 (comment)

This is suggested by @noahfalk - for folks who have been using the EventCounters, we might consider something like "legacy time in GC" and make it an explicit opt-in (with a clear API name indicating that it has an unclear definition, and we don't recommend it).

[xiang17]

For future people coming back to this, please leave a like or comment down below if you also would like to have the time-in-gc in the runtime instrumentation despite having the fancy new gc.duration metrics. (See description here: process.runtime.dotnet.gc.duration.)