Alerty telefoniczne z Prometheus Alertmanagera: budzą tylko przy krytycznych

Spis treści

• Dlaczego Alertmanager sam nie zadzwoni na Twój telefon
• Czego potrzebujesz
• Krok 1 — utwórz kanał, który do Ciebie dzwoni
• Krok 2 — dodaj odbiorcę webhook
• Krok 3 — zrozum, co właściwie przychodzi
• Krok 4 — wysyłaj powroty do normy jako ciche powiadomienia
• Krok 5 — kieruj według wagi, a nie po wszystkim
• Krok 6 — pułapka Watchdog
• Strojenie, żeby nie wołało wilka
• Dzwoń tylko poza godzinami pracy
• Radzenie sobie z pustym commonLabels
• Utrzymywanie małego payloadu
• Dzielenie alertu z zespołem
• Czego ta konfiguracja nie daje
• Rozwiązywanie problemów
• Najczęściej zadawane pytania
• Czy Prometheus Alertmanager potrafi sam zadzwonić na telefon?
• Czy połączenie ominie tryb Nie przeszkadzać?
• Czy to działa z Alertmanagerem za zaporą albo wewnątrz Kubernetes?
• Jak przestać dostawać telefony, gdy alert zostaje rozwiązany?
• Dlaczego mój telefon dzwoni co cztery godziny w sprawie tego samego alertu?
• Czy kilka osób może dostać telefon o tym samym alercie?
• Filtrować wagę w Alertmanagerze czy w warunkach Echobell?
• Podsumowanie
• Powiązane

Alertmanager nie ma odbiorcy głosowego. Aby dostać telefon, gdy uruchomi się alert Prometheusa, dodaj odbiorcę webhook_configs wskazujący na kanał Echobell, którego typ subskrypcji to Calling. Ten przewodnik pokazuje dokładny YAML, warunek, który powstrzyma dzwonienie przy alertach rozwiązanych, kierowanie według wagi oraz alert Watchdog, który inaczej będzie dzwonił na Twój telefon co cztery godziny bez końca.

Prometheus to domyślny stos metryk w większości infrastruktury budowanej w ostatniej dekadzie, a Alertmanager naprawdę dobrze radzi sobie z trudnymi częściami: deduplikacją alertów, ich grupowaniem, wyciszaniem na czas prac serwisowych i tłumieniem szumu, gdy zawiedzie zależność wyżej w łańcuchu.

Czego nie zrobi, to nikogo nie obudzi.

Dlaczego Alertmanager sam nie zadzwoni na Twój telefon

Alertmanager ma odbiorców dla poczty, Slacka, PagerDuty, OpsGenie, Discorda, Telegrama, Pushover, Webex, MS Teams i kilkunastu innych. Każdy z nich dostarcza wiadomość, a wiadomości podlegają przełącznikowi dzwonka, trybowi Nie przeszkadzać i trybom Skupienia w iOS. O 03:00 oznacza to, że alert przychodzi i nic się nie dzieje.

Nie ma czegoś takiego jak voice_configs. Zwykle ludzie lądują na tych opcjach:

• PagerDuty / OpsGenie / Splunk On-Call — te faktycznie dzwonią, ale są pełnymi platformami zarządzania incydentami z odpowiadającym temu cennikiem za stanowisko. Właściwy wybór, gdy potrzebujesz rotacji i drzew eskalacji; przesada, gdy chcesz tylko, aby telefon zadzwonił. (Szczególnie OpsGenie jest wygaszane, dlatego tak wiele zespołów właśnie teraz przegląda tę warstwę na nowo.)
• Mostki SMS w rodzaju Sachet — uruchamiasz kolejną usługę, płacisz bramce za każdą wiadomość, a SMS i tak ląduje jako wiadomość. Na iOS SMS nie przebija się przez tryb Skupienia, o ile nadawcy nie masz na liście dozwolonych.
• Własna warstwa na Twilio — piszesz mały odbiornik webhooków, kupujesz numer, płacisz za każde połączenie i nagle utrzymujesz kawałek produkcyjnej infrastruktury, której jedynym zadaniem jest sprawić, by telefon zadzwonił.

Wyjściem awaryjnym jest ogólny odbiorca webhook. Wysyła udokumentowany payload JSON pod dowolny adres URL, a to wszystko, czego potrzebujesz.

Czego potrzebujesz

• Działającego zestawu Prometheus + Alertmanager i możliwości edycji alertmanager.yml
• Zainstalowanego Echobell (App Store / Google Play)
• Dziesięciu minut

Ten przewodnik powstał dla Alertmanagera 0.31. Payload webhooka od lat ma version: "4", więc wydania 0.2x zachowują się identycznie.

Twój Alertmanager potrzebuje wychodzącego HTTPS do hook.echobell.one. Nie musi być osiągalny z internetu, więc Alertmanager w klastrze, w VPC albo w domowej serwerowni sprawdzi się bez problemu.

Krok 1 — utwórz kanał, który do Ciebie dzwoni

W Echobell utwórz kanał o nazwie w rodzaju Prometheus Critical. Ustaw typ powiadomienia jego subskrypcji na Calling. To ustawienie ma tu kluczowe znaczenie: alerty Calling pojawiają się jako ekran połączenia przychodzącego i dzwonią mimo trybu Skupienia w iOS oraz trybu Nie przeszkadzać, czego powiadomienie push nie robi.

Ustaw szablony tak, aby czytały payload Alertmanagera wprost:

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

A w ustawieniach zaawansowanych ustaw szablon odnośnika, aby wpis powiadomienia prowadził prosto do wykresu:

{{alerts[0].generatorURL}}

Następnie skopiuj adres URL webhooka kanału:

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

Traktuj ten adres jak sekret — każdy, kto go ma, może sprawić, że Twój telefon zadzwoni.

Krok 2 — dodaj odbiorcę webhook

W 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

Przeładuj konfigurację poleceniem curl -X POST http://localhost:9093/-/reload albo sygnałem SIGHUP.

Zwróć uwagę na send_resolved: false. Domyślną wartością dla odbiorcy webhook jest true, inaczej niż u większości pozostałych odbiorców Alertmanagera, więc pominięcie tej opcji oznacza, że telefon zadzwoni, gdy usługa się zepsuje, oraz zadzwoni ponownie, gdy sama się naprawi. To ten drugi telefon uczy ludzi ignorowania pierwszego. Krok 4 pokazuje, jak odzyskać powiadomienie o powrocie do normy bez dzwonienia.

Krok 3 — zrozum, co właściwie przychodzi

Alertmanager grupuje alerty, a następnie wysyła jeden payload na grupę:

