Introduction

Apache Kafka has become the backbone of modern event-driven architectures, powering everything from micro services communication to real-time analytics and stream processing.

As Kafka deployments grow, developers and operators frequently need answers to questions such as:

• Are messages reaching Kafka successfully?
• Which partition received a message?
• Are consumers keeping up with producers?
• How much lag exists in a consumer group?
• How can I inspect Kafka messages without writing to a consumer?

While Kafka provides powerful command-line tools, they can be cumbersome for day-to-day troubleshooting.

This is where Kafdrop comes in.

In this article, we’ll explore how to install Kafdrop, monitor Kafka topics, inspect messages, understand partition assignment, and perform basic topic administration using a real local Kafka setup.

---

Environment Used in This Article

The examples and screenshots in this article were captured using the following setup:

 

Component	Version
Kafka	Local Broker
Kafdrop	4.2.0
Java	17+
Broker Address	localhost:9092

---

What is Kafdrop?

Kafdrop is an open-source web interface for Apache Kafka.

It is a lightweight web UI for Apache Kafka that allows developers and operators to inspect topics, partitions, messages, consumer groups, offsets, and cluster health directly from a browser.

Instead of relying on different commands separately to monitor different components such as:

kafka-topics.sh

kafka-consumer-groups.sh

kafka-console-consumer.sh

You can access Kafka through an intuitive browser-based UI.

 

Key Features of Kafdrop

•  Topic Monitoring
•  Consumer Group Monitoring
•  Partition Visibility
•  Offset Tracking
•  Message Inspection
•  Consumer Lag Monitoring
•  Topic Configuration Viewing
•  Message Search
•  Topic Creation
•  Topic Deletion

---

Running Kafdrop Using Docker

The simplest way to run Kafdrop is through Docker.

docker run -d -p 9000:9000 -e KAFKA_BROKERCONNECT=localhost:9092 obsidiandynamics/kafdrop

Open the application at localhost:9092 and Kafdrop will connect to your Kafka broker.

---

Running Kafdrop Locally Without Docker

 

Step 1: Download the Kafdrop JAR

Download the latest Kafdrop release from the official GitHub releases page:

https://github.com/obsidiandynamics/kafdrop/releases/

 

Step 2: Start Kafdrop

After the above jar is downloaded in your system, launch Kafdrop by connecting it to your Kafka broker using the following command:

java -jar kafdrop-4.2.0.jar –kafka.brokerConnect=localhost:9092

If Kafdrop starts successfully, you should see log messages similar to the following:

Step 3: Accessing the Kafdrop Web UI

After the application has started (Step 2), open your browser and navigate to:

localhost:9000

---

Kafka Cluster Overview

After connecting Kafdrop to the Kafka broker, the dashboard displayed the following cluster overview.

 

Understanding the Kafdrop Dashboard

At the top of the dashboard, you’ll see the Bootstrap Servers value, which in this example is localhost:9092. This indicates that Kafdrop is successfully connected to the Kafka broker running on your local machine.

Next, you’ll notice that the cluster contains 3 partitions for the getting-started topic. These are Partition 0, Partition 1 and Partition 2.

Another useful metric is the Preferred Partition Leader. In this example, all partitions are running on their preferred leader broker, resulting in a value of 100%. This indicates that the cluster is in a healthy state and leadership is balanced as expected.

Finally, the dashboard displays the number of Under-Replicated Partitions, which is 0 in this environment. This means every partition replica is fully synchronised with its leader, indicating that the cluster is healthy.

 

---

Exploring a Kafka Topic

Clicking on the topic name opens the Topic Details page.

 

Topic Overview (getting-started)

Below is the initial state of the topic:

Metric	Value
Partitions	3
Preferred Replicas	100%
Under Replicated Partitions	0
Total Available Messages	0

Publishing Text Messages to the above topic

To demonstrate how Kafka partitions messages based on their keys, I published a few sample messages to the getting-started topic using different message keys.

The following messages were produced:

Key: a  Value: first message
Key: a  Value: second message
Key: b  Value: first message

Notice that the first two messages use the same key (a), while the third message uses a different key (b). This is intentional because Kafka’s default partitioner routes messages with the same key to the same partition. As a result, messages with key (a) should be stored in the same partition and maintain their order, whereas the message with key (b) may be assigned to a different partition.

After publishing these messages, Kafdrop immediately reflects the updated state of the topic. The dashboard shows that the topic still contains 3 partitions, all preferred replicas remain in a healthy state (100%), there are 0 under-replicated partitions, and the Total Available Messages count has increased to 3.

