Schedule icon
Amqp1Publish icon
Amqp1Consume icon
Return icon
Switch icon
SlackIncomingWebhook icon
Log icon

AMQP 1.0 Dead-Letter Queue and Canary Delivery Sentinel

Audit AMQP 1.0 broker dead-letter queues, verify synthetic canary delivery, classify health status, and alert Slack on poison message backlog breaches.

Categories
Infrastructure

Enterprise messaging backbones running ISO-standard AMQP 1.0 brokers, such as Apache ActiveMQ Artemis, RabbitMQ 4.x, Azure Service Bus, or Apache Qpid, frequently encounter poison messages caused by unexpected serialization shifts, downstream consumer bugs, or schema drift. When unhandled, failing messages route into dead-letter queues (DLQs) where they silently accumulate, consuming broker storage, exhausting memory quotas, and masking recurring application outages.

This blueprint provides an automated Day 2 operations sentinel for AMQP 1.0 brokers. On a scheduled interval, it delivers a synthetic canary message to verify broker link creation and acceptance, samples accumulated dead-letter messages without message destruction, classifies cluster health across five operational tiers, and dispatches real-time Slack alerts before buffer limits cause broker degradation.

How it works

  1. The periodic_schedule trigger invokes the flow on a 4-hour cadence with explicit parameter bindings, shipped in a disabled state for initial validation.
  2. probe_canary_delivery (io.kestra.plugin.amqp.Amqp1Publish) publishes a synthetic JSON heartbeat payload carrying the execution ID and timestamp to canary_address, validating that the broker opens links and returns delivery acceptance.
  3. probe_dlq_backlog (io.kestra.plugin.amqp.Amqp1Consume) drains up to sample_limit dead-letter records from dlq_address within bounded maxDuration and pollDuration windows, writing the raw payload stream to Kestra internal storage.
  4. classify_broker_posture (io.kestra.plugin.core.debug.Return) evaluates canary delivery counts and consumed DLQ message volume using Pebble logic to produce an unambiguous status token: BROKER_UNREACHABLE, CANARY_DELIVERY_FAILED, DLQ_BACKLOG_BREACH, DLQ_WARNING, or HEALTHY.
  5. route_posture_action (io.kestra.plugin.core.flow.Switch) routes downstream actions: critical backlog breaches and delivery failures dispatch actionable alerts to Slack, minor warnings log diagnostic advice, and clean runs confirm stability.
  6. audit_sentinel_run (io.kestra.plugin.core.log.Log) writes an immutable summary entry to the execution logs recording the verdict, DLQ count, and published canary metrics.
  7. A flow-level errors handler catches unhandled transport failures or authentication timeouts, dispatching an incident notice to Slack.

What you get

  • Automated, continuous validation of AMQP 1.0 broker write and read link protocols.
  • Early warning of poison message accumulation before dead-letter queues exhaust disk or memory quotas.
  • Durable internal storage capture of dead-letter message batches for offline forensic analysis.
  • Real-time Slack notifications pinpointing broker endpoints, message counts, and storage locations.
  • Clean execution history tracking operational SLA trends across messaging backbones.

Who it's for

  • Platform Engineers and SREs maintaining self-hosted ActiveMQ Artemis, Red Hat AMQ, or RabbitMQ 4 clusters.
  • Cloud Infrastructure Teams managing Azure Service Bus namespaces and enterprise event brokers.
  • Integration Engineers and Data Engineers relying on AMQP 1.0 messaging for transactional data transport.

Why orchestrate this with Kestra

Scripting broker health checks with custom Python or Bash daemons introduces unmanaged cron jobs, unmasked credential exposure, and fragmented logging. Kestra provides native AMQP 1.0 tasks built directly on Apache Qpid Proton-J2, enterprise secret governance, declarative scheduling, execution auditability, and turnkey Slack alerting without requiring sidecar monitoring daemons or custom consumer agents.

Prerequisites

  • An AMQP 1.0 compliant broker reachable from the Kestra worker environment (e.g. Apache ActiveMQ Artemis, RabbitMQ 4, or Azure Service Bus).
  • An existing dead-letter address (e.g. orders.dlq) and a designated canary test address (e.g. sentinel.canary).
  • A Slack Incoming Webhook URL for alert routing.

Secrets

  • AMQP_USERNAME: Authentication username for the AMQP 1.0 broker connection.
  • AMQP_PASSWORD: Authentication password or SAS token for the AMQP 1.0 broker connection.
  • SLACK_WEBHOOK_URL: Incoming webhook URL for the destination Slack channel.

Quick start

  1. Configure AMQP_USERNAME, AMQP_PASSWORD, and SLACK_WEBHOOK_URL in your Kestra namespace secrets.
  2. Start a local open-source Apache ActiveMQ Artemis container for testing:
    docker run -d --name artemis-sentinel \
      -p 5672:5672 -p 8161:8161 \
      -e ARTEMIS_USER=artemis \
      -e ARTEMIS_PASSWORD=artemis \
      apache/activemq-artemis:latest
    
  3. Connect the Artemis container to your Kestra Docker network:
    docker network connect YOUR_KESTRA_NETWORK artemis-sentinel
    
  4. Execute a manual test run in the Kestra UI to verify link establishment and check that HEALTHY is classified.
  5. Enable the periodic_schedule trigger to activate autonomous 4-hour background surveillance.

How to extend

  • Add automated dead-letter message redelivery using an approval-gated io.kestra.plugin.amqp.Amqp1Publish task to replay quarantined messages back to the primary intake queue once downstream defects are resolved.
  • Incorporate schema validation with io.kestra.plugin.serdes.avro or JSON Schema validation to automatically quarantine messages failing contract compatibility.
  • Route critical alerts to PagerDuty or Opsgenie via io.kestra.plugin.pagerduty for tier-1 on-call paging during sustained broker degradations.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.