DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor RabbitMQ with Vigilmon

#rabbitmq #monitoring #devops #backend

How to Monitor RabbitMQ with Vigilmon

RabbitMQ is one of the most widely used message brokers in production — powering background job queues, event buses, and microservice communication for millions of applications. When RabbitMQ goes down or queues back up, the symptoms are delayed: jobs stop processing, emails stop sending, and orders go unfulfilled — all without an obvious error page.

This guide shows how to monitor RabbitMQ with Vigilmon — from broker health to queue depth alerting via heartbeats.

RabbitMQ Failure Modes

RabbitMQ fails in ways that don't immediately surface to end users:

  • Memory alarm triggered — RabbitMQ pauses all publishers when memory usage exceeds the high-watermark
  • Disk space alarm — RabbitMQ stops accepting messages when disk drops below the minimum threshold
  • Queue depth explosion — consumers crash; the queue grows unboundedly; broker eventually OOMs
  • Dead letter queue buildup — unprocessable messages accumulate silently in DLX queues
  • Network partition — cluster split-brain causes messages to be routed incorrectly

Step 1: Monitor the RabbitMQ Management API

RabbitMQ ships with a management plugin that exposes an HTTP API:

# Enable management plugin (if not already enabled)
rabbitmq-plugins enable rabbitmq_management
Enter fullscreen mode Exit fullscreen mode

The API health endpoint is available at:

GET http://localhost:15672/api/health/checks/alarms
Enter fullscreen mode Exit fullscreen mode

This returns {"status":"ok"} when no alarms are active, or a non-200 when memory/disk alarms are triggered.

In Vigilmon:

  1. Add HTTP(S) monitor
  2. URL: http://your-rabbitmq-host:15672/api/health/checks/alarms
  3. Authentication: Basic auth (guest/guest in dev, use a monitoring user in prod)
  4. Alert if: status != 200

Step 2: Monitor the Broker Liveness Check

RabbitMQ 3.8+ includes a dedicated liveness endpoint:

GET http://localhost:15672/api/health/checks/virtual-hosts
Enter fullscreen mode Exit fullscreen mode

This checks that all virtual hosts are accessible. Monitor it with a 60-second interval.

Step 3: Monitor Queue Depth via Heartbeat

Queue depth monitoring is the most important RabbitMQ check — but it requires polling the management API and comparing against a threshold. Use a cron heartbeat:

#!/bin/bash
# rabbitmq-queue-check.sh — run every 2 minutes via cron

RABBIT_HOST=${RABBIT_HOST:-localhost}
RABBIT_PORT=${RABBIT_PORT:-15672}
RABBIT_USER=${RABBIT_USER:-guest}
RABBIT_PASS=${RABBIT_PASS:-guest}
QUEUE=${QUEUE_NAME:-jobs}
MAX_DEPTH=${MAX_QUEUE_DEPTH:-5000}
HEARTBEAT_URL=${VIGILMON_HEARTBEAT_URL:-https://hb.vigilmon.online/YOUR-HEARTBEAT-ID}

DEPTH=$(curl -sf -u "$RABBIT_USER:$RABBIT_PASS" \
  "http://$RABBIT_HOST:$RABBIT_PORT/api/queues/%2F/$QUEUE" | \
  grep -o '"messages":[0-9]*' | cut -d: -f2 | head -1)

if [ -n "$DEPTH" ] && [ "$DEPTH" -lt "$MAX_DEPTH" ]; then
  curl -sf "$HEARTBEAT_URL" > /dev/null
fi
Enter fullscreen mode Exit fullscreen mode

Configure in cron:

*/2 * * * * /usr/local/bin/rabbitmq-queue-check.sh
Enter fullscreen mode Exit fullscreen mode

If the queue exceeds your threshold, the heartbeat stops — Vigilmon fires an alert.

Step 4: Monitor Dead Letter Queues

Dead letter queues (DLX) silently accumulate unprocessable messages. Add a separate heartbeat check for your DLX:

#!/bin/bash
# Check dead letter queue is empty (or below threshold)
DLX_DEPTH=$(curl -sf -u guest:guest \
  "http://localhost:15672/api/queues/%2F/dead-letters" | \
  grep -o '"messages":[0-9]*' | cut -d: -f2 | head -1)

if [ "$DLX_DEPTH" -lt 10 ]; then
  curl -sf "https://hb.vigilmon.online/YOUR-DLX-HEARTBEAT-ID" > /dev/null
fi
Enter fullscreen mode Exit fullscreen mode

Step 5: Monitor with Celery or Sidekiq (Application-Level)

If you use RabbitMQ as the Celery broker:

# celery_health.py - expose health endpoint
from celery import Celery
from flask import Flask, jsonify

app = Flask(__name__)
celery = Celery(broker='amqp://localhost//')

@app.route('/health')
def health():
    try:
        # Check broker connectivity
        conn = celery.connection()
        conn.ensure_connection(max_retries=1)
        conn.close()
        return jsonify({'status': 'ok', 'broker': 'connected'}), 200
    except Exception as e:
        return jsonify({'status': 'error', 'error': str(e)}), 503

if __name__ == '__main__':
    app.run(port=9100)
Enter fullscreen mode Exit fullscreen mode

Monitor http://your-worker-host:9100/health with Vigilmon.

RabbitMQ Monitoring Coverage Table

Monitor Type Target Alert Condition
HTTP(S) Management API /api/health/checks/alarms Status != 200
HTTP(S) /api/health/checks/virtual-hosts Status != 200
Heartbeat Queue depth cron (main queue) No ping if depth > 5000
Heartbeat DLX check cron No ping if DLX > 10
HTTP(S) Application worker health Status != 200

Conclusion

RabbitMQ failures are insidious — they don't crash your app, they just make it slow down and stop processing work. Vigilmon's combination of HTTP health checks and heartbeat queue monitoring gives you full visibility into broker health and queue depth.

Start monitoring RabbitMQ free at vigilmon.online

Top comments (0)