At a glance, we can confirm that the Kafka cluster is healthy, replication is functioning correctly and the messages have been successfully written to the topic.

 

---

Understanding Partition Details

 

The Partition Details section is one of the most valuable views in Kafdrop because it provides insight into how Kafka has distributed messages across the partitions of a topic. Rather than simply showing that messages exist, it allows you to understand where those messages have been stored and how the topic is being utilised.

For the getting-started topic, the partition information is shown below:

Partition	Last Offset
0	0
1	2
2	1

 

From the values shown above, we can immediately see that Kafka has not distributed the messages evenly across all three partitions. Instead, messages have been assigned according to Kafka’s partitioning strategy.

By inspecting the partition details in Kafdrop, you can quickly verify whether messages are being distributed as expected, identify potential partition skew and confirm that key-based partitioning is working correctly.

---

Understanding Kafka Partition Assignment

One of Kafka’s most important features is its ability to consistently route messages with the same key to the same partition. This ensures that messages belonging to the same logical entity are processed in the order they were produced.

This behaviour is critical for:

• Order Processing
• Payment Events
• Inventory Updates
• User Activity Streams

 

In our example, the getting-started topic contains three partitions. When the producer publishes messages with the key a, Kafka computes the same hash value each time, resulting in both messages being assigned to Partition 1. Similarly, the message with key b is hashed to a different value and is therefore routed to Partition 2.

As a result, the messages are distributed as follows:

Partition 1

Key: a Value: first message
Key: a Value: second message

Partition 2

Key: b Value: first message

---

Viewing Messages in Kafdrop

One of Kafdrop’s most powerful features is direct message inspection.

Click: View Messages

to browse messages stored in Kafka.

 

Kafdrop displays:

• Partition
• Offset
• Key
• Timestamp
• Headers
• Payload

---

Monitoring Consumer Groups

The Consumers section displays:

• Consumer Group ID
• Combined Lag

Currently No active consumers.

Once consumers begin processing messages, Kafdrop will show consumer lag information.

Example:

Consumer Group	Lag
order-consumer-group	0

This is extremely useful for identifying slow consumers and processing bottlenecks.

---

Creating Topics Using Kafdrop

Kafdrop provides basic topic administration capabilities.

From the dashboard, click:

+ New

 

You can specify:

• Topic Name
• Partitions
• Replication Factor

This eliminates the need for Kafka CLI commands during development.

---

Deleting Topics Using Kafdrop

When viewing a topic, Kafdrop displays a Delete topic button:

 

This allows administrators to remove topics directly from the UI.

Important Note

Deleting a topic removes:

• Messages
• Offsets
• Metadata

For production environments, topic deletion should be tightly controlled.

---

Real-World Troubleshooting Scenarios

1. Messages Not Being Consumed

Symptoms:

• Producer is publishing events
• Consumer appears healthy

Investigation:

1. Open Consumer Groups
2. Check Lag

Result:

Lag = 10000

This immediately identifies a consumer bottleneck.

 

2. Missing Events

Investigation:

1. Open Topic
2. View Messages

If the event does not exist in Kafka, the issue likely lies with the producer.

 

---

Using Kafdrop in Production

Kafdrop can also be a valuable operational tool in a production environment.

In production systems, Kafdrop provides a centralized interface for developers, support teams, platform engineers, and SREs to quickly inspect Kafka topics, verify message delivery, analyze consumer lag, and troubleshoot issues without accessing Kafka servers directly.

However, production deployments require additional planning around security, scalability, and access control.

During production incidents, support team/dev engineers often need answers such as:

• Did Kafka receive the message?
• Which partition contains the event?
• Was the event produced successfully?
• Is the consumer lagging?
• Are replicas healthy?

Kafdrop provides these answers through a single interface.

 

---

Conclusion

Kafdrop is one of the simplest and most effective tools for Kafka monitoring and troubleshooting.

Using a local Kafka setup, we were able to:

• Monitor cluster health
• Inspect topics and partitions
• View messages
• Understand partition assignment
• Verify message ordering
• Monitor consumers
• Create topics
• Delete topics

Whether you’re learning Kafka, debugging a micro service or operating a production cluster, Kafdrop provides valuable visibility into what is happening inside Kafka without requiring command-line tools or custom consumers.

If your team works with Kafka regularly, Kafdrop deserves a place in your Kafka observability toolkit.