2026.09.29 — 2026-09-20

Added

• Rank every queue by consumer health, with the cause and the evidence (665f526b)

  Studio can now answer "which of my queues have consumer trouble, and why". A new Consumer health screen under Observe ranks every queue worst-first, and the same verdict appears in a queue's detail drawer, over REST, through the diagnose MCP tool and as a consumerHealth alert condition.

  Each queue gets exactly one verdict from an ordered ladder — PAUSED, NO_CONSUMERS, BROKER_SLOW, STALLED, STARVED, FALLING_BEHIND, DRAINING, HEALTHY, or INSUFFICIENT_DATA — with the numbers behind it: depth and its regression slope, enqueue and acknowledge rates, the net of the two, per-consumer velocity, messages in flight, a drain ETA, and the age and span of the samples it rests on.

  The distinction that matters is STALLED versus STARVED. Both show consumers attached to a backlog that is not moving; only the in-flight count separates them, and they lead to opposite actions — inspect the consumer process, or inspect its selector. ADR-0044 described this failure as invisible in the queue grid, because depth and consumer count both look healthy in exactly this case.

  The broker keeps the last word: a CONSUMER_SLOW notification outranks any derived verdict and names the consumer. A verdict that cannot be computed is reported as INSUFFICIENT_DATA and ranked apart — never as healthy, and never as a zero rate.

  What operators should know when upgrading:

  • metric_sample grows by half. Six metrics are now recorded per queue per sweep rather than four: deliveringCount and messagesExpired join the existing set, both read off the listQueues row the sweep already fetched. No additional broker call is made, and retention and partitioning are unchanged. Lower artemis-studio.metric.retention-days to trade history back for space.
  • Thresholds are artemis-studio.consumer-health.idle-ack-rate (0.01 msg/s), min-backlog (1) and broker-slow-window (10m).
  • No migration. metric_sample.metric and alert_rule.metric are text columns.

  Two pre-existing bugs are fixed on the way:

  • An ackRatePerConsumer alert rule could never be saved. AlertRuleService hard-coded gauge and rate metrics when validating, so the derived metric ADR-0044 ships a template for was rejected as "unknown metric". Validation now asks the conditions themselves what they can evaluate.
  • diagnose reported deliveringCount in the messagesAdded field, scheduledCount in messagesAcknowledged, and paused as always false.

  AlertCondition becomes a real extension point: it takes an exported AlertRuleSpec instead of the unexported JPA entity, declares supports(...), and is discovered as an ordered bean list. That is what lets the new condition live in feature/triage — triage already depends on alerting, so the reverse edge would have been a cycle. Any module that may depend on alerting can now contribute a rule kind.

  See ADR-0089 for the ladder and why it is fixed rather than configurable.