-
Notifications
You must be signed in to change notification settings - Fork 103
feat(pool): Expose utilization and activity metrics from the pool #4658
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
Conversation
relay-threading/src/metrics.rs
Outdated
/// | ||
/// Note that this metric is collected and updated for each thread when the main future is polled, | ||
/// thus if no work is being done, it will not be updated. | ||
pub fn utilization(&self) -> u8 { |
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.
Maybe call that cpu_utilization
and expose a total_utilization
which does max(activity, cpu_utilization)
which can be used in the auto scaler thingy?
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.
I am thinking of the edge case where we have 100% activity since we are doing lots of I/O and 0% max utilization (assuming no cpu bound work is being done). Do we really want to scale in this case? Scaling might not help.
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.
Up to you, without thinking too much about I would have said yes, because scaling is probably the safer option.
This PR updates the metrics emitted by the async pool:
utilization
-> it now calculates how busy the pool is by checking the CPU-bound work it is doing.activity
-> it checks how active the pool is (this was the previous utilization metric). The activity determines how many futures are currently being driven by the pool w.r.t. the total capacity of futures it can hold.To make this possible I have reused the
ServiceMonitor
which has been renamed toTimedFuture
and it has been made agnostic of any service related internals. Additionally, the future now relies on aTimedFutureReceiver
to emit lifecycle and state changes.Closes: https://github.com/getsentry/team-ingest/issues/689