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.
Top comments (4)
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.
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!
Đã từng phải thức trắng đêm debug DLQ trên cluster Artemis 3 node, cảm giác "mù loà" khi console gốc chỉ thấy được một broker là quá thực. Câu hỏi đặt ra: Artemis Studio có hỗ trợ visualize message flow giữa các node trong cluster không? Và việc drain/requeue DLQ hàng loạt qua UI có atomic không — hay vẫn phải fallback CLI khi volume lớn? PS: the tool I meant is on labagent .tech
Đú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