---
title: "Alerty telefoniczne z Prometheus Alertmanagera: budzą tylko przy krytycznych"
description: "Alertmanager nie ma odbiorcy głosowego. Kieruj alerty Prometheusa na połączenie telefoniczne tylko przy wadze critical: konfiguracja webhooka, warunki i pułapka Watchdog."
date: 2026-09-04
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Prometheus
  - Alertmanager
  - alerty telefoniczne
  - powiadomienia z webhooków
  - Kubernetes
  - dyżury on-call
---

# Alerty telefoniczne z Prometheus Alertmanagera: budzą tylko przy krytycznych

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](https://prometheus.io/docs/alerting/latest/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](/pl/blog/opsgenie-end-of-life-alternatives), dlatego tak wiele zespołów właśnie teraz przegląda tę warstwę na nowo.)
- **Mostki SMS** w rodzaju [Sachet](https://github.com/messagebird/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](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-pl&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid))
- 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`:

```yaml
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ę:

```json
{
  "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`:

```yaml
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:

```yaml
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](https://github.com/prometheus-operator/kube-prometheus), 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.

```yaml
    - 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](https://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:

| Ustawienie | Gdzie | Co robi |
| --- | --- | --- |
| `for:` | Reguła alertu | Jak długo warunek musi się utrzymywać, zanim alert w ogóle się uruchomi. Twoja pierwsza linia obrony przed dwusekundowym mignięciem. |
| `group_wait` | Reguła kierowania | Jak długo czekać na kolejne alerty przed pierwszym powiadomieniem. Domyślnie 30 s; przy krytycznych zejdź do `10s`. |
| `group_interval` | Reguła kierowania | Minimalny odstęp przed powiadomieniem o *nowych* alertach w istniejącej grupie. Domyślnie 5 min. |
| `repeat_interval` | Reguła kierowania | Jak często nierozwiązany alert powiadamia ponownie. **Domyślnie 4h** — więc nocna awaria dzwoni o 03:00 i znowu o 07:00. |

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](/pl/blog/time-window-notifications-using-utc-conditions).

## 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:

```yaml
      - 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:

```bash
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](/pl/blog/how-to-bypass-ios-focus-mode-for-critical-alerts).

### 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](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-alertmanager-phone-call-alerts-pl&mt=8) albo [zainstaluj z Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid), a następnie uruchom powyższy alert `EchobellTest`, zanim zaczniesz polegać na tej ścieżce w czymkolwiek prawdziwym.

---

## Powiązane

- [Dokumentacja integracji z Prometheusem](/pl/docs/developer/prometheus)
- [Dokumentacja warunków kanału](/pl/docs/conditions)
- [Powiadomienia telefoniczne z Grafany](/pl/blog/grafana-call-notification)
- [Alerty telefoniczne z Uptime Kuma](/pl/blog/uptime-kuma-phone-call-alerts)
- [Przewodnik dla programistów po walce ze zmęczeniem alertami](/pl/blog/fix-alert-fatigue-developer-guide)