Belajar RabbitMQ - Alerting & Health Checks

#Pendahuluan

Di episode 24 kalian membangun observability: metrik mengalir ke Prometheus dan tampil di Grafana. Tapi dashboard yang indah tidak akan membangunkan kalian jam 3 pagi saat queue menumpuk. Di episode ini, observability bertransformasi menjadi actionability — melalui health checks dan alerting.

Health checks menjawab dua pertanyaan sederhana namun penting: "apakah broker masih hidup?" (liveness) dan "apakah broker siap menerima trafik?" (readiness). Sementara alerting memastikan kondisi abnormal segera diketahui tim, melalui kanal yang tepat — Slack, email, atau PagerDuty.

Episode ini menyusun alerting secara sistematis: apa saja yang harus di-alert, berapa ambang batasnya, dan lewat mana notifikasinya. Di akhir episode, kalian memiliki runbook dasar untuk merespons tanda-tanda pertama kerusakan broker.

#Health Checks

#Liveness dan Readiness Checks

Liveness check memastikan proses node hidup. Cara termudah: cek apakah port AMQP merespons, atau minta status node:

Liveness check port AMQP

nc -zv localhost 5672
rabbitmqctl await_startup

Readiness check memastikan node siap menerima trafik — queue bisa diakses, tidak dalam alarm, dan node bukan partitioned. Readiness yang tepat memakai health check API internal:

Health check API internal

rabbitmqctl eval 'rabbit_health_checks:check_local_alarms().'
rabbitmqctl eval 'rabbit_health_checks:check_if_running().'

Evaluasi check_local_alarms() gagal jika node sedang dalam memory/disk alarm — itulah sinyal "belum siap" yang bisa dipakai orchestrator seperti Kubernetes (episode 29).

#Custom Health Check Endpoint

Untuk kebutuhan spesifik, buat script health check sendiri yang memverifikasi: node tidak alarm, koneksi consumer aktif untuk queue kritikal, dan queue depth di bawah ambang. Jalankan script ini terjadwal dan kirim hasilnya ke sistem monitoring.

#Strategi Alerting

#Alert Kritis yang Wajib Ada

Beberapa kondisi yang harus memicu alert:

Memory alarm — node memblokir publisher; tanda segera bertindak.
Disk alarm — disk mendekati penuh; node berhenti memproses pesan.
Queue length — depth queue melewati ambang dalam durasi tertentu.
Consumer down — tidak ada consumer aktif untuk queue kritikal.
Cluster partition — node terpisah; risiko split-brain.
Dead letter queue — depth DLQ terus naik (pengingat dari episode 11).

#Menyusun Aturan Alert di Prometheus

Contoh aturan alert queue depth di prometheus.yml:

Alert queue length di Prometheus

groups:
  - name: rabbitmq
    rules:
      - alert: RabbitQueueDepthHigh
        expr: rabbitmq_queue_messages > 10000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Queue {{ $labels.queue }} melebihi 10 ribu pesan"

Aturan di atas menyala jika queue messages melebihi 10.000 selama 5 menit — cukup panjang untuk mengabaikan lonjakan sesaat.

#Integrasi Alat Alerting

#Notifikasi ke Slack dan Email

Grafana dan Alertmanager bisa meneruskan alert ke banyak kanal. Di Alertmanager, atur penerima Slack dan email:

Receiver Alertmanager untuk Slack

receivers:
  - name: ops
    slack_configs:
      - channel: "#infra-alert"
        api_url: "https://hooks.slack.com/services/XXXX"
    email_configs:
      - to: "ops@example.com"

Kedua receiver di atas memastikan notifikasi sampai ke kanal Slack tim operasional dan email cadangan.

#PagerDuty dan Custom Webhook

Untuk insiden kritis yang menuntut respons segera, hubungkan ke PagerDuty atau OpsGenie — alert on-call akan di-eskalasi otomatis. Untuk sistem internal, cukup buat custom webhook: Alertmanager mengirim POST JSON ke endpoint tim kalian, yang bisa meneruskannya ke aplikasi notifikasi internal atau bot.

Warning

Alert yang terlalu banyak justru berbahaya: tim belajar mengabaikan notifikasi. Mulai dari beberapa alert benar-benar kritis, lalu tambahkan perlahan. Setiap alert harus punya tindakan yang jelas — jika tidak, hapus saja.

#Penutup

Di episode 25 ini kalian sudah membuat liveness dan readiness checks, memakai health check API internal, menyusun alerting untuk memori, disk, queue length, consumer down, partition, dan DLQ, serta mengintegrasikan notifikasi ke Slack, email, PagerDuty, dan webhook.

Inti yang harus dibawa pulang:

Liveness mengecek proses hidup; readiness mengecek siap menerima trafik.
check_local_alarms adalah readiness check bawaan yang andal.
Alert memory dan disk harus segera direspons.
Queue length alert dengan durasi for menghindari false positive.
Alert consumer down dan cluster partition menangkap kegagalan kritis.
PagerDuty untuk eskalasi on-call; Slack untuk informasi umum.
Terlalu banyak alert membuat tim mati rasa — pilih dengan hati-hati.

Di episode 26 selanjutnya kita akan menghubungkan federation dan shovel — mereplikasi exchange dan queue antar cluster dengan Federation, meneruskan pesan point-to-point dengan Shovel, membandingkan keduanya, serta merancang pola multi-datacenter dan transfer pesan yang andal untuk disaster recovery. Ini jembatan antar broker!