-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
I can see OpenTelemetry spec has defined an |
I believe this will be resolved: #708 |
@jmacd did you mean open-telemetry/oteps#118? |
I was able to use the new |
Hey @moorara any chance you can show a snippet of the code ? Thanks! |
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. |
Thanks for the swift reply @moorara ! So.. to replicate a |
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. |
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) |
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?
The text was updated successfully, but these errors were encountered: