Skip to main content
Kafka Brokers are the server nodes that store data and serve client requests. This page lets you monitor broker health, view connection details, and inspect or modify broker configurations.

​
Key Concepts

Broker

A Kafka server node that stores topic partitions and handles produce/consume requests from clients.

Controller

One broker in the cluster is elected as controller. It manages partition leader elections and replica assignments.

Rack Awareness

Brokers can be assigned to racks for fault tolerance. Kafka distributes replicas across racks when possible.

Endpoints

Each broker exposes one or more listener endpoints with different security protocols (PLAINTEXT, SSL, SASL_SSL).

​
Required Permissions

Broker configuration changes require admin-level permission. Modifying broker configs can affect cluster stability.

​
How to View Brokers

1

Select Kafka Cluster

Choose the target Kafka cluster from the dropdown.
2

View Broker List

The table shows all brokers in the cluster with their host, port, and controller status.
3

Open Broker Details

Click on a broker row to view detailed information including connection details, partition counts, and configurations.

​
How to View Broker Configuration

1

Open Broker Detail Page

Click on a broker to navigate to its detail page.
2

Go to Configuration Tab

Select the Configuration tab to view all broker settings.
3

Filter Configurations

Use the available filters:
  • Search: Find specific configuration keys
  • Modified Only: Show only non-default values
  • Source Filter: Filter by configuration source

​
Configuration Sources

Broker configurations come from different sources with varying precedence:
Dynamic configurations take precedence over static configurations. Changes made through the UI create dynamic configurations.

​
Understanding Configuration Metadata

Each configuration entry includes metadata:
  • Read-Only: Cannot be modified (Kafka internal settings)
  • Sensitive: Value is hidden for security (passwords, keys)
  • Source: Where the current value comes from

​
Common Broker Configurations

​
Performance Tuning

​
Log Management

​
Replication

​
Broker Detail Information

The detail page shows:

​
Connection Details

  • Host: Broker hostname or IP address
  • Port: Listener port number
  • Rack: Physical rack assignment (if configured)
  • Role: Controller or Follower status

​
Partition Statistics

  • Leader Partitions: Number of partitions where this broker is leader
  • Follower Partitions: Number of partitions where this broker is a replica

​
Endpoints

List of listener endpoints showing security protocol for each (PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL).

​
Troubleshooting

  • Verify the broker is running and connected to the cluster
  • Check network connectivity between the API server and brokers
  • Ensure the bootstrap servers configuration includes reachable addresses
  • The broker may be in a failed state; check Kafka logs
  • You need read permission for Kafka
  • The broker may be unreachable
  • Check if the Kafka cluster is healthy
  • You need admin permission to modify broker configurations
  • Some configurations are read-only and cannot be changed
  • The value may be invalid for the configuration type
  • Check if the broker is accepting connections
  • The broker process may have crashed
  • Network partition between brokers
  • Check disk space on the broker node
  • Review broker logs for errors
  • Run partition reassignment to balance leaders
  • Check if other brokers are healthy
  • Consider using Kafka’s kafka-leader-election.sh tool

​
FAQ

No. Broker membership is managed by Kafka itself. To add brokers, start new Kafka instances pointing to the same ZooKeeper/KRaft cluster. To remove brokers, gracefully shut them down after reassigning their partitions.
The Controller is elected among brokers and handles administrative tasks: partition leader elections, tracking cluster membership, and managing topic/partition metadata. If the controller fails, another broker is elected.
Read-only configurations are either Kafka internals or require a broker restart to change. These must be modified in the broker’s server.properties file and require a restart.
Configurations marked as sensitive contain security-related values like passwords or API keys. Their values are hidden in the UI and API responses for security.
Dynamic configurations are stored in ZooKeeper/KRaft and applied without broker restart. They override static configurations in server.properties. Changes take effect immediately.
Rack awareness lets Kafka spread partition replicas across different failure domains (racks, availability zones). Configure broker.rack in server.properties and ensure topics have enough replicas to span racks.
Check leader partition count (unbalanced distribution increases load), monitor network I/O thread configuration, and review follower partition lag. High partition counts on a single broker may indicate need for rebalancing.

​
Best Practices

​
Monitor Broker Balance

Ensure leader partitions are evenly distributed across brokers. An unbalanced cluster puts excessive load on certain brokers.

​
Use Rack Awareness

In multi-datacenter or multi-AZ deployments, configure broker.rack to ensure replicas are distributed for fault tolerance.

​
Review Configuration Changes

Before modifying broker configurations:
  1. Understand the impact on cluster performance
  2. Test changes in a non-production environment
  3. Monitor broker metrics after changes
  4. Document configuration changes for audit purposes

​
Regular Health Checks

Monitor broker health regularly:
  • Check that all brokers are online
  • Verify controller election is stable
  • Monitor partition leader distribution
  • Watch for under-replicated partitions