-
Noob question: Is there any particular reason that
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Generally, the various metric types are specialized on updating their value in instrumentation and then return them in a scrape. If we had methods to directly access the metric values, it would signal that those methods are useful and efficient, and generally meant to be used for regular operation. See also https://pkg.go.dev/github.com/prometheus/[email protected]/prometheus/testutil#ToFloat64 for a helper function to access the value of a Gauge and why that's only recommended for special cases like tests. |
Beta Was this translation helpful? Give feedback.
-
In that case, I would recommend to manage the Gauge value on your own and expose it via https://pkg.go.dev/github.com/prometheus/[email protected]/prometheus#NewGaugeFunc Note that you run into all kind of concurrency problems. After retrieving the value from a Gauge, another goroutine might already update it before you set it again. Furthermore, future versions of client_golang might leverage core-local variables that are only gathered together upon scrape… |
Beta Was this translation helpful? Give feedback.
In that case, I would recommend to manage the Gauge value on your own and expose it via https://pkg.go.dev/github.com/prometheus/[email protected]/prometheus#NewGaugeFunc
Note that you run into all kind of concurrency problems. After retrieving the value from a Gauge, another goroutine might already update it before you set it again. Furthermore, future versions of client_golang might leverage core-local variables that are only gathered together upon scrape…