Rahdar
03:07:00

It's 3 a.m. A queue is backing up somewhere in your cluster.

Eight brokers, two clusters, four live/backup pairs. Which one is it? Let's find out the way most Artemis operators still do.

Find it

Before

Go on. Find it.

Artemis ships with a web console that manages one broker at a time and has no idea a cluster exists. So a cluster becomes a row of tabs. Open them. Expand the trees. Read the numbers.

Management ConsoleJMXAttributesOperationsCharts

Now close all eight tabs.

One console for every Artemis cluster you run.

Rahdar is open source. It talks to every node you run and shows them together, as one estate.

After

The same incident. One screen.

Both clusters on one canvas, with the HA roles Rahdar actually polled. Every queue on every node in one table, sorted by depth. The broker you were hunting for is the one that's glowing, and its queue is the first row.

Rahdar LIVE · SSE
● live○ backup━ cluster connection┅ replication
Queues · all nodes, both clusters
QueueNodeMessages ▾Consumers
You, one tab at a time
? s

Try the hunt above. The clock starts on your first click.

Rahdar
Row 1

No tabs, no tree, no guessing. It was the first row before you asked.

The whole cluster, not one broker.

Live/backup pairs, replication state and a shared-NodeID axis on one canvas. HA role is polled from every node, never read from config, so two live nodes in a pair shows up as a split-brain alert, not a surprise at 3 a.m.

Every queue, every node, one table.

Queues, addresses, consumers, sessions, connections and producers across the estate in a single virtualised grid, updating over SSE. Sort by depth and the worst thing in the cluster is the first row.

01 / Flow

Watch the messages move.

Mid-incident, "what's in this queue" isn't really the question. It's who sends here, where does it go, and why is it piling up? Flow draws the whole path for a cluster:

  • Producers, then addresses, then queues, then consumers, with diverts, bridges and the hops between nodes.
  • Dots move along every edge, faster and denser as the path gets busier.
  • Colour only shows up when something is wrong, and the problem is spelled out: no consumer, stalled, not connected.
How Flow works
Flow · recorded in Rahdar
02 / Safe operations

Fix it without flinching.

At 3 a.m. the dangerous part isn't finding the queue. It's the button you press next.

  • Every destructive call takes ?dryRun=true and answers with the affected count, without doing anything.
  • Purge and delete are confirmed by pressing and holding the button until it fills, so a stray click cannot do it.
  • The audit event is written in the same transaction as the command, before the broker call, so even a crash mid-operation leaves a record.
Moving messages safely
Move messages
FromORDERS.DLQ @ broker-03
ToORDERS
Filterall messages
Nothing has run yet.
Purge queue · try it
Purge ORDERS.DLQ on broker-03?

Press and hold to confirm.

audit · waiting for confirmation
03 / SQL Console

Ask the question you actually have.

"Where did order 4471 go?" Artemis can't answer that. Its only server-side filter is a JMS selector, which never sees the body and runs against one queue on one node at a time.

  • One query covers every queue in the cluster, including message bodies.
  • It's SELECT-only and parsed to an AST, so no mutation can even be written.
  • The plan shows what each predicate costs before it runs: target, pushdown or scan.
SQL Console guide
SQL Console
target · "ORDERS.#" → 2 queues × 4 live nodespushdown · nonescan · body→>'orderId' (Rahdar reads the body)
queuenodetimestampbody
SQL Console · recorded in Rahdar
04 / Your brokers

Keep your brokers exactly as they are.

Rahdar registers the brokers you already run. It doesn't install them, doesn't restart them, and never writes broker.xml.

  • Nothing to rewrite beyond the management endpoints you almost certainly already have on.
  • If a capability is missing, the UI says so and shows the exact snippet that enables it. Nothing just silently disappears.
  • It goes easy on the broker: reads are batched into one Jolokia POST per node, never one per queue, behind a per-node rate limiter.
Register your first cluster
git diff -- etc/broker.xml
Changes Rahdar needs in your broker configuration
0 files changed
0 insertions(+), 0 deletions(−) · assuming management is on, as it usually is
<!-- what Rahdar talks to, already in a typical install -->
Jolokia  http://broker-01:8161/console/jolokia   reads, operations
Core     tcp://broker-01:61616                  notifications, message I/O

Not a mock-up

This is the real thing.

A real session against a real cluster pair: the topology, the cross-node queue grid, a message that went to the dead-letter queue, message flow and the charts.

Rahdar · unedited session

Also in the box

Everything else you've been missing.

Request-reply tracing

A request matched to its reply across addresses and nodes, with latency and timeouts measured against expectations you declare.

An MCP server

Ask an assistant why ORDERS.DLQ is backed up and get an answer from your real clusters, under the same permissions and audit trail as a person.

Configuration drift

Declare what a cluster should run, apply it canary-first, and see in plain words when any node has drifted.

Message capture

Index the queues you care about so messages you've already consumed can still be queried.

Alert delivery

Send the alert that woke you up to where your team already works, before it wakes anyone at 3 a.m.

Plugins

Install screens, API, assistant tools and data from the UI, most of them without a restart.

Next time it's 3 a.m., open one tab.

Install in one command
$ git clone https://github.com/sudoitir/rahdar && cd rahdar
$ just up   # two Rahdar replicas + HAProxy + Postgres, secrets generated, pinned to the latest release

Your brokers already exist. Rahdar registers them, it doesn't start them.

Read the quickstart Docs ★ Star on GitHub
Alpha. Under active development and not yet feature-complete. Published images are pre-stable dev builds (sudoit1/rahdar:dev, no :latest yet). Expect breaking changes.