-
Notifications
You must be signed in to change notification settings - Fork 188
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
Add MaximumOverIntervalGauge #469
base: master
Are you sure you want to change the base?
Add MaximumOverIntervalGauge #469
Conversation
Signed-off-by: Jan Berktold <[email protected]>
Signed-off-by: Jan Berktold <[email protected]>
// The length of a given interval. | ||
interval_duration: Duration, | ||
// The time at which the current interval will expose. | ||
interval_expiry: Arc<RwLock<Instant>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually use an ArcSwap
for this in our internal codebase. I've switched this over to an RwLock
here to avoid taking on the ArcSwap
crate dependency.
#[derive(Clone, Debug)] | ||
pub struct MaximumOverIntervalGauge { | ||
// The current real-time value. | ||
value: Arc<AtomicI64>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here and everywhere else, gauges typically operate on f64
values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was purely an i64 because we weren't clear on how to implement an atomic f64 (nor did we care enough). I just discovered your awesome https://github.com/tikv/rust-prometheus/blob/master/src/atomic64.rs#L89 setup -- will switch this over!
Interesting, I'll need to read a bit more about the underlying logic. Does this have an equivalent in Go world (or any other client library)? |
Depends on #405.
This is another "fancy" gauge type from other internal codebase that I believe to be beneficial to others.
We have a few use cases where we want to monitor a value that moves around a lot. One example is measuring the number of concurrent requests for a gRPC server.
With a normal gauge, we're only able to inspect the value as of the time of the scraping (typically once every 10 seconds). This actually got us in production -- We had queue build ups due to downstream TCP re-connects that were manifesting themselves as increased latency for our customers but our metrics looked fine.
Enter the
MaximumOverIntervalGauge
: Instead of reporting the current value, we report the maximum of the value over the last (user configured) interval. This allows us to observe shifts that resolve themselves in less than the configured scrape interval.