David Ashpole

/assign @yangjunmyfm192085 /triage accepted

Based on https://github.com/prometheus/client_golang/blob/76b74e25d5660965000a74cf2e918c217ed76da2/prometheus/go_collector.go#L26, this is the mapping from memStats to go runtime metrics: * `memStats.Alloc` is the same as the `/memory/classes/heap/objects:bytes` runtime metric. * `memStats.Sys` is the same as the...

This is definitely the right time to make changes to the new runtime metrics. I don't think there is a rush with disabling the old metrics, and we won't remove...

> So, it appears there's no equivalent. If you do not group by the `go.memory.type` label, you would get /`memory/classes/total:bytes - /memory/classes/heap/released:bytes`, which is what we want. It is common...

If we want to add `/memory/classes/heap/objects:bytes`, we would need to propose it here: https://github.com/open-telemetry/semantic-conventions/blob/106f880ccbf26443f115ce1f48c236ec6a0b6f1b/docs/runtime/go-metrics.md?plain=1#L4

We should involve the Go folks that worked on the proposal from the Go side.

> memStats.TotalAlloc This is equivalent to [go.memory.allocated](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/runtime/go-metrics.md#metric-gomemoryallocated) > memStats.Alloc This makes sense to me as a potential opt-in metric. > memStats.Sys We could consider exposing released memory as a separate...

> Yes, it's supported in new metrics, but not in old metrics. If we want to keep both new and old in sync, we could add it to the old...

> The reason I'm considering total or released is useful is that, even Go has “released” the memory, the OS may not immediately reclaim it. This may affect physical memory...

So to summarize, we want to get feedback from to Go folks on: * Is "released" memory useful for determining if the OS has reclaimed memory? Does it have any...