Update all metric types in processconv to be Observable

[mike-kulinski-dd]

Problem Statement

There are a number of different metrics in the processconv package that aren't using the Observable variants. I am trying to emit some more metrics like process.memory.usage but it's difficult to instrument this correct since that is an Int64UpDownCounter instead of an Int64ObservableUpDownCounter.

This would also make it easier to add these metrics into the go.opentelemetry.io/contrib/instrumentation/host which would be nice considering the Otel spec recommends to emit these metrics. https://opentelemetry.io/docs/specs/semconv/system/process-metrics/#metric-processmemoryusage

Proposed Solution

Update all metrics in processconv to use the Observable variants

Alternatives

I am planning on just creating my own Observable counters for the metrics I want to emit, but it would be nice to use the official semconv package so I didn't have to define that myself.

Prior Art

In the host metrics instrumentation, they are already emitting some metrics using this pattern. https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/host/host.go#L235-L239

You can see that CPUTime for example is an ObservableFloat64. https://github.com/open-telemetry/opentelemetry-go/blob/main/semconv/v1.37.0/processconv/metric.go#L215-L225

I tried looking into adding my own instrumentation so that I could emit more metrics like process.memory.usage but I noticed that that metric in processconv wasn't an Observable. https://github.com/open-telemetry/opentelemetry-go/blob/main/semconv/v1.37.0/processconv/metric.go#L501-L511 So it was difficult to emit like the CPUTime was.

[pellared]

From https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/metrics.md#instrument-types:

The semantic metric conventions specification is written to use the names of the synchronous instrument types, like Counter or UpDownCounter. However, compliant implementations MAY use the asynchronous equivalent instead, like Asynchronous Counter or Asynchronous UpDownCounter. Whether implementations choose the synchronous type or the asynchronous equivalent is considered to be an implementation detail. Both choices are compliant with this specification.

Maybe we should simply generate both variants (synchronous and asynchronous) for metrics which are defined as synchronous instruments in semantic conventions?

@open-telemetry/go-maintainers, WDYT?

[dashpole]

I like that idea. Or at least generate both by default, and have the config remove the one we don't need once it is set. Part of the process of adding instrumentation could be removing the unused generated instruments.

[pellared]

I think generating both is more flexible. It allows building 3rd party instrumentations that may use different instrument types than contrib

[mike-kulinski-dd]

Right now both sync and async counters exist in processconv. If we generate both what would the naming convention be? Does semconv have the same backwards compatibility requirements?

[seh]

I just ran into this gap yesterday. The processconv.Uptime type is not observable, so it's difficult to register a callback to call on its Report method periodically.

[pellared]

Right now both sync and async counters exist in processconv. If we generate both what would the naming convention be? Does semconv have the same backwards compatibility requirements?

I would just add Observable suffix for the async ones.