{
  "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 czyta treść JSON w takiej postaci, w jakiej przyszła, więc każde z tych pól jest dostępne w szablonach i warunkach. Zagnieżdżony dostęp działa w obu składniach — {{commonLabels.severity}} albo {{alerts[0].labels["instance"]}}.

Wszystko poniżej wynika z dwóch właściwości tego payloadu:

Pole status na najwyższym poziomie ma wartość firing, jeśli którykolwiek alert w grupie jest aktywny. Zmienia się na resolved dopiero wtedy, gdy rozwiążą się wszystkie alerty w grupie. To czyni je wygodnym kryterium filtrowania.

commonLabels zawiera wyłącznie etykiety wspólne dla każdego alertu w grupie. To najczęstsza niespodzianka. Jeśli group_by jest na tyle szerokie, że jeden webhook niesie HighErrorRate z trzech różnych instancji, to commonLabels.instance nie występuje, a {{commonLabels.instance}} renderuje się jako pusty ciąg. Jak sobie z tym radzić — piszemy dalej.

Krok 4 — wysyłaj powroty do normy jako ciche powiadomienia

Nadal chcesz wiedzieć, że coś wróciło do normy — po prostu nie chcesz, aby Ci o tym dzwoniono. Dodaj drugi kanał Echobell o nazwie Prometheus Recovered, ustaw jego typ powiadomienia na Normal i nadaj mu takie szablony:

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

oraz, w ustawieniach zaawansowanych, taki warunek:

status == "resolved"

Warunki to wyrażenia obliczane przed jakimkolwiek dostarczeniem. Jeśli wyrażenie jest fałszywe, Echobell przyjmuje żądanie i nic nie wysyła.

Następnie skieruj tego samego odbiorcę na oba kanały — jeden odbiorca może zawierać kilka wpisów webhook_configs:

receivers:
  - name: echobell-critical
    webhook_configs:
      # Dzwoni na telefon. Tylko alerty aktywne.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # Ciche powiadomienie. Warunek kanału odrzuca połowę z alertami aktywnymi.
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true

Kanał powrotów do normy dostaje payloady zarówno aktywne, jak i rozwiązane, i odrzuca te aktywne. Efekt: awaria dzwoni, a powrót do normy przychodzi jako powiadomienie, które przeczytasz rano.

Krok 5 — kieruj według wagi, a nie po wszystkim

Reguła zbiorcza wysyłająca każdy alert do kanału dzwoniącego to maszyna do produkowania ignorowanych telefonów. Rozdziel alerty według wagi w Alertmanagerze, bo tam należy drzewo kierowania:

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

  routes:
    # Watchdog nigdy nie dociera do człowieka. Zobacz krok 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

Reguły są sprawdzane od góry do dołu i wygrywa pierwsze dopasowanie — continue domyślnie ma wartość false. Kolejność ma więc znaczenie: reguła Watchdog musi stać powyżej wszystkiego, co inaczej by ją pochłonęło.

Jeśli wolisz zostać przy jednym kanale i filtrować po stronie Echobell, równoważny warunek brzmi:

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

Zwykle lepiej zrobić to w Alertmanagerze, bo severity steruje wtedy również group_wait i repeat_interval. W Echobell jest lepiej wtedy, gdy nie zdołasz dziś wprowadzić zmiany w konfiguracji.

Krok 6 — pułapka Watchdog

Jeśli korzystasz z kube-prometheus-stack, masz alert o nazwie Watchdog, którego wyrażenie to vector(1). Jest zaprojektowany tak, aby być aktywnym bez końca — istnieje po to, by zewnętrzny system zauważył, że sam Prometheus przestał działać. Domyślna konfiguracja kieruje go do odbiorcy null.

Skieruj regułę zbiorczą na kanał dzwoniący bez wykluczenia go, a Watchdog będzie dzwonił na Twój telefon co repeat_interval, bez końca, od razu. To sposób numer jeden, w jaki ludzie dochodzą do wniosku, że alerty telefoniczne „nie działają".

Zachowaj regułę null z kroku 5. Potem, opcjonalnie, zrób z niej coś pożytecznego: zamień Watchdog w prawdziwego czuwaka.

    - 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 sam nie może być czuwakiem — alarmuje, gdy żądanie przychodzi, a nie gdy przestaje przychodzić. Wysyłaj więc ping z Watchdoga do usługi zbudowanej do wykrywania ciszy (Healthchecks.io, Cronitor, Dead Man's Snitch), a następnie skieruj webhook „kontrola przestała odpowiadać" tej usługi na swój dzwoniący kanał Echobell. Wtedy połączenie telefoniczne oznacza „padł sam monitoring", czyli ten jeden alert, przy którym najbardziej chcesz zostać obudzony, a którego nikt nie konfiguruje.

Strojenie, żeby nie wołało wilka

Najwięcej pracy wykonują trzy ustawienia Alertmanagera i jedno Prometheusa:

Nad repeat_interval warto się zastanowić. Cztery godziny to długo, aby zostawić coś zepsutego; dwadzieścia minut to prosta droga do wyłączenia kanału. Jedna godzina przy alertach krytycznych to rozsądny punkt wyjścia.

Jeśli chcesz, aby nieodebrane połączenie było ponawiane od razu, zamiast czekać na kolejny repeat_interval, włącz ponawianie nieudanych połączeń w ustawieniach aplikacji Echobell.

Dzwoń tylko poza godzinami pracy

W ciągu dnia pracy prawdopodobnie i tak patrzysz na dashboard. Systemowe zmienne czasu w Echobell (wszystkie w UTC) pozwalają kanałowi zachowywać się różnie w zależności od godziny, bez drugiej reguły kierowania w Alertmanagerze:

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

Taki warunek dzwoni tylko poza przedziałem 09:00–17:00 UTC. Skieruj drugi kanał typu Normal na warunek odwrotny, aby w dzień dostawać powiadomienia push:

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

Dodaj dayOfWeek >= 1 && dayOfWeek <= 5, aby weekendy też traktować jako czas poza godzinami pracy. Pamiętaj, że wartości te są zawsze liczone w UTC — przelicz je na swoją strefę czasową. Pełniejsze omówienie znajdziesz w tekście o powiadomieniach w oknach czasowych z warunkami UTC.

Radzenie sobie z pustym commonLabels

Gdy grupa zawiera alerty z kilku instancji, commonLabels.instance znika, a tytuł powiadomienia brzmi 🔴 HighErrorRate on .

Są trzy wyjścia, w kolejności od najlepszego:

1. Wstaw etykietę do group_by. Jeśli group_by zawiera instance, każdy alert w grupie ją współdzieli i commonLabels.instance jest zawsze obecne. Ceną jest więcej powiadomień — jedno na instancję zamiast jednego na nazwę alertu.
2. Czytaj zamiast tego pierwszy alert. {{alerts[0].labels.instance}} jest zawsze wypełnione. To tylko jeden z być może wielu alertów, więc połącz to z licznikiem: {{alerts[0].labels.instance}} (+{{alerts.length}} alerts).
3. Zaprojektuj etykietę tak, aby pusta wartość też się czytała. Echobell nie ma operatora wartości domyślnej — {{a || "unknown"}} wyrenderuje dosłowny tekst true, a nie wartość zastępczą — więc napisz Instance: {{commonLabels.instance}} w osobnej linii, gdzie pusta wartość jest po prostu widocznie pusta, a nie urwanym zdaniem.

Utrzymywanie małego payloadu

Grupa obejmująca sto podów daje sporą treść JSON, a Echobell odrzuca treści wyzwalaczy powyżej 1 MiB kodem HTTP 413. Ogranicz ją w Alertmanagerze:

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

Alertmanager wyśle wtedy najwyżej dwadzieścia alertów i ustawi truncatedAlerts na liczbę pominiętych, którą możesz pokazać w treści:

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

Dzielenie alertu z zespołem

Kanał Echobell można udostępnić linkiem subskrypcji, a każdy subskrybent wybiera własny typ powiadomienia. Ta sama reguła kierowania może więc dzwonić do osoby na dyżurze, a u pozostałych lądować jako zwykłe powiadomienie push — bez opłat za stanowisko i bez dodatkowych reguł kierowania w Alertmanagerze.

Pasuje to też do powodu, dla którego wiele zespołów w ogóle hostuje Prometheusa u siebie: Twoje metryki i reguły alertowania zostają w Twojej infrastrukturze, a Echobell trzyma treść i historię powiadomień na urządzeniu, a nie na swoich serwerach.

Czego ta konfiguracja nie daje

Uczciwość co do granic oszczędza późniejszej nieudanej migracji. Echobell jest warstwą dostarczania, a nie platformą zarządzania incydentami. Nie ma:

• grafików rotacyjnych dyżurów ani przekazywania zmian w modelu follow-the-sun,
• drzew eskalacji wywołujących drugą osobę, gdy pierwsza nie odbierze,
• osi czasu incydentów, śledzenia potwierdzeń ani narzędzi do analiz poincydentalnych.

Jeśli Twój zespół tego potrzebuje, potrzebujesz PagerDuty, Grafana Cloud IRM albo czegoś podobnego. To, co opisujemy, zamyka konkretną lukę zostawioną przez Alertmanagera: zamianę aktywnego alertu w telefon, który naprawdę dzwoni. Dla osób pracujących samodzielnie, małych zespołów i domowych serwerowni zwykle to całe wymaganie.

Rozwiązywanie problemów

Nic nie przychodzi. Sprawdź najpierw własne logi Alertmanagera (level=error component=dispatcher), a potem upewnij się, że reguła kierowania faktycznie prowadzi do Twojego odbiorcy — amtool config routes test severity=critical alertname=HighErrorRate powie Ci, u którego odbiorcy wylądowałby alert, bez czekania na prawdziwy.

Echobell zwraca HTTP 404. Token kanału jest błędny albo kanał został usunięty. Nieznany token daje 404, a nie ciche powodzenie.

Echobell zwraca 200 z "notificationTriggered": false. Twój warunek dał wynik fałszywy. Treść odpowiedzi zawiera też "conditionsMet": false, co najszybciej odróżnia „mam zły warunek" od „mój webhook nigdy nie dotarł". Porównaj status == "firing" z tym, co faktycznie wysłał Alertmanager — chodzi o status najwyższego poziomu, a nie alerts[0].status.

HTTP 413. Payload przekroczył 1 MiB. Ustaw max_alerts, jak wyżej.

HTTP 405. Kanał ma włączone POST Only, a coś wysłało żądanie GET. Alertmanager używa POST, więc zwykle oznacza to, że adres URL został przetestowany w przeglądarce.

W tytule jest pusta luka. commonLabels nie zawierało tej etykiety dla danej grupy. Zobacz sekcję powyżej.

Nic nie dzwoni, ale powiadomienie przychodzi. Typ powiadomienia w subskrypcji to Normal albo Time Sensitive, a nie Calling. Typ powiadomienia wybiera każdy subskrybent osobno, więc sprawdź go na tym urządzeniu, które nie dzwoni.

Testowanie bez psucia produkcji. Dodaj regułę z expr: vector(1), odrębną nazwą alertname i severity: critical, pozwól jej raz się uruchomić, a potem ją usuń. Albo wywołaj alert ręcznie:

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"}}
]'

Najczęściej zadawane pytania

Czy Prometheus Alertmanager potrafi sam zadzwonić na telefon?

Nie. Alertmanager ma odbiorców dla poczty, Slacka, PagerDuty, OpsGenie i wielu innych, ale nie ma odbiorcy głosowego ani SMS. Połączenia telefoniczne wymagają skierowania ogólnego odbiorcy webhook do usługi, która potrafi je wykonać, takiej jak Echobell, albo opłacenia platformy zarządzania incydentami.

Czy połączenie ominie tryb Nie przeszkadzać?

Tak. Typ powiadomienia Calling w Echobell pojawia się jako połączenie przychodzące, które dzwoni mimo trybu Skupienia w iOS i trybu Nie przeszkadzać. Szczegóły i potrzebne ustawienia opisuje tekst o omijaniu trybu Skupienia w iOS przy krytycznych alertach.

Czy to działa z Alertmanagerem za zaporą albo wewnątrz Kubernetes?

Tak. Webhook to wychodzące żądanie HTTPS z Alertmanagera, więc musi on jedynie dosięgnąć hook.echobell.one. Twój Alertmanager nie potrzebuje publicznego adresu ani ingressu.

Jak przestać dostawać telefony, gdy alert zostaje rozwiązany?

Ustaw send_resolved: false w konfiguracji webhooka wskazującej na Twój dzwoniący kanał. Odbiorca webhook domyślnie ma true, inaczej niż większość pozostałych odbiorców Alertmanagera, więc jest to rezygnacja, a nie zapisanie się. Aby nadal po cichu dostawać powroty do normy, dodaj drugi kanał z warunkiem status == "resolved".

Dlaczego mój telefon dzwoni co cztery godziny w sprawie tego samego alertu?

To repeat_interval, którego wartość domyślna to 4h. Alertmanager powiadamia w takim rytmie o wciąż aktywnym alercie. Ustaw go osobno dla każdej reguły — 1h przy alertach krytycznych to częsty wybór. Jeśli telefony zaczęły się od razu po dodaniu reguły zbiorczej, winowajcą jest raczej stale aktywny alert Watchdog; zobacz krok 6.

Czy kilka osób może dostać telefon o tym samym alercie?

Tak. Udostępnij kanał osobom z zespołu, a każdy subskrybent wybierze własny typ powiadomienia. Wszyscy zapisani na dzwoniący kanał dostaną połączenie, bez opłat za stanowisko.

Filtrować wagę w Alertmanagerze czy w warunkach Echobell?

Lepiej w Alertmanagerze: kierowanie tam pozwala dodatkowo ustawić group_wait i repeat_interval osobno dla każdej wagi, a drzewo kierowania zostaje w kontroli wersji razem z resztą konfiguracji. Warunków Echobell używaj, gdy nie możesz zmienić konfiguracji Alertmanagera albo gdy chodzi o filtry, których Alertmanager w ogóle nie zna — na przykład porę dnia.

Podsumowanie

Cała konfiguracja to jeden odbiorca, jedno send_resolved: false i drzewo kierowania, które trzyma wszystko poza severity: critical z dala od dzwoniącego kanału. Twoje reguły alertowania, grupowanie, wyciszenia i tłumienie zostają dokładnie takie, jakie są, a luka między „Prometheus zauważył" a „człowiek zauważył" znika.

Pobierz Echobell na iPhone'a albo zainstaluj z Google Play, a następnie uruchom powyższy alert EchobellTest, zanim zaczniesz polegać na tej ścieżce w czymkolwiek prawdziwym.

---

Powiązane

• Dokumentacja integracji z Prometheusem
• Dokumentacja warunków kanału
• Powiadomienia telefoniczne z Grafany
• Alerty telefoniczne z Uptime Kuma
• Przewodnik dla programistów po walce ze zmęczeniem alertami