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

Add MaximumOverIntervalGauge #469

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

JanBerktold
Copy link
Contributor

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.

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>>,
Copy link
Contributor Author

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>,
Copy link
Member

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.

Copy link
Contributor Author

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!

@lucab
Copy link
Member

lucab commented Nov 15, 2022

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants