Prometheus dan AlertManager: Membangun Sistem Alert On-Call yang Benar-Benar Berfungsi

Prometheus mengumpulkan metrik. AlertManager memutuskan siapa yang dihubungi dan kapan. Kombinasi keduanya, yang dilakukan dengan benar, adalah perbedaan antara mengetahui pemadaman sebelum pengguna Anda tahu dan mengetahuinya ketika ponsel Anda berdering pukul 3 pagi dari klien. Di Commsult Indonesia, saya memelihara stack Prometheus + AlertManager yang memantau 11 server di dua cloud provider. Kami mendapatkan alert yang dapat ditindaklanjuti — bukan kebisingan — karena desain aturan alert yang cermat dan konfigurasi routing AlertManager. Panduan ini mencakup apa yang benar-benar berfungsi di produksi, termasuk kesalahan yang saya buat dalam mengonfigurasi AlertManager yang menyebabkan banjir alert dan insiden yang terlewat.

Peran AlertManager dalam Stack Prometheus

Prometheus memicu alert berdasarkan aturan PromQL — ketika suatu kondisi bernilai benar lebih lama dari durasi for, Prometheus mengirimkan alert ke AlertManager. AlertManager kemudian menangani deduplikasi, pengelompokan, routing, pembungkaman, dan inhibisi sebelum mengirim notifikasi ke receiver (Telegram, Slack, PagerDuty, email). Pemisahan concern ini bersih: Prometheus tahu apa yang salah; AlertManager memutuskan siapa yang diberitahu dan bagaimana. Arsitektur ini berarti Anda dapat memiliki beberapa instance Prometheus yang mengirimkan alert ke satu cluster AlertManager, dan AlertManager berkoordinasi di antara semuanya.

Desain Aturan Alert: Kualitas di Atas Kuantitas

Kesalahan terbesar yang dilakukan tim dengan alerting Prometheus adalah menulis terlalu banyak aturan alert terlalu cepat. Setiap aturan yang menyala menjadi notifikasi, dan terlalu banyak notifikasi menyebabkan alert fatigue — engineer mulai mengabaikan alert karena tidak dapat ditindaklanjuti. Tulis aturan alert hanya untuk kondisi yang memerlukan tindakan manusia. Alert yang baik memiliki pemilik yang jelas, tindakan yang jelas, dan tingkat urgensi yang jelas. 'CPU > 90% selama 5 menit' dapat ditindaklanjuti jika Anda telah menetapkan apa yang harus dilakukan ketika CPU melonjak. 'Penggunaan disk > 80%' dapat ditindaklanjuti karena tindakannya jelas (tambah storage atau bersihkan file). 'Node up is 0' dapat ditindaklanjuti — server down. Alert untuk 'HTTP 4xx rate > 5%' mungkin hanya kebisingan jika aplikasi Anda memiliki 404 yang diharapkan.

Konfigurasi Routing Tree

Routing tree AlertManager menentukan alert mana yang menuju ke receiver mana. Route root adalah catch-all — setiap alert yang tidak cocok dengan route yang lebih spesifik berakhir di sini. Child route mencocokkan label alert (severity, service, environment) dan merutekan ke receiver tertentu. Routing tree produksi: alert severity critical pergi ke PagerDuty untuk paging on-call segera; alert severity warning pergi ke saluran Telegram untuk ditinjau; alert informasional pergi ke mailing list prioritas rendah. Routing berbasis environment: alert prod pergi ke grup Telegram on-call; alert staging dan dev pergi ke saluran terpisah yang dipantau lebih sedikit orang.

Inhibition Rule: Mencegah Kebisingan Alert Cascading

Inhibition rule menekan alert ketika alert level yang lebih tinggi sudah menyala. Kasus penggunaan klasik: jika alert 'cluster tidak dapat dijangkau' menyala, hambat semua alert 'layanan down' untuk layanan dalam cluster tersebut — karena root cause adalah cluster yang tidak dapat dijangkau, bukan kegagalan layanan individual. Menulis inhibition rule memerlukan pencocokan yang cermat untuk menghindari over-inhibisi. Gunakan source_matchers (alert yang melakukan inhibisi) dan target_matchers (alert yang dihambat) dengan pencocokan label untuk memastikan hanya alert yang tepat yang ditekan. Over-inhibisi dapat menyebabkan Anda melewatkan kegagalan independen nyata.

# alertmanager.yml — Production routing configuration
global:
  resolve_timeout: 5m

route:
  group_by: [alertname, env, cluster]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: default-telegram

  routes:
    - matchers:
        - severity = critical
      receiver: oncall-telegram
      continue: false
    - matchers:
        - severity = warning
        - env = prod
      receiver: prod-warnings-telegram

inhibit_rules:
  - source_matchers:
      - alertname = ClusterUnreachable
    target_matchers:
      - alertname = ServiceDown
    equal: [cluster, env]

receivers:
  - name: oncall-telegram
    telegram_configs:
      - bot_token: "YOUR_BOT_TOKEN"
        chat_id: -1001234567890
        message: |
          FIRING: {{ .GroupLabels.alertname }}
          Severity: {{ .CommonLabels.severity }}
          {{ range .Alerts }}{{ .Annotations.summary }}{{ end }}

Integrasi Telegram untuk Tim Indonesia

Telegram adalah saluran alerting paling praktis untuk tim DevOps Indonesia — semua orang telah menginstalnya, berfungsi dengan andal di Indonesia, dan AlertManager memiliki dukungan Telegram native. Buat bot Telegram melalui @BotFather, buat grup chat untuk alert, tambahkan bot, dan dapatkan chat ID. Dalam konfigurasi receiver AlertManager, gunakan blok telegram_configs dengan token bot dan chat_id. Format pesan alert dengan template pesan untuk menyertakan nama alert, severity, deskripsi, dan tautan ke dashboard Grafana yang relevan. Alert Telegram yang diformat dengan baik memberi tahu engineer on-call persis apa yang salah dan ke mana harus melihat dalam 30 detik setelah membuka notifikasi.

┌──────────────────────────────────────────────────────┐
│         Prometheus + AlertManager Flow                │
├──────────────────────────────────────────────────────┤
│                                                      │
│  Prometheus (evaluates PromQL rules every 1m)        │
│       ↓ Alert fires (condition true for "for" period)│
│  AlertManager Cluster (HA: 2 nodes, gossip protocol) │
│       ↓ Deduplicate + Group (group_wait: 30s)        │
│       ↓ Apply inhibition rules                       │
│       ↓ Route by severity/env labels                 │
│                                                      │
│  critical → Telegram on-call group (immediate)       │
│  warning  → Telegram prod-warnings channel           │
│  info      → Email digest (low priority)             │
└──────────────────────────────────────────────────────┘

Cluster AlertManager High-Availability

Instance AlertManager tunggal adalah single point of failure untuk infrastruktur alerting Anda. Jika AlertManager down, semua alert Prometheus mengantri secara diam-diam dan Anda tidak menerima notifikasi selama pemadaman. Jalankan AlertManager dalam cluster HA dengan setidaknya dua instance menggunakan flag --cluster.peer untuk menghubungkannya. AlertManager menggunakan protokol gossip untuk berbagi state notifikasi di seluruh instance — ini mencegah notifikasi duplikat ketika Prometheus mengirimkan alert ke beberapa instance AlertManager. Dengan dua instance AlertManager, Prometheus mengirimkan setiap alert ke keduanya; instance berkoordinasi melalui gossip untuk memastikan hanya satu yang mengirimkan notifikasi.

Manajemen Silence untuk Pemeliharaan Terencana

Pemeliharaan terencana menghasilkan alert yang diharapkan — reboot server menyebabkan alert 'server down'; migrasi database menyebabkan alert slow query. Fitur silence AlertManager memungkinkan Anda menekan alert tertentu untuk jendela waktu yang terdefinisi. Buat silence melalui UI web atau API AlertManager sebelum pemeliharaan dimulai. Silence mencocokkan matcher label dan memiliki waktu kedaluwarsa. Disiplin yang saya terapkan: setiap jendela pemeliharaan terencana harus memiliki silence AlertManager yang dibuat sebelum dimulai. Ini mencegah notifikasi page yang tidak perlu selama gangguan yang diharapkan dan menjaga kepercayaan tim on-call bahwa alert adalah masalah nyata, bukan kebisingan pemeliharaan.

Pendapat Saya: Seperti Apa Alerting yang Baik

Setelah dua tahun menjalankan Prometheus + AlertManager di Commsult Indonesia, alerting yang baik berarti: menerima kurang dari 5 notifikasi alert per minggu selama operasi normal, setiap notifikasi dapat ditindaklanjuti dalam 10 menit setelah diterima, dan nol insiden 'produksi down dan tidak ada yang di-page'. Untuk mencapai ini memerlukan penulisan aturan alert yang menyala pada gejala daripada penyebab (alert pada 'HTTP 5xx rate > 1%' bukan 'CPU > 80%'), konfigurasi pengelompokan dan inhibisi yang agresif, dan sesi tinjauan alert triwulanan di mana kami secara sengaja menghapus alert yang menyala tetapi tidak memerlukan tindakan. Alert debt — aturan yang terakumulasi yang tidak direspons oleh siapa pun — sama merusaknya terhadap operasi seperti technical debt terhadap kualitas kode.

Artikel Terkait

• Grafana dan Prometheus: Setup Stack Monitoring Lengkap di VPS
• Perencanaan Disaster Recovery: Monitoring sebagai Bagian dari Strategi DR