You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current design is an overall cluster utilization up to 100%. This masks two things:
Makes it hard to see if one broker is heavily over-utilized/under-utilized
Makes it hard to understand actual cpu utilization if you don't know the underlying core counts configured for shards.
It would be good to break up the primary cpu utilization gauge into at least a per-broker heat map (and maybe a per-shard one on one of the lesser dashboards, like the ops dashboard, rather than the default).
I think this will help people understand available headroom given that they're likely used to looking at system.cpu from the kernel where this stuff is more easily accessible, especially if coming from another system like Apache Kafka where java utilization == cpu utilization.
The text was updated successfully, but these errors were encountered:
Current design is an overall cluster utilization up to 100%. This masks two things:
It would be good to break up the primary cpu utilization gauge into at least a per-broker heat map (and maybe a per-shard one on one of the lesser dashboards, like the ops dashboard, rather than the default).
I think this will help people understand available headroom given that they're likely used to looking at system.cpu from the kernel where this stuff is more easily accessible, especially if coming from another system like Apache Kafka where java utilization == cpu utilization.
The text was updated successfully, but these errors were encountered: