Leader skew and shrunk ISR
Every leader on one broker, plus a partition below its replication factor
Topic: orders Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2 Topic: orders Partition: 1 Leader: 1 Replicas: 1,2 Isr: 1
Kafka Partition Assignment Visualizer
See how partition replicas and leadership actually sit across your brokers. Replica counts can be perfectly even while one broker leads everything, and leadership is what carries the traffic.
Give a rack per broker id and every partition is checked for spreading across them. Leave it empty to skip that check. Rack placement is applied when a topic is created and is not maintained afterwards, so a reassignment can quietly undo it.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Visualize. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A healthy topic
Leaders spread and every ISR full, for comparison
Topic: orders Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 Topic: orders Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 Topic: orders Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Leaving every leader on one broker
Leaders take all the client traffic. Concentrated leaders mean one broker saturated and the rest idle.
Instead:Run the preferred leader election, and check auto.leader.rebalance.enable.
Ignoring a shrunk ISR
A partition with fewer in-sync replicas than min.insync.replicas rejects acks=all writes, and the producer error names the topic rather than the cause.
Instead:Alert on UnderMinIsrPartitionCount.
Assigning replicas without rack awareness
Without broker.rack, replicas can land in one failure domain and a single rack loss takes the partition offline.
Instead:Set broker.rack and reassign.
Replica count is not the load, leadership is
A cluster can be perfectly even on replicas and badly uneven on leadership, and only the second one decides where the traffic goes.
Leadership follows the first replica in each list
Every produce and every consumer fetch for a partition goes to that partition's leader. The first entry in a replica list is the preferred leader, and a preferred leader election puts leadership back exactly there, so the spread of first replicas is what leadership settles to whatever it happens to be right now. A reassignment that distributes replica sets evenly while starting every list with the same broker gives you an even-looking cluster that fails at one machine.
# even replicas, terrible leadership
0: [1,2,3]
1: [1,3,2]
2: [1,2,3]
-> broker 1 holds 3 replicas, same as the others,
and leads all three partitionsPreferred and current leadership are different numbers
After a broker restart, leadership has moved to other replicas and does not come back on its own until auto.leader.rebalance.enable acts on its own schedule, or until you run a preferred election. Paste a kafka-topics --describe output and both columns appear side by side, which is the quickest way to see how much a preferred election would actually change.
kafka-leader-election.sh --bootstrap-server broker:9092 \
--election-type preferred --all-topic-partitionsRack awareness is applied at creation, not maintained
With broker.rack set, Kafka spreads a new topic's replicas across racks. A manual reassignment can undo that and nothing recomputes it or complains. A partition whose replicas share a rack loses every copy when that rack does, and with min.insync.replicas=2 it stops accepting writes the moment the rack goes rather than degrading. Give this page a broker-to-rack mapping and it checks every partition against the racks available.
Under-replicated is a different problem from unbalanced
A replica outside the ISR does not count toward acks=all and cannot be elected leader without unclean election. If the in-sync count falls below min.insync.replicas the partition refuses writes, which is the setting working as intended and looks like a producer fault. Worth fixing the lag before touching any configuration, because lowering min.insync.replicas to restore writes trades away exactly the durability it was set for.
What this reads
Either a reassignment JSON, the kind kafka-reassign-partitions takes and produces, or the output of kafka-topics --describe. The second carries current leaders and ISR and so gives a fuller answer. Racks go in the box above as id=rack pairs. Nothing here contacts a cluster: it reads what you paste.
Related kafka tools
Kafka Consumer Assignment Visualizer The three assignors disagree Kafka Connect Pipeline Visualizer The order things really run in Kafka Key to Partition Mapper Which partition does this key land on? Kafka Partition Reassignment Generator The throttle is not optional Kafka Partition Count Calculator The number you can never reduce Kafka Consumer Group Id Validator Which broker coordinates the group
All 73 kafka tools