2026.11.5 — 2026-11-02

Added

• View and change broker configuration (616a11f8)

  Operators can now read and change the settings of a Kafka broker, or of the cluster-wide default, without leaving Rahdar. Brokers lists a Configuration link per broker and a link to the cluster default.

  Each setting is shown with its value and where it comes from: set on that broker, the cluster default, the broker's file, or a built-in default. A setting only a restart changes is shown as a fact, with the reason, and has no edit control. Secrets are never listed or accepted.

  Changes are collected, reviewed against what they would replace, and applied against the state the review read, so a configuration that changed in between is refused as stale. Applying is gated like a topic configuration change, audited before the broker call and finished after it. A refusal by the broker, such as a restart-only setting, answers 409 with the broker's own words.

  New endpoints under /api/v1/clusters/{id}/kafka/brokers/{broker}/config, where {broker} is a broker number or default: GET, POST config:preview and POST config:apply.

• Complete FROM with topics on Kafka and streams on RabbitMQ (120f99af)

  The SQL console's FROM completion offered consumer groups on a Kafka cluster and every queue on a RabbitMQ one. It now offers topics on Kafka and only streams on RabbitMQ, the one queue kind that can be read without consuming.

• Offer the SQL console on Kafka and RabbitMQ clusters (c202dc51)

  The SQL Console is no longer hidden on Kafka and RabbitMQ clusters. Its syntax help explains what differs there: a Kafka topic is read from its log with the partition available as props.partition, and only RabbitMQ streams can be queried.

• Query Kafka topics and RabbitMQ streams from the SQL console (fe60b7cb)

  The SQL console now works on Kafka and RabbitMQ clusters without a capture step. Neither system can filter where its messages are kept, so the console reads the log and evaluates the whole WHERE in Rahdar, inside the same scan cap, row limit and timeout as an Artemis query.

  • Kafka: FROM names a topic (or a pattern). Every partition is read from its start. offset is messageId, the record time is timestamp, and the partition is queryable as props.partition.
  • RabbitMQ: only streams are browsable. A classic or quorum queue named by the query is refused with 409 and the reason (reading it would take its messages); matched by a pattern it is skipped and a notice names it.
  • The message index stays Artemis-only: creating, previewing or changing a capture on another system answers 409 naming the system and pointing at the direct query. Live tail and verify-on-broker state honestly that the system has no selectors.

• Map Kafka consumer groups and RabbitMQ bindings in Flow (ce85f704)

  Flow now works on Kafka and RabbitMQ clusters, not only Artemis. The Flow page and its "Show in Flow" actions are offered on every cluster.

  • Kafka: each consumer group with a running member is drawn as a consumer of every topic it reads, from one batched read of the group subscriptions. Kafka does not list producers, so none are shown and the graph says so.
  • RabbitMQ: consumers are drawn on their queue with the connection's client id, user and address. Bindings are drawn as routes from an exchange to its queue with the routing key as the filter; exchange bindings, shovels and federation links are drawn as forwards and links. Rahdar does not read RabbitMQ producers, and says so.
  • Both read the whole cluster in one call, so Flow samples them once through the first node instead of once per node. Their rates are unavailable rather than zero, as neither keeps a per-client counter.
  • Artemis keeps its wildcard joins and the management.xml access hint; other systems show neither.

• Watch Kafka and RabbitMQ clusters through their own health (71eb2786)

  A new Kafka or RabbitMQ cluster is seeded with one built-in rule, Cluster degraded, instead of the Artemis set. That rule now reads the health the cluster's system judges, which is the same verdict the cluster screen shows: offline partitions, lost brokers and the controller quorum on Kafka, and node reachability and memory or disk alarms on RabbitMQ. Before this change, cluster degraded read Artemis live/backup pairs on every system, so it never fired on Kafka or RabbitMQ.

  Split-brain, node down, replication behind, clock skew, configuration drift, setup risk and the slow-consumer metric read what only Artemis reports. On a Kafka or RabbitMQ cluster they are now refused with a 409 (unsupported-on-system) that names the system and what to watch instead. The rule form lists them disabled and marked "Artemis only", with that reason beside it. The form offers a consumer-lag template on Kafka and a queue-depth template on RabbitMQ in place of the slow-consumer one.

  Kafka and RabbitMQ clusters registered before this release keep the Artemis rules they were seeded with, which never fire there. Delete them and add a Cluster degraded rule; the form starts one from its cluster-degraded template.

Fixed

• Keep saying ACLs are unavailable on a cluster with no authorizer (ed363bb5)

  OpenBroker 0.9.1 reports a Kafka cluster with no ACL authorizer as "not supported", with the Kafka error attached. Rahdar dropped that error when it turned the refusal into a conflict, so the ACL page answered 409 instead of saying ACLs are unavailable on the cluster. A conflict now keeps the broker's failure as its cause, so the page reads it as before.

• Give rows read from a log the id of their topic or stream (0d829c31)

  Rows, targets and node outcomes of a Kafka topic or a RabbitMQ stream were named with the id of the system's first subscription kind, which is not the resource that was read. They now carry the id of the topic or stream itself.

• Show the message index only on Artemis clusters (5b225000)

  Settings listed "Message index" on every cluster, because the settings page ignored which system a section is for. On a Kafka or RabbitMQ cluster, where the index cannot capture anything, the section is no longer offered.

• Stop wording Kafka and RabbitMQ failures and gaps as Artemis ones (386ad86f)

  • A broker failure whose driver error does not name its system now takes the system of the cluster in the request's path. A Kafka or RabbitMQ error without native details no longer reads as "This Artemis version is not supported" or names a Jolokia agent.
  • A capability gap's remedy is headed "Add this to broker.xml" only for an Artemis snippet. A Kafka or RabbitMQ remedy reads "Make this change on the broker". The cluster header's capability notice says the same.
  • The product tagline, image description, About dialog and trademark notice name Apache Kafka and RabbitMQ next to Apache ActiveMQ Artemis.
  • The API descriptions of versionSupport, versionGates, the token resource pattern and the MCP capabilities resource no longer say Artemis for every system.