Apa peran AlertManager dalam stack Prometheus, dan mengapa ia terpisah dari Prometheus itu sendiri?

Prometheus bertugas mengumpulkan metrik dan mengevaluasi aturan alert — ia memicu alert ketika kondisi PromQL terus bernilai benar lebih lama dari durasi 'for' yang dikonfigurasi. AlertManager kemudian mengambil alih untuk menangani deduplikasi, pengelompokan, routing, pembungkaman, dan inhibisi sebelum mengirim notifikasi ke receiver seperti Telegram, Slack, atau PagerDuty. Pemisahan ini menjaga concern tetap bersih: Prometheus tahu apa yang salah, sementara AlertManager memutuskan siapa yang diberitahu dan bagaimana. Arsitektur ini juga memungkinkan beberapa instance Prometheus mengirimkan alert ke satu cluster AlertManager yang berkoordinasi di antara semuanya.

Bagaimana pengelompokan alert sebaiknya dikonfigurasi agar tidak terjadi banjir notifikasi?

Fitur pengelompokan AlertManager menggabungkan alert-alert yang berkaitan menjadi satu notifikasi, bukan mengirim satu pesan per alert. Mengonfigurasi 'group_by: [alertname, env, cluster]' dengan 'group_wait: 30s' dan 'group_interval: 5m' berarti AlertManager menunggu 30 detik untuk alert tambahan dalam grup yang sama sebelum mengirim, lalu mengirimkan alert baru yang terakumulasi setiap 5 menit. Sebagai contoh, ketika sebuah switch jaringan gagal dan membuat 20 server tidak dapat dijangkau, konfigurasi ini menghasilkan satu alert 'kegagalan jaringan memengaruhi 20 server' alih-alih 20 pesan 'server down' terpisah. Pendekatan ini telah mencegah beberapa badai alert menjadi banjir notifikasi bagi rotasi on-call.

Mengapa aturan alert harus selalu menyertakan durasi 'for', dan apa yang terjadi jika dihilangkan?

Tanpa durasi 'for', Prometheus langsung memicu alert begitu suatu kondisi bernilai benar — termasuk lonjakan sesaat yang bersifat sementara. Lonjakan CPU ke 95% selama 3 detik akan menghasilkan dua pesan Telegram (FIRING dan RESOLVED) sebelum siapa pun sempat menanganinya, menciptakan kebisingan yang melatih engineer untuk mengabaikan alert. Durasi 'for' berfungsi sebagai debounce, mengharuskan kondisi terus benar selama seluruh periode sebelum alert menyala. Titik awal yang baik adalah 'for: 5m' untuk saturasi resource, 'for: 1m' untuk alert layanan down, dan 'for: 15m' untuk alert berbasis tren.

Apa itu inhibition rule, dan kapan sebaiknya digunakan?

Inhibition rule menekan alert level rendah ketika alert level yang lebih tinggi sudah menyala, mencegah kebisingan cascading dari satu root cause yang sama. Contoh klasiknya adalah menekan semua alert 'layanan down' untuk layanan dalam sebuah cluster ketika alert 'cluster tidak dapat dijangkau' sudah aktif — layanan-layanan tersebut tampak down karena cluster tidak terjangkau, bukan karena kegagalan independen. Inhibition rule menggunakan 'source_matchers' dan 'target_matchers' dengan pencocokan label agar hanya alert yang tepat yang ditekan. Over-inhibisi adalah risiko nyata, sehingga pencocokan harus cukup presisi agar tidak menyembunyikan kegagalan independen yang sebenarnya.

Seperti apa alerting yang sudah tertuning dengan baik, dan bagaimana cara mengukurnya?

Setup Prometheus dan AlertManager yang tertuning dengan baik seharusnya menerima kurang dari 5 notifikasi alert per minggu selama operasi normal, setiap notifikasi dapat ditindaklanjuti dalam 10 menit, dan nol insiden 'produksi down dan tidak ada yang di-page'. Untuk mencapai standar ini diperlukan penulisan aturan alert yang menyala pada gejala daripada penyebab — misalnya alert pada 'HTTP 5xx rate above 1%' bukan 'CPU above 80%' — dikombinasikan dengan pengelompokan dan inhibisi yang agresif, serta sesi review kuartalan yang secara sengaja menghapus alert yang menyala tetapi tidak memerlukan tindakan.

Prometheus AlertManager: Cara Membangun Sistem Alert On-Call

Cara mengonfigurasi Prometheus AlertManager untuk alerting on-call produksi — routing tree, inhibition rule, pengelompokan, integrasi Telegram, dan setup high-availability.

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. Stack Prometheus + AlertManager dapat menghasilkan alert yang dapat ditindaklanjuti — bukan kebisingan — melalui desain aturan alert yang cermat dan konfigurasi routing AlertManager. Panduan ini mencakup apa yang benar-benar berfungsi di produksi, termasuk kesalahan konfigurasi AlertManager yang umum terjadi dan menyebabkan banjir alert serta 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.

Dari pengalaman saya: gunakan pengelompokan AlertManager secara agresif untuk mencegah banjir notifikasi. Ketika sebuah switch jaringan gagal dan 20 server menjadi tidak dapat dijangkau, Anda ingin satu alert ('kegagalan jaringan memengaruhi 20 server') bukan 20 alert 'server down' individual. Konfigurasikan group_by: [alertname, env, cluster] dan group_wait: 30s (tunggu 30 detik untuk lebih banyak alert dalam grup yang sama sebelum mengirim) dan group_interval: 5m (kirim alert baru yang terakumulasi setiap 5 menit setelah notifikasi awal). Pengelompokan ini telah mencegah beberapa badai alert menjadi banjir notifikasi untuk rotasi on-call kami.

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)             │
└──────────────────────────────────────────────────────┘

Di awal setup Prometheus saya, saya menulis aturan alert tanpa durasi for, yang berarti alert menyala segera ketika kondisi benar — bahkan untuk lonjakan metrik sesaat. Hasilnya adalah banjir alert yang menyala dan terselesaikan selama variasi traffic normal. Lonjakan CPU ke 95% selama 3 detik menyala dan terselesaikan sebelum siapa pun dapat melihatnya, tetapi menghasilkan dua pesan Telegram (FIRING dan RESOLVED) dan berkontribusi pada alert fatigue. Selalu atur durasi for yang sesuai dengan sifat alert: for: 5m untuk alert saturasi resource, for: 1m untuk alert layanan down, for: 15m untuk alert berbasis tren. Durasi for bertindak sebagai debounce — mengharuskan kondisi terus benar selama periode tersebut sebelum menyala.

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

Target yang masuk akal untuk alerting yang baik adalah: 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 diperlukan penulisan aturan alert yang menyala pada gejala daripada penyebab (alert pada 'HTTP 5xx rate above 1%' bukan 'CPU above 80%'), konfigurasi pengelompokan dan inhibisi yang agresif, dan sesi tinjauan alert triwulanan di mana Anda 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.

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