Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to model Prometheus Gauge in OpenTelemetry language? #708

Closed
moorara opened this issue May 9, 2020 · 10 comments
Closed

How to model Prometheus Gauge in OpenTelemetry language? #708

moorara opened this issue May 9, 2020 · 10 comments
Assignees
Labels
area:metrics Part of OpenTelemetry Metrics
Milestone

Comments

@moorara
Copy link
Contributor

moorara commented May 9, 2020

Use-Case

I want to have an instrument similar to Prometheus Gauge metric to measure the number of in-flight request. Basically, on each request I need to increase and once the request is handled, decrease it. The aggregation is also should be last value I believe.

Any suggestion how can I approach this use-case?

@moorara moorara changed the title How can we model Prometheus Gauge in OpenTelemetry language? How to model Prometheus Gauge in OpenTelemetry language? May 9, 2020
@moorara
Copy link
Contributor Author

moorara commented May 9, 2020

I can see OpenTelemetry spec has defined an UpDownCounter instrument, but I cannot figure out how to implement it using OpenTelemetry Go SDK.

@jmacd
Copy link
Contributor

jmacd commented May 11, 2020

The 0.4 specification has not been formally released yet, and the language SDKs are not caught up yet. #709 is the key next step toward adding the new instruments, after which I plan to add multi-observer support (see #634), followed by the new instruments.

@jmacd
Copy link
Contributor

jmacd commented Jun 18, 2020

I believe this will be resolved: #708

@MrAlias
Copy link
Contributor

MrAlias commented Jun 18, 2020

@jmacd did you mean open-telemetry/oteps#118?

@moorara
Copy link
Contributor Author

moorara commented Jun 19, 2020

I was able to use the new UpDownCounter in 0.6.0 release and implement a gauge, so I close this.

@moorara moorara closed this as completed Jun 19, 2020
@otherview
Copy link

Hey @moorara any chance you can show a snippet of the code ?
I'm also stuck trying to create a Gauge too.

Thanks!

@moorara
Copy link
Contributor Author

moorara commented Sep 8, 2020

@otherview

This is a simple example:

import "go.opentelemetry.io/otel/api/metric"

type instruments struct {
	reqCounter  metric.Int64Counter
	reqGauge    metric.Int64UpDownCounter
}

func newInstruments(meter metric.Meter) *instruments {
	mm := metric.Must(meter)

	return &instruments{
		reqCounter: mm.NewInt64Counter(
			"http_requests_total",
			metric.WithDescription("The total number of http requests"),
			metric.WithUnit(unit.Dimensionless),
		),
		reqGauge: mm.NewInt64UpDownCounter(
			"http_requests_active",
			metric.WithDescription("The number of in-flight http requests"),
			metric.WithUnit(unit.Dimensionless),
		),
	}
}

And here is how you can measure the metrics:

...
m.instruments.reqGauge.Add(ctx, 1,
	label.String("method", "GET"),
	label.String("route", "/"),
)
...
m.instruments.reqGauge.Add(ctx, -1,
	label.String("method", "GET"),
	label.String("route", "/"),
)
...

You can see the full code here.

@otherview
Copy link

Thanks for the swift reply @moorara !

So.. to replicate a promauto.NewGauge().Set() (prometheus client API) I would have to store and subtract the existing value in otel?

@seanhoughton
Copy link

I would like to ask that this issue be re-opened because the answer doesn't work for a large number of use cases where the instrumentation doesn't have access to each value increment/decrement events. It might work for the specific case of an http handler, but not for many classes of instrumentation where change event instrumentation is not possible. Examples include water levels, engine temperatures, disk consumption, and number of processes running.

The opentelemetry-collector's host metrics is a good example of where this is needed and that codebase goes through some gymnastics to implements gauge types internally, although the types are private. Example: https://github.com/open-telemetry/opentelemetry-collector/blob/08a18d5b9f1b8ee001f8e16e6f6b9daf45b4d42e/cmd/mdatagen/metricdata.go#L104

The fact that a tool written by the opentelemetry team implemented a full suite of gauges in one of its own project indicates to me that they should just be implemented in the core library as first class instruments or at least promoted to a public util library for use in other projects.

@seanhoughton
Copy link

Ultimately the solution looks like something that is still to be worked on. Instead of using a dedicated instrument like I mentioned above you would use a ValueObserver/ValueRecorder and make sure the aggregation selector uses the last value instead of producing a histogram (which is baked in to the prometheus convenience functions). The workaround is to make your own selector which will let you return a "lastvalue" aggregator for value recorders and observers.

See: #1139 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:metrics Part of OpenTelemetry Metrics
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants