Kafka Adaptive Balancer
Keep broker load balanced as your Kafka cluster grows and traffic changes. AxonOps proposes partition replica and leadership changes for you to review before starting a rebalance.
Balance broker load
Plan replica and leadership changes around broker load and capacity limits.
Plan cluster changes
Put new brokers to work or drain replicas from a broker before retiring it.
Stay in control
Review proposals and run a dry run before choosing to execute live changes.
Broker capacity
Understand where broker load is uneven
Individual brokers can carry more traffic or store more data as workloads change. The Adaptive Balancer uses your existing AxonOps metrics to identify uneven load and propose replica placement changes based on your configured goals.
Compare broker utilisation alongside partition and leader counts to assess whether rebalancing or additional capacity is needed.
Kafka monitoring
Placement goals
Balance capacity with replica protection
Enable rack-awareness and capacity goals to check proposed moves against your cluster's failure domains and resource limits. Distribution goals then seek a more even spread of load within those constraints.
Set the enabled goals for each cluster so development and production can use different requirements. Rack-aware placement uses the failure domains you configure through broker.rack.
Proposal review
Check the plan before moving data
Review the proposed replica moves and leadership changes alongside the estimated data volume. The analysis also reports remaining goal violations so you can assess the plan before executing it.
A dry run validates the execution plan without submitting changes to Kafka. For live execution you can limit concurrent movements and data in flight while tracking individual movement results.
Follow the rebalancing workflow
Across your Kafka clusters
Rebalancing within your existing AxonOps operations
One place to manage clusters
Manage balancing across your Kafka clusters with separate goals and analysis history for each cluster. No separate balancing application to operate for every cluster.
No extra metrics collector
The AxonOps service uses metrics already collected by your AxonOps agents. Those agents carry out the Kafka requests through their existing connections.
Access control and audit records
Restrict balancing to Admin and SuperUser roles. Changes are audited with who did what and when so your team can review them alongside execution history.
Kafka rebalancing questions
Does Kafka rebalance partitions when you add a broker?
Adding a broker does not move existing partition replicas onto it. AxonOps can propose replica reassignments to use the new broker based on the cluster model and enabled goals so you can review the changes before executing them.
Is broker rebalancing the same as consumer-group rebalancing?
Broker rebalancing changes where partition replicas are stored or which replicas lead partitions. Consumer-group rebalancing changes which application instance reads each partition without moving stored replicas between brokers. Adaptive Balancer handles broker rebalancing.
Does AxonOps rebalance Kafka automatically?
AxonOps calculates balancing proposals from your cluster metrics and goals but an operator starts live execution. You can review the proposals and run a dry run before submitting any replica reassignments to Kafka.
Does AxonOps use Kafka Cruise Control?
AxonOps Adaptive Balancer is a separate implementation that uses your existing AxonOps metrics and agent connections. Our Kafka Cruise Control comparison covers multi-cluster management and enterprise controls alongside the rebalancing workflow.
See Adaptive Balancer in AxonOps
Talk through your Kafka capacity and rebalancing requirements with our team. Adaptive Balancer needs to be enabled for your organisation.