Peringatan Panggilan Telepon Prometheus Alertmanager: Bangun Hanya untuk yang Kritis

Alertmanager tidak punya receiver suara. Arahkan peringatan Prometheus ke panggilan telepon hanya untuk severity kritis: konfigurasi webhook, kondisi, dan jebakan Watchdog.

Diperbarui

Daftar Isi

Alertmanager tidak punya receiver suara. Untuk mendapat panggilan telepon saat sebuah peringatan Prometheus terpicu, tambahkan receiver webhook_configs yang mengarah ke saluran Echobell dengan jenis langganan Panggilan. Panduan ini membahas YAML persisnya, kondisi yang mencegah peringatan yang sudah pulih ikut menelepon Anda, perutean berdasarkan severity, dan peringatan Watchdog yang kalau dibiarkan akan membuat ponsel Anda berdering tiap empat jam selamanya.

Prometheus adalah tumpukan metrik bawaan bagi sebagian besar infrastruktur yang dibangun dalam satu dekade terakhir, dan Alertmanager memang benar-benar baik di bagian yang sulit: mendeduplikasi peringatan, mengelompokkannya, membisukannya saat pemeliharaan, dan menekan kebisingan hilir ketika sebuah dependensi hulu gagal.

Yang tidak akan ia lakukan adalah membangunkan siapa pun.

Mengapa Alertmanager tidak bisa membuat ponsel Anda berdering sendiri

Alertmanager menyediakan receiver untuk email, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams, dan belasan lainnya. Semuanya mengirimkan sebuah pesan, dan pesan tunduk pada sakelar dering, Do Not Disturb, serta Mode Fokus iOS. Pukul 03.00, itu berarti peringatannya datang dan tidak terjadi apa-apa.

Tidak ada voice_configs. Pilihan yang biasanya diambil orang adalah:

  • PagerDuty / OpsGenie / Splunk On-Call — ini memang bisa menelepon, dan semuanya platform manajemen insiden lengkap dengan harga per kursi yang setimpal. Jawaban yang tepat jika Anda butuh rotasi dan pohon eskalasi; berlebihan jika yang Anda butuhkan hanyalah ponsel yang berdering. (OpsGenie khususnya sedang dihentikan, dan itulah sebabnya begitu banyak tim mengevaluasi ulang lapisan ini sekarang.)
  • Jembatan SMS seperti Sachet — Anda menjalankan satu layanan lagi, membayar gateway per pesan, dan SMS pun tetap mendarat sebagai pesan. Di iOS, sebuah SMS tidak menembus Mode Fokus kecuali pengirimnya ada di daftar izin Anda.
  • Perekat berbasis Twilio — tulis receiver webhook kecil, beli sebuah nomor, bayar per panggilan, dan kini Anda memiliki sepotong infrastruktur produksi yang tugas satu-satunya adalah membuat ponsel berdering.

Receiver webhook generik adalah pintu keluarnya. Ia mengirim payload JSON yang terdokumentasi ke URL mana pun, dan itu sudah cukup.

Yang Anda butuhkan

  • Penyiapan Prometheus + Alertmanager yang sudah berjalan, dan akses untuk mengedit alertmanager.yml
  • Echobell terpasang (App Store / Google Play)
  • Sepuluh menit

Panduan ini ditulis berdasarkan Alertmanager 0.31. Payload webhook sudah berada di version: "4" selama bertahun-tahun, jadi rilis 0.2x berperilaku sama persis.

Alertmanager Anda butuh HTTPS keluar ke hook.echobell.one. Ia tidak perlu bisa dijangkau dari internet, jadi Alertmanager di dalam sebuah cluster, VPC, atau homelab pun berjalan baik.

Langkah 1 — Buat saluran yang menelepon Anda

Di Echobell, buat saluran bernama semisal Prometheus Critical. Setel jenis notifikasi langganannya ke Panggilan. Inilah pengaturan yang menentukan: peringatan bertipe Panggilan datang sebagai layar panggilan masuk dan berdering menembus Mode Fokus iOS dan Do Not Disturb, hal yang tidak bisa dilakukan notifikasi push.

Setel templatnya agar membaca payload Alertmanager secara langsung:

Title: 🔴 {{commonLabels.alertname}} on {{commonLabels.instance}}
Body: {{commonAnnotations.summary}}
{{commonAnnotations.description}}

Dan, di Pengaturan Lanjutan, sebuah Templat Tautan agar catatan notifikasinya langsung melompat ke grafik:

{{alerts[0].generatorURL}}

Lalu salin URL Webhook saluran tersebut:

https://hook.echobell.one/t/<channel-token>

Perlakukan URL itu sebagai rahasia — siapa pun yang memegangnya bisa membuat ponsel Anda berdering.

Langkah 2 — Tambahkan receiver webhook

Di alertmanager.yml:

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-critical

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false

Muat ulang dengan curl -X POST http://localhost:9093/-/reload atau SIGHUP.

Perhatikan send_resolved: false. Nilai bawaan untuk receiver webhook adalah true, berbeda dari kebanyakan receiver Alertmanager lain, jadi menghilangkannya berarti ponsel Anda berdering saat layanan rusak dan berdering lagi saat ia pulih sendiri. Panggilan kedua itulah yang melatih orang mengabaikan yang pertama. Langkah 4 menunjukkan cara mendapatkan kembali pemberitahuan pemulihan tanpa deringan.

Langkah 3 — Pahami apa yang sebenarnya datang

Alertmanager mengelompokkan peringatan, lalu mengirim satu payload POST per kelompok:

{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "echobell-critical",
  "groupLabels": { "alertname": "HighErrorRate" },
  "commonLabels": { "alertname": "HighErrorRate", "severity": "critical" },
  "commonAnnotations": { "summary": "Error rate above 5% for 10m" },
  "externalURL": "http://alertmanager.internal:9093",
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighErrorRate", "instance": "api-7d9f:8080" },
      "annotations": { "summary": "Error rate above 5% for 10m" },
      "startsAt": "2026-09-04T02:41:07.351Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "http://prometheus:9090/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f60718"
    }
  ]
}

Echobell membaca body JSON apa adanya, jadi setiap bidang di atas tersedia di templat dan kondisi. Akses bersarang bisa dengan salah satu sintaks — {{commonLabels.severity}} atau {{alerts[0].labels["instance"]}}.

Dua sifat payload ini menentukan semua hal di bawah:

status di tingkat teratas bernilai firing jika ada peringatan mana pun dalam kelompok itu yang sedang firing. Ia baru menjadi resolved setelah semua peringatan dalam kelompok tersebut pulih. Itu menjadikannya patokan yang bersih untuk menyaring.

commonLabels hanya memuat label yang sama-sama dimiliki setiap peringatan dalam kelompok. Inilah kejutan yang paling sering terjadi. Jika group_by cukup luas sehingga satu webhook membawa HighErrorRate dari tiga instance berbeda, maka commonLabels.instance tidak ada dan {{commonLabels.instance}} dirender sebagai string kosong. Cara menanganinya dibahas lebih lanjut di bawah.

Langkah 4 — Kirim pemulihan sebagai push yang tenang

Anda tetap ingin tahu ketika sesuatu pulih — Anda hanya tidak ingin ditelepon soal itu. Tambahkan saluran Echobell kedua bernama Prometheus Recovered, setel jenis notifikasinya ke Normal, lalu beri templat berikut:

Title: ✅ {{commonLabels.alertname}} resolved
Body: {{commonAnnotations.summary}}

dan, di Pengaturan Lanjutan, kondisi ini:

status == "resolved"

Kondisi adalah ekspresi yang dievaluasi sebelum apa pun dikirim. Jika ekspresinya bernilai salah, Echobell menerima permintaannya dan tidak mengirim apa-apa.

Lalu arahkan receiver yang sama ke kedua saluran — satu receiver bisa memuat beberapa webhook_configs:

receivers:
  - name: echobell-critical
    webhook_configs:
      # Membuat ponsel berdering. Hanya saat firing.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # Push yang tenang. Kondisi saluran membuang paruh firing-nya.
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true

Saluran pemulihan menerima payload firing maupun resolved lalu membuang yang firing. Hasilnya: gangguan membuat ponsel berdering, pemulihan datang sebagai push yang Anda baca pagi hari.

Langkah 5 — Rutekan berdasarkan severity, bukan berdasarkan segalanya

Rute tangkap-semua yang mengirim setiap peringatan ke saluran panggilan adalah mesin penghasil panggilan telepon yang diabaikan. Pisahkan berdasarkan severity di Alertmanager, tempat pohon perutean memang seharusnya berada:

route:
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: echobell-warning

  routes:
    # Watchdog tidak pernah sampai ke manusia. Lihat Langkah 6.
    - matchers:
        - alertname = "Watchdog"
      receiver: "null"

    - matchers:
        - severity = "critical"
      receiver: echobell-critical
      group_wait: 10s
      repeat_interval: 1h

receivers:
  - name: "null"

  - name: echobell-critical
    webhook_configs:
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false

  - name: echobell-warning
    webhook_configs:
      - url: "https://hook.echobell.one/t/<normal-channel-token>"
        send_resolved: true

Rute dievaluasi dari atas ke bawah dan kecocokan pertama yang menang — continue bernilai bawaan false. Jadi urutannya penting: rute Watchdog harus berada di atas apa pun yang jika tidak akan menelannya.

Jika Anda lebih suka memakai satu saluran dan menyaring di sisi Echobell, kondisi setaranya adalah:

status == "firing" && commonLabels.severity == "critical"

Melakukannya di Alertmanager biasanya lebih baik, karena severity di sana juga menentukan group_wait dan repeat_interval. Melakukannya di Echobell lebih baik ketika Anda tidak bisa membuat perubahan konfigurasi disetujui hari ini.

Langkah 6 — Jebakan Watchdog

Jika Anda menjalankan kube-prometheus-stack, Anda punya sebuah peringatan bernama Watchdog yang ekspresinya vector(1). Ia memang dirancang untuk terus firing selamanya — keberadaannya agar sistem eksternal bisa menyadari saat Prometheus sendiri berhenti. Konfigurasi bawaan mengarahkannya ke receiver null.

Arahkan rute tangkap-semua ke saluran panggilan tanpa mengecualikannya, dan Watchdog akan menelepon ponsel Anda setiap repeat_interval, selamanya, mulai saat itu juga. Inilah penyebab nomor satu orang menyimpulkan bahwa peringatan lewat telepon "tidak berhasil".

Pertahankan rute null dari Langkah 5. Lalu, bila mau, lakukan hal yang berguna dengannya: ubah Watchdog menjadi dead man's switch yang sungguhan.

    - matchers:
        - alertname = "Watchdog"
      receiver: deadmansswitch
      group_wait: 0s
      group_interval: 1m
      repeat_interval: 50s

receivers:
  - name: deadmansswitch
    webhook_configs:
      - url: "https://hc-ping.com/<your-check-uuid>"
        send_resolved: false

Echobell tidak bisa menjadi dead man's switch itu sendiri — ia memberi peringatan ketika sebuah permintaan datang, bukan ketika permintaan berhenti datang. Jadi kirim ping Watchdog ke layanan yang memang dibangun untuk mendeteksi kesunyian (Healthchecks.io, Cronitor, Dead Man's Snitch), lalu arahkan webhook "check went down" dari layanan itu ke saluran panggilan Echobell Anda. Kini sebuah panggilan telepon berarti "sistem pemantauannya sendiri mati", yaitu satu peringatan yang paling ingin Anda dengar dan paling jarang dikonfigurasi orang.

Menyetel agar ia tidak "mengaku ada serigala"

Tiga pengaturan Alertmanager melakukan sebagian besar pekerjaannya, ditambah satu di Prometheus:

PengaturanDi manaFungsinya
for:Aturan peringatanBerapa lama kondisinya harus bertahan sebelum ia firing sama sekali. Garis pertahanan pertama Anda terhadap gangguan dua detik.
group_waitRuteBerapa lama menunggu peringatan lain sebelum notifikasi pertama. Bawaannya 30s; turunkan ke 10s untuk yang kritis.
group_intervalRuteJeda minimum sebelum notifikasi tentang peringatan baru dalam kelompok yang sudah ada. Bawaannya 5m.
repeat_intervalRuteSeberapa sering peringatan yang belum pulih diberitahukan ulang. Bawaannya 4h — jadi gangguan tengah malam menelepon Anda pukul 03.00 dan lagi pukul 07.00.

repeat_interval adalah yang layak dipikirkan. Empat jam terlalu lama untuk membiarkan sesuatu rusak; dua puluh menit adalah mesin yang membuat Anda menonaktifkan salurannya. Satu jam untuk yang kritis adalah titik awal yang masuk akal.

Jika Anda ingin panggilan yang tak terjawab langsung dicoba ulang alih-alih menunggu repeat_interval berikutnya, aktifkan Coba Ulang Panggilan Gagal di pengaturan aplikasi Echobell.

Hanya berdering di luar jam kerja

Saat jam kerja, Anda mungkin sudah menatap dasbor. Variabel waktu sistem Echobell (semuanya UTC) memungkinkan sebuah saluran berperilaku berbeda menurut jam, tanpa perlu rute Alertmanager kedua:

status == "firing" && (hour >= 17 || hour < 9)

Itu menelepon Anda hanya di luar pukul 09.00–17.00 UTC. Arahkan saluran kedua bertipe Normal ke kebalikannya untuk push di siang hari:

status == "firing" && hour >= 9 && hour < 17

Tambahkan dayOfWeek >= 1 && dayOfWeek <= 5 untuk memperlakukan akhir pekan sebagai di luar jam kerja juga. Ingat bahwa semuanya selalu dihitung dalam UTC — sesuaikan dengan zona waktu Anda sendiri. Pembahasan lebih lengkap ada di notifikasi jendela waktu memakai kondisi UTC.

Menangani masalah commonLabels yang kosong

Ketika sebuah kelompok memuat peringatan dari beberapa instance, commonLabels.instance menghilang dan judul notifikasi Anda berbunyi 🔴 HighErrorRate on .

Tiga jalan keluar, berurutan sesuai preferensi:

  1. Masukkan labelnya ke group_by. Jika group_by menyertakan instance, maka setiap peringatan dalam satu kelompok memilikinya dan commonLabels.instance selalu ada. Biayanya: notifikasi jadi lebih banyak — satu per instance alih-alih satu per nama peringatan.
  2. Baca peringatan pertama saja. {{alerts[0].labels.instance}} selalu terisi. Ia hanya salah satu dari kemungkinan banyak, jadi padukan dengan jumlahnya: {{alerts[0].labels.instance}} (+{{alerts.length}} alerts).
  3. Rancang labelnya agar tetap terbaca saat kosong. Echobell tidak punya operator nilai bawaan — {{a || "unknown"}} merender teks harfiah true, bukan nilai cadangan — jadi tulis Instance: {{commonLabels.instance}} di barisnya sendiri, di mana nilai kosong jelas terlihat kosong alih-alih menjadi kalimat yang rusak.

Menjaga payload tetap kecil

Sebuah kelompok yang mencakup seratus pod menghasilkan body JSON yang besar, dan Echobell menolak body pemicu di atas 1 MiB dengan HTTP 413. Batasi di Alertmanager:

      - url: "https://hook.echobell.one/t/<channel-token>"
        send_resolved: false
        max_alerts: 20

Alertmanager lalu mengirim paling banyak dua puluh peringatan dan menyetel truncatedAlerts ke jumlah yang ia buang, yang bisa Anda tampilkan di isi pesan:

Body: {{commonAnnotations.summary}}
Alerts: {{alerts.length}} (+{{truncatedAlerts}} truncated)

Membagikan peringatannya ke tim Anda

Saluran Echobell bisa dibagikan lewat tautan langganan, dan setiap pelanggan memilih jenis notifikasinya sendiri. Karena itu, rute yang sama bisa menelepon insinyur on-call sekaligus mendarat sebagai push biasa bagi semua orang lain — tanpa harga per kursi, dan tanpa aturan perutean tambahan di Alertmanager.

Ini juga selaras dengan alasan banyak tim meng-host Prometheus sendiri sejak awal: metrik dan aturan peringatan Anda tetap berada di infrastruktur Anda, dan Echobell menyimpan isi serta riwayat notifikasi di perangkat, bukan di servernya.

Yang tidak diberikan penyiapan ini

Berterus terang soal batasannya menyelamatkan Anda dari migrasi yang buruk kelak. Echobell adalah lapisan pengiriman, bukan platform manajemen insiden. Ia tidak punya:

  • Jadwal rotasi on-call atau serah terima follow-the-sun
  • Pohon eskalasi yang memanggil orang kedua ketika yang pertama tidak menjawab
  • Linimasa insiden, pelacakan pengakuan, atau perkakas postmortem

Jika tim Anda membutuhkannya, Anda butuh PagerDuty, Grafana Cloud IRM, atau sejenisnya. Yang dicakup panduan ini adalah celah spesifik yang ditinggalkan Alertmanager: mengubah peringatan yang firing menjadi ponsel yang benar-benar berdering. Bagi operator perorangan, tim kecil, dan homelab, biasanya itulah seluruh kebutuhannya.

Pemecahan masalah

Tidak ada apa pun yang datang. Periksa dulu log Alertmanager sendiri (level=error component=dispatcher), lalu pastikan rutenya memang mengarah ke receiver Anda — amtool config routes test severity=critical alertname=HighErrorRate memberi tahu receiver mana yang akan menerima sebuah peringatan tanpa perlu menunggu ada yang firing.

Echobell mengembalikan HTTP 404. Token salurannya salah atau salurannya sudah dihapus. Token yang tidak dikenal menghasilkan 404, bukan keberhasilan senyap.

Echobell mengembalikan 200 dengan "notificationTriggered": false. Kondisi Anda bernilai salah. Body responsnya juga memuat "conditionsMet": false, yang merupakan cara tercepat membedakan "kondisi saya salah" dari "webhook saya tidak pernah sampai". Periksa status == "firing" terhadap apa yang benar-benar dikirim Alertmanager — status di tingkat teratas, bukan alerts[0].status.

HTTP 413. Payload melampaui 1 MiB. Setel max_alerts seperti di atas.

HTTP 405. Saluran mengaktifkan POST Only dan ada yang mengirim GET. Alertmanager memakai POST, jadi ini biasanya berarti Anda menguji URL-nya di peramban.

Judulnya punya celah kosong. commonLabels tidak memuat label itu untuk kelompok ini. Lihat bagian di atas.

Tidak ada dering, tetapi notifikasinya datang. Jenis notifikasi langganannya Normal atau Peka Waktu, bukan Panggilan. Jenis notifikasi dipilih per pelanggan, jadi periksa di perangkat yang tidak berdering.

Menguji tanpa merusak produksi. Tambahkan aturan dengan expr: vector(1), alertname yang khas, dan severity: critical, biarkan firing sekali, lalu hapus. Atau picu satu secara manual:

curl -X POST http://localhost:9093/api/v2/alerts -H 'Content-Type: application/json' -d '[
  {"labels":{"alertname":"EchobellTest","severity":"critical"},
   "annotations":{"summary":"Testing the phone call path"}}
]'

Pertanyaan yang sering diajukan

Bisakah Prometheus Alertmanager melakukan panggilan telepon secara bawaan?

Tidak. Alertmanager punya receiver untuk email, Slack, PagerDuty, OpsGenie, dan banyak lainnya, tetapi tidak ada receiver suara atau SMS. Panggilan telepon menuntut Anda mengarahkan receiver webhook generik ke layanan yang bisa melakukannya, seperti Echobell, atau membayar platform manajemen insiden.

Apakah panggilannya menembus Do Not Disturb?

Ya. Jenis notifikasi Panggilan di Echobell tampil sebagai panggilan masuk, yang berdering menembus Mode Fokus iOS dan Do Not Disturb. Lihat menembus Mode Fokus iOS untuk peringatan kritis untuk detail dan pengaturan yang terlibat.

Apakah ini berfungsi dengan Alertmanager di balik firewall atau di dalam Kubernetes?

Ya. Webhook-nya adalah permintaan HTTPS keluar dari Alertmanager, jadi ia hanya perlu menjangkau hook.echobell.one. Alertmanager Anda tidak perlu alamat publik atau ingress.

Bagaimana cara berhenti ditelepon saat sebuah peringatan pulih?

Setel send_resolved: false pada konfigurasi webhook yang mengarah ke saluran panggilan Anda. Receiver webhook bernilai bawaan true, berbeda dari kebanyakan receiver Alertmanager lain, jadi ini bersifat opt-out, bukan opt-in. Untuk tetap menerima kabar pemulihan secara tenang, tambahkan saluran kedua dengan kondisi status == "resolved".

Mengapa ponsel saya berdering tiap empat jam untuk peringatan yang sama?

Itu repeat_interval, yang bawaannya 4h. Alertmanager memberitahukan ulang peringatan yang masih firing pada irama itu. Setel per rute — 1h untuk yang kritis adalah pilihan yang lazim. Jika panggilannya mulai muncul segera setelah Anda menambahkan rute tangkap-semua, biang keroknya lebih mungkin peringatan Watchdog yang selalu firing; lihat Langkah 6.

Bisakah beberapa orang ditelepon untuk peringatan yang sama?

Bisa. Bagikan salurannya ke rekan tim dan setiap pelanggan memilih jenis notifikasinya sendiri. Semua yang berlangganan saluran panggilan akan ditelepon, tanpa biaya per kursi.

Sebaiknya saya menyaring severity di Alertmanager atau di kondisi Echobell?

Utamakan Alertmanager: perutean di sana juga memungkinkan Anda menyetel group_wait dan repeat_interval per severity, dan pohon perutean tetap tersimpan di kontrol versi bersama konfigurasi lain Anda. Pakai kondisi Echobell ketika Anda tidak bisa mengubah konfigurasi Alertmanager, atau untuk penyaringan yang tidak dikenal Alertmanager — seperti waktu dalam sehari.

Penutup

Penyiapannya terdiri dari satu receiver, satu send_resolved: false, dan pohon perutean yang menjauhkan segala hal selain severity: critical dari saluran panggilan. Ia membiarkan aturan peringatan, pengelompokan, pembisuan, dan penekanan Anda persis seperti sedia kala, sekaligus menutup celah antara "Prometheus menyadarinya" dan "seorang manusia menyadarinya".

Unduh Echobell untuk iPhone atau dapatkan di Google Play, lalu picu peringatan EchobellTest di atas sebelum Anda mengandalkan jalur ini untuk hal yang sungguhan.

Terkait

Artikel terkait

Peringatan Panggilan Telepon Uptime Kuma: Buat Ponsel Anda Berdering

Uptime Kuma punya 90+ penyedia notifikasi, tetapi tak satu pun membuat ponsel Anda berdering. Ini cara menambahkan peringatan panggilan telepon untuk downtime memakai satu webhook.

Baca selengkapnya

Agen AI Anda Sedang Menunggu Anda: Ubah Gerbang Persetujuan Jadi Panggilan Telepon

Agen otonom berhenti dan menunggu tanpa suara ketika butuh manusia. Tidak ada satu pun bagian dari tumpukan agen yang membuat ponsel Anda berdering. Begini cara menyambungkan gerbang persetujuan agen dan run yang gagal ke panggilan sungguhan dengan Echobell.

Baca selengkapnya

Terima Peringatan TradingView sebagai Panggilan Telepon dengan Echobell

Hubungkan TradingView ke Echobell lewat webhook untuk menerima peringatan harga sebagai panggilan telepon atau notifikasi peka waktu, dengan isi suara yang bisa disesuaikan.

Baca selengkapnya