How to implement Prometheus Gauge Set method in open-telemetry？

[lsytj0413]

Problem Statement

A clear and concise description of what the problem is.
Ex. I'm always frustrated when [...]

I'm trying to migrate an project's metric implement from Prometheus to open-telemetry，it heavily use gauge.Set to measure values with different labels group. For example:

It have an gauge metric for conn pool stats, defined as:

conn_pool_stat{type=?}

and type's value could be one of: free、running as so on.

On other hand, another library we used only expose an Store method to the user, which is been called when the library want to set a metric to an concrete value (with different labels group), we implement Store use gauge.Set method. but when we migrate to open-telemetry，we only have two choice:

1. Float64UpDownCounter，but it only have an Add method
2. Float64ObservableGauge，but it only record value when callback is perform, and the library will call Store at any time.

base on this discription，how should implement gauge.Set method in open-telemetry with different label groups？

I have search for previous issue，and found #708 (comment) is and similar requests.

Proposed Solution

A clear and concise description of what you want to happen.

Alternatives

A clear and concise description of any alternative solutions or features you've considered.

Prior Art

A clear and concise list of any similar and existing solutions from other projects that provide context to possible solutions.

Additional Context

Add any other context or screenshots about the feature request here.

[MrAlias]

Related to open-telemetry/opentelemetry-specification#2318

[lsytj0413]

The specification have add an sync gauge at https://github.com/open-telemetry/opentelemetry-specification/pull/3540，is there any plan to implement it in go？

[MrAlias]

The specification have add an sync gauge at https://github.com/open-telemetry/opentelemetry-specification/pull/3540，is there any plan to implement it in go？

When it becomes stable in the specification, yes.

[dashpole]

You can (relatively easily) work around this using asynchronous gauges:

func ExampleSynchronousGauge() {
	myGauge := NewFloat64Gauge()
	_, err := meter.Float64ObservableGauge(
		"my.metric.name",
		metric.WithUnit("s"),
		metric.WithInt64Callback(myGauge.Callback),
	)
	if err != nil {
		panic(err)
	}
        // use your synchronous gauge!
	myGauge.Set(3.14, attribute.NewSet(attribute.String("one", "1")))
	myGauge.Set(3.14159, attribute.NewSet(attribute.String("one", "bar")))

	// Later, if I want to stop exporting that attribute set:
	myGauge.Delete(attribute.NewSet(attribute.String("one", "1")))
}

func NewFloat64Gauge() *Float64Gauge {
	return &Float64Gauge{observations: make(map[attribute.Set]float64)}
}

type Float64Gauge struct {
	observations map[attribute.Set]float64
}

// Callback implements the callback function for the underlying asynchronous gauge
// it observes the current state of all previous Set() calls.
func (f *Float64Gauge) Callback(ctx context.Context, o metric.Float64Observer) error {
	for attrs, val := range f.observations {
		o.Observe(val, metric.WithAttributeSet(attrs))
	}
	return nil
}

func (f *Float64Gauge) Set(val float64, attrs attribute.Set) {
	f.observations[attrs] = val
}

func (f *Float64Gauge) Delete(attrs attribute.Set) {
	delete(f.observations, attrs)
}

[dashpole]

I don't think this should block the prometheus exporter's GA.

[rivik]

Seems sync gauge already released in specs (https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.25.0)

Are there any support plans for golang?

[dashpole]

We likely won't support it until it is promoted to stable.

[amedveshchek]

I've worked it around by implementing gauge using the example of OpenTelemetry telemetrygen tool, which submits the Gauge metrics by default: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/cmd/telemetrygen/internal/metrics/worker.go#L52-L64

Will replace my workaround with the original synchronous Gauge once it's implemented.