Artemis Studio: an open-source cluster console for ActiveMQ Artemis

It's 3 a.m., ORDERS.DLQ is backing up somewhere, and the console that ships with Artemis manages one broker at a time. You open a tab per node and walk a JMX tree until you find it. I got tired of that, so I built Artemis Studio, an open-source console that treats the cluster as the unit.

What it does

• Live topology with HA roles polled from the nodes themselves
• Every queue on every node in one table, sorted by depth
• Search over message contents, with a cost indicator that tells you whether a query is a cheap header lookup or a full body scan
• Message flow view across diverts, bridges and cluster hops
• Safe operations: dry-run on mutating calls, and you type the resource name to confirm a purge or delete
• Setup review that flags known misconfigurations
• MCP server, so an AI assistant uses the same permissions and audit trail as a human

Design choices

Brokers are polled with one batched Jolokia request per node, tiered by how often data changes, with a rate limiter so the console doesn't load the brokers it watches. The app is a single container: Java 25, Spring Boot 4.1, PostgreSQL with Liquibase, and a React front end with a plugin system.

Try it

It's alpha, so expect breaking changes. Apache-2.0, and not affiliated with the ASF.

git clone https://github.com/sudoitir/artemis-studio
cd artemis-studio
just up

Repo: https://github.com/sudoitir/artemis-studio
Story: https://github.com/sudoitir/artemis-studio

Issues, ideas and topologies you'd like supported are welcome on GitHub.

Comments

[Launch Gate]

For the cluster-wide table plus purge/delete confirmation, I'd add a stale-target fixture: open a dry-run for ORDERS.DLQ on node A, then fail over or replace that queue before confirming, while node B has a queue with the same name.

Does the confirmation bind to the broker and resource identity reviewed in the dry-run, or can the typed name authorize a newly resolved target? A stale preview should require a fresh review, and the audit trail should distinguish requested, attempted and confirmed outcomes if the broker times out after a mutation. I haven't run Artemis Studio; this is a suggested operation-identity fixture from the topology and safe-operation flow in the post, not a reported flaw.

[Mahdi AmirAbdollahi]

Thanks, this is a really useful fixture. Right now the confirmation isn't tied to the exact target you reviewed in the dry-run, so a stale preview could slip through. I'll work on it and add it: a stale-target test, a fresh review when the target changes, and separate requested / attempted / confirmed states in the audit trail. For config changes I already do something similar (apply to one broker first, then the rest if it's OK). I'll track it in an issue. Thanks again!

[baumgaerben]

Đúng lúc 3 sáng thì mới thấy rõ console mặc định thiếu thốn thế nào — chỉ thấy một broker mà cluster 3 node thì mò log từng cái. Tính năng theo dõi DLQ theo topic/queue pattern là cứu cánh, không phải grep log hay jmxterm nữa. Đã từng mất 2 tiếng chỉ để tìm message bị stuck ở node nào vì console không show routing across cluster. Nếu Artemis Studio có thể visualize message flow cross-node và cho phép replay DLQ hàng loạt từ UI thì đỡ phải viết script ad-hoc mỗi vụ sự cố — found it via LabAgent, site: labagent .tech