sonirico.dev

Marcos Sánchez
SRE @ Chess.com
Madrid

A k9s for Redpanda

The sagacious reader will have noticed this blog’s fondness for Redpanda by now. My homelab keeps everything in its topics (part I), I patched the broker itself to read them by key (part II), and the serialization experiment that became parco was born streaming trades through it. Today the streak continues with something smaller: I’ve released readpanda, a terminal UI for looking inside those topics.

The itch

My inspection loop was rpk topic consume piped through jq. That works until the topic is Avro, where the payload is a magic byte, a schema id and bytes jq won’t touch. Then the loop grows a curl to the schema registry and a decode script, multiplied by however many topics I’m watching. k9s solved this shape of problem for Kubernetes years ago: stop composing the inspection by hand, put the operator inside the cluster. I wanted the same seat for my broker.

What it does

readpanda is a Bubble Tea TUI over any Kafka-compatible cluster. It draws the topics as a tree, folding the dot hierarchy (shop.orders.v1, iot.sensors.temperature) into branches you expand and filter. Drill into a topic and you get a live tail that decodes Avro, JSON Schema and Protobuf inline through the schema registry, so the wire bytes come out as the JSON you actually wanted. The other tabs cover consumer groups with their lag, partitions, topic config and brokers. The keys are k9s keys, because my fingers already knew them.

Live tail of an Avro topic, records decoded inline through the schema registry

Try it

The repo ships a demo: a docker-compose with a single-node Redpanda, a seed script that creates nine topics in a dot hierarchy, and a traffic generator that publishes Avro orders and JSON telemetry while a deliberately slow consumer builds up lag. Two terminals and you’re in:

just demo-up
just demo-traffic
go run ./cmd/readpanda --brokers localhost:19092 --sr-url http://localhost:18081

It’s early and it’s read-only, which for a tool you point at production is less a limitation than a promise. If it breaks on your cluster, I’d rather hear about it than not.