A New Kafka Viewer for a Better Debugging Workflow

Kafma is a new Kafka viewer tool for macOS, Windows, and Linux, built to keep the debugging workflow in one workspace. Each topic opens as a persistent Console tab that keeps its message stream, producer, topic details, schema context, and consumer state together.

A Kafka browser can help you find and read a record, but debugging usually continues beyond it. You need to inspect its metadata and schema, check what a consumer group has processed, reproduce the input, and observe what happens next.

Each step is straightforward on its own. The friction comes from moving between separate consumer, producer, Schema Registry, topic, and consumer-group views—and rebuilding the same context each time. Kafma keeps those parts of the investigation together, so the debugging loop becomes shorter: find the records, inspect their context, create a controlled test, and watch the result.

Kafka debugging loses context easily

Consider a common debugging sequence:

1. Consume a bounded set of records around the time an issue occurred.
2. Find the relevant key or payload and inspect its headers, partition, offset, and timestamp.
3. Resolve the schema and check whether the record was encoded as expected.
4. Check the consumer group's position and whether the record is still in its backlog.
5. Reuse the record as a test case or produce a modified version.
6. Watch the new input arrive, then check whether the target consumer group processes it and advances its committed position.

This is one investigation, but it is often spread across several commands and screens. Copying only the payload between them is not enough: message keys, headers, schemas, partitions, and consumer positions are all part of the context.

The missing piece is not another isolated view. It is a workspace that keeps the message, schema context, topic details, consumer state, and producer together throughout the investigation.

A persistent workspace for each topic

In the Console, each topic opens in its own tab. The message stream occupies the upper part of the tab, the producer stays available below it, and a topic-details drawer opens beside them. Several topic tabs can remain open at once, so one investigation does not need to replace another.

The Console also remembers the open tabs for each cluster connection. If you switch from a production cluster to a local cluster and later return, the topics you were investigating are still open. Each cluster has its own tab set, which helps prevent local and production work from being mixed together while keeping both workspaces ready.

This matters when a problem crosses environments: you can keep the source cluster's context intact while reproducing the issue in a local cluster.

Find and inspect the relevant messages

A busy topic may contain far more data than one investigation needs. Start with a bounded snapshot from the newest records, the beginning, a specific offset, or a timestamp. Then narrow the loaded records by key, value, or partition.

Kafma reads these records directly from the brokers. Opening or refreshing a Console tab does not join an application consumer group, trigger a rebalance, or commit offsets, so inspection does not change the consumer state you are trying to understand.

Expand a record to see its key, value, headers, partition, offset, timestamp, size, and compression. When Schema Registry is connected, Kafma resolves the schema ID and automatically decodes Avro, Protobuf, and JSON Schema records. The original bytes remain available in the Raw view, which is useful when the serializer, schema, or wire format may be part of the problem.

For the individual controls and decoding behavior, see Consuming messages and Decoding Avro and Protobuf messages.

Inspect the topic without leaving the Console

A suspicious record often raises questions about the topic around it. Is a partition unhealthy? What is the retention policy? Which consumer groups use the topic? How much data is currently retained?

The topic-details drawer answers those questions without replacing the message stream. It shows topic health, message count, retention, partitions, and the consumer groups associated with the topic. This keeps the topic details, selected record, and producer visible in the same tab.

Keeping the details beside the stream avoids a common break in the debugging flow: navigating to a separate topic or consumer page, finding the same resource again, and then returning to the original message.

Watch a consumer group in the message stream

Lag is more useful when you can connect it to the records waiting to be processed. In Watch Group mode, the Console shows a bounded window around a selected consumer group's committed positions and marks records as consumed, pending, or unassigned.

The same view includes member status, total lag, and the lag trend. A divider separates the remaining backlog from the most recently consumed record, so you can inspect the messages at the front of the lag rather than looking at a number in isolation.

Kafma reads the group's committed positions without joining the group. Watching it therefore does not add a member or trigger a rebalance in the application you are debugging.

This closes an important gap in the workflow: the message contents and the consumer's progress are visible in the same investigation.

Reuse messages across topics and clusters

Once you find a representative record, you should not have to reconstruct it by hand.

Replay to topic opens a producer for the current topic or another topic in the same cluster and fills in the record's key, value, and headers. The result is an editable draft, not an immediate write. You can change the payload, choose a partition or schema version, and review everything before producing it.

For a quick cross-cluster test, Forward to cluster sends one record—or the currently loaded, filtered set—to the same topic name on another cluster. Kafma blocks forwarding to clusters marked as Production. Schema-backed records are forwarded as decoded JSON or text rather than retaining their original Schema Registry encoding. Export is also available when the current records need to be saved as JSON or CSV for a test or shared investigation.

Replay and forwarding solve different problems. Replay creates a controlled, editable test case; forwarding moves messages directly. Forwarding does not copy Schema Registry subjects or topic configuration. When the destination needs the topic's schemas, configuration, and a selected range of source data, use Data Clone instead.

See Replay and export Kafka messages for the exact behavior of each action.

Keep a producer loop running while you debug

Some consumer behavior is difficult to test with a single record. An application may aggregate a stream, process periodic events, or fail only after several inputs arrive.

The Console producer can send one message manually or run on a timed Loop. A loop can repeat the current key, value, and headers at a fixed interval. If the key or value is bound to a Schema Registry subject, the loop can regenerate that field on every tick with a fresh schema-compatible payload.

The loop continues while you switch to other Console tabs or pages in the same cluster. You can keep generating test traffic while inspecting another topic, checking a consumer group, or following a different part of the debugging flow. Return to the source tab to see the sent count or stop the loop. Closing the source tab stops the loop.

This makes Loop useful for simulating a producer that reports continuously while you work on the consumer side. It is intended for repeatable functional testing, not throughput benchmarking.

See Producing messages for payload encodings, schema generation, partitions, acknowledgments, and Loop controls.

More than a Kafka viewer

The value of one workspace is not simply that several controls fit on one screen. It is that the investigation remains intact:

• The topic stays open as a tab.
• The message stream and producer share the same context.
• Topic details and consumer state are available without leaving the Console.
• A producer loop can continue while you inspect other resources.
• Each cluster preserves its own set of open investigations.

A conventional Kafka viewer can show which records are in a topic. For debugging, the useful unit is larger: Kafma keeps the topic, message metadata, schema context, consumer state, producer, and active investigation together—even when you switch between clusters.

Download Kafma for macOS, Windows, or Linux, or read the Console documentation for a complete reference.