Avvisi con chiamata da Prometheus Alertmanager: squillare solo per il critico

Alertmanager non ha un receiver vocale. Come trasformare gli avvisi Prometheus in una chiamata solo per severity critical: config webhook, condizioni e la trappola Watchdog.

Aggiornato

Indice

Alertmanager non ha un receiver vocale. Per ricevere una chiamata quando scatta un avviso di Prometheus, aggiungi un receiver webhook_configs che punti a un canale Echobell con tipo di sottoscrizione Chiamata. Questa guida copre lo YAML esatto, la condizione che impedisce agli avvisi risolti di chiamarti, il routing per severità e l'avviso Watchdog che, altrimenti, farà squillare il tuo telefono ogni quattro ore per sempre.

Prometheus è lo stack di metriche predefinito per quasi tutta l'infrastruttura costruita nell'ultimo decennio, e Alertmanager è davvero bravo nelle parti difficili: deduplicare gli avvisi, raggrupparli, silenziarli durante la manutenzione e inibire il rumore a valle quando cade una dipendenza a monte.

L'unica cosa che non farà è svegliare qualcuno.

Perché Alertmanager non può far squillare il tuo telefono

Alertmanager include receiver per email, Slack, PagerDuty, OpsGenie, Discord, Telegram, Pushover, Webex, MS Teams e una dozzina di altri. Tutti consegnano un messaggio, e i messaggi sono soggetti all'interruttore della suoneria, a Non disturbare e alle modalità Full Immersion di iOS. Alle 03:00 questo significa che l'avviso arriva e non succede nulla.

Non esiste voice_configs. Le opzioni su cui di solito si finisce:

  • PagerDuty / OpsGenie / Splunk On-Call — chiamano davvero, ma sono piattaforme complete di gestione degli incidenti, con il prezzo per postazione che ne consegue. La risposta giusta se ti servono turni e alberi di escalation; sproporzionata se vuoi solo che un telefono squilli. (OpsGenie, tra l'altro, sta chiudendo, ed è per questo che tanti team stanno rivalutando questo strato proprio ora.)
  • Ponti SMS come Sachet — gestisci un altro servizio, paghi un gateway a messaggio, e l'SMS resta comunque un messaggio. Su iOS un testo non buca la Full Immersion a meno che il mittente non sia nella tua lista di consentiti.
  • Collante su Twilio — scrivi un piccolo receiver di webhook, compri un numero, paghi a chiamata, e ora possiedi un pezzo di infrastruttura di produzione il cui unico compito è far squillare un telefono.

Il receiver webhook generico è la via d'uscita. Fa POST di un JSON documentato su qualunque URL, ed è tutto ciò che serve.

Cosa ti serve

  • Un Prometheus + Alertmanager in esecuzione e l'accesso per modificare alertmanager.yml
  • Echobell installato (App Store / Google Play)
  • Dieci minuti

Questa guida è scritta su Alertmanager 0.31. Il payload del webhook è a version: "4" da anni, quindi le release 0.2x si comportano in modo identico.

Il tuo Alertmanager ha bisogno di HTTPS in uscita verso hook.echobell.one. Non deve essere raggiungibile da internet: un Alertmanager dentro un cluster, una VPC o un homelab funziona benissimo.

Passo 1 — Crea un canale che ti chiama

In Echobell, crea un canale chiamato per esempio Prometheus Critical. Imposta il tipo di notifica della sottoscrizione su Chiamata. È questa l'impostazione che conta: gli avvisi di tipo Chiamata arrivano come schermata di chiamata in arrivo e squillano attraverso Full Immersion e Non disturbare di iOS, cosa che una notifica push non fa.

Imposta i template in modo che leggano direttamente il payload di Alertmanager:

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

E, nelle Impostazioni avanzate, un template di link così che il record della notifica salti direttamente al grafico:

{{alerts[0].generatorURL}}

Poi copia l'URL webhook del canale:

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

Tratta quell'URL come un segreto: chiunque lo possieda può far squillare il tuo telefono.

Passo 2 — Aggiungi un receiver webhook

In 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

Ricarica con curl -X POST http://localhost:9093/-/reload oppure con SIGHUP.

Nota send_resolved: false. Il valore predefinito per un receiver webhook è true, a differenza della maggior parte degli altri receiver di Alertmanager: ometterlo significa che il telefono squilla quando il servizio si rompe e squilla di nuovo quando si aggiusta da solo. È quella seconda chiamata a insegnare alle persone a ignorare la prima. Il passo 4 mostra come riavere l'avviso di ripristino senza lo squillo.

Passo 3 — Capire cosa arriva davvero

Alertmanager raggruppa gli avvisi e poi fa una POST per gruppo:

{
  "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 legge il corpo JSON così com'è, quindi ognuno di quei campi è disponibile in template e condizioni. L'accesso annidato funziona con entrambe le sintassi — {{commonLabels.severity}} oppure {{alerts[0].labels["instance"]}}.

Due proprietà di questo payload governano tutto ciò che segue:

Lo status di primo livello è firing se qualsiasi avviso del gruppo è attivo. Diventa resolved solo quando ogni avviso del gruppo si è risolto. Questo lo rende un criterio pulito su cui filtrare.

commonLabels contiene solo le label condivise da tutti gli avvisi del gruppo. È la sorpresa più comune. Se group_by è abbastanza ampio da far sì che un webhook porti HighErrorRate da tre istanze diverse, commonLabels.instance è assente e {{commonLabels.instance}} viene reso come stringa vuota. Più sotto c'è una sezione su come gestirlo.

Passo 4 — Manda i ripristini come push silenzioso

Vuoi comunque sapere quando qualcosa si riprende: semplicemente non vuoi essere chiamato per questo. Aggiungi un secondo canale Echobell chiamato Prometheus Recovered, impostalo su tipo Normale e dagli questi template:

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

e, nelle Impostazioni avanzate, questa condizione:

status == "resolved"

Le condizioni sono espressioni valutate prima che venga consegnato qualsiasi cosa. Se l'espressione è falsa, Echobell accetta la richiesta e non invia nulla.

Poi punta lo stesso receiver a entrambi i canali: un receiver può contenere più webhook_configs.

receivers:
  - name: echobell-critical
    webhook_configs:
      # Fa squillare il telefono. Solo quando è attivo.
      - url: "https://hook.echobell.one/t/<calling-channel-token>"
        send_resolved: false
      # Push silenzioso. La condizione del canale scarta la metà "firing".
      - url: "https://hook.echobell.one/t/<recovery-channel-token>"
        send_resolved: true

Il canale di ripristino riceve sia payload firing sia resolved e scarta i primi. Risultato: il disservizio squilla, il ripristino arriva come push che leggi al mattino.

Passo 5 — Instrada per severità, non tutto

Una route catch-all che manda ogni avviso a un canale di chiamata è una macchina per produrre chiamate ignorate. Dividi per severità in Alertmanager, dove l'albero di routing deve stare:

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

  routes:
    # Watchdog non raggiunge mai un essere umano. Vedi Passo 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

Le route sono valutate dall'alto verso il basso e vince la prima corrispondenza: continue è false per impostazione predefinita. Quindi l'ordine conta: la route Watchdog deve stare sopra qualunque cosa la inghiottirebbe.

Se preferisci tenere un solo canale e filtrare lato Echobell, la condizione equivalente è:

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

Di solito è meglio farlo in Alertmanager, perché così severity guida anche group_wait e repeat_interval. Farlo in Echobell è meglio quando oggi non riesci a far passare una modifica di configurazione.

Passo 6 — La trappola Watchdog

Se usi kube-prometheus-stack, hai un avviso chiamato Watchdog la cui espressione è vector(1). È progettato per scattare sempre: esiste affinché un sistema esterno possa accorgersi che Prometheus stesso si è fermato. La configurazione predefinita lo instrada a un receiver null.

Punta una route catch-all a un canale di chiamata senza escluderlo e Watchdog chiamerà il tuo telefono a ogni repeat_interval, per sempre, a partire da subito. È il motivo numero uno per cui la gente conclude che gli avvisi telefonici "non funzionano".

Tieni la route null del passo 5. Poi, facoltativamente, fanne qualcosa di utile: trasforma Watchdog in un vero dead man's switch.

    - 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 non può essere lui stesso il dead man's switch: avvisa quando una richiesta arriva, non quando smette di arrivare. Manda quindi il ping di Watchdog a un servizio pensato per rilevare il silenzio (Healthchecks.io, Cronitor, Dead Man's Snitch), e poi punta il webhook "check caduto" di quel servizio al tuo canale di chiamata Echobell. Ora una telefonata significa "il monitoraggio stesso è morto", che è l'avviso per cui più desideri essere svegliato e quello che nessuno configura.

Regolare perché non gridi al lupo

Tre impostazioni di Alertmanager fanno quasi tutto il lavoro, più una di Prometheus:

ImpostazioneDoveCosa fa
for:Regola di avvisoPer quanto la condizione deve reggere prima di scattare. La prima linea di difesa contro un singhiozzo di due secondi.
group_waitRouteQuanto attendere altri avvisi prima della prima notifica. 30s di default; scendi a 10s per il critico.
group_intervalRouteIntervallo minimo prima di notificare avvisi nuovi in un gruppo esistente. 5m di default.
repeat_intervalRouteOgni quanto rinotificare un avviso non risolto. 4h di default: un disservizio notturno ti chiama alle 03:00 e di nuovo alle 07:00.

repeat_interval è quella su cui vale la pena ragionare. Quattro ore sono tante per lasciare qualcosa rotto; venti minuti sono una macchina per farti disattivare il canale. Un'ora sul critico è un buon punto di partenza.

Se vuoi che una chiamata senza risposta venga ritentata subito anziché aspettare il prossimo repeat_interval, attiva Riprova chiamata fallita nelle impostazioni dell'app Echobell.

Squillare solo fuori dall'orario di lavoro

Durante la giornata probabilmente stai già guardando una dashboard. Le variabili di tempo di sistema di Echobell (tutte in UTC) permettono a un canale di comportarsi diversamente in base all'ora, senza una seconda route in Alertmanager:

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

Questo ti chiama solo fuori dalle 09:00–17:00 UTC. Punta un secondo canale di tipo Normale sulla fascia inversa per i push diurni:

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

Aggiungi dayOfWeek >= 1 && dayOfWeek <= 5 per trattare anche il fine settimana come fuori orario. Ricorda che sono sempre calcolate in UTC: compensa per il tuo fuso. Una trattazione più completa è in notifiche a fascia oraria con condizioni UTC.

Gestire il problema di commonLabels vuoto

Quando un gruppo contiene avvisi da più istanze, commonLabels.instance sparisce e il titolo della notifica diventa 🔴 HighErrorRate on .

Tre vie d'uscita, in ordine di preferenza:

  1. Metti la label in group_by. Se group_by include instance, ogni avviso del gruppo la condivide e commonLabels.instance è sempre presente. Il costo sono più notifiche: una per istanza invece di una per nome di avviso.
  2. Leggi invece il primo avviso. {{alerts[0].labels.instance}} è sempre valorizzato. È solo uno di forse tanti, quindi abbinalo a un conteggio: {{alerts[0].labels.instance}} (+{{alerts.length}} avvisi).
  3. Progetta l'etichetta perché regga anche vuota. Echobell non ha un operatore di valore predefinito — {{a || "unknown"}} rende il testo letterale true, non un fallback — quindi scrivi Instance: {{commonLabels.instance}} su una riga a sé, dove un valore vuoto è ovviamente vuoto invece di spezzare una frase.

Mantenere piccolo il payload

Un gruppo che copre cento pod produce un corpo JSON grande, ed Echobell rifiuta i corpi di trigger oltre 1 MiB con HTTP 413. Limitalo in Alertmanager:

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

Alertmanager invierà allora al massimo venti avvisi e imposterà truncatedAlerts al numero che ha scartato, che puoi mostrare nel corpo:

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

Condividere l'avviso con il team

Un canale Echobell si può condividere tramite un link di sottoscrizione, e ogni iscritto sceglie il proprio tipo di notifica. La stessa route può quindi far squillare il telefono di chi è reperibile e arrivare come push normale a tutti gli altri: nessun prezzo per postazione e nessuna regola di routing aggiuntiva in Alertmanager.

Si sposa anche con il motivo per cui molti team ospitano Prometheus in proprio: metriche e regole di avviso restano sulla tua infrastruttura, ed Echobell mantiene contenuto e cronologia delle notifiche sul dispositivo anziché sui suoi server.

Cosa questa configurazione non ti dà

Essere onesti sul confine ti risparmia una brutta migrazione più avanti. Echobell è un livello di consegna, non una piattaforma di gestione degli incidenti. Non ha:

  • Calendari di reperibilità né passaggi follow-the-sun
  • Alberi di escalation che chiamano una seconda persona se la prima non risponde
  • Cronologie degli incidenti, tracciamento delle prese in carico o strumenti di postmortem

Se al tuo team servono, ti serve PagerDuty, Grafana Cloud IRM o simili. Qui si copre il buco specifico che Alertmanager lascia aperto: convertire un avviso attivo in un telefono che squilla davvero. Per chi opera da solo, per i piccoli team e per gli homelab, di solito è tutto il requisito.

Risoluzione dei problemi

Non arriva proprio nulla. Guarda prima i log di Alertmanager stesso (level=error component=dispatcher), poi verifica che la route si risolva davvero nel tuo receiver: amtool config routes test severity=critical alertname=HighErrorRate ti dice in quale receiver finirebbe un avviso senza aspettare che ne scatti uno.

Echobell risponde HTTP 404. Il token del canale è sbagliato o il canale è stato eliminato. Un token sconosciuto è un 404, non un successo silenzioso.

Echobell risponde 200 con "notificationTriggered": false. La tua condizione è risultata falsa. Il corpo della risposta porta anche "conditionsMet": false, che è il modo più veloce per distinguere "la mia condizione è sbagliata" da "il mio webhook non è mai arrivato". Verifica status == "firing" rispetto a quello che Alertmanager ha davvero inviato: lo status di primo livello, non alerts[0].status.

HTTP 413. Il payload ha superato 1 MiB. Imposta max_alerts come sopra.

HTTP 405. Il canale ha POST Only attivo e qualcosa ha mandato una GET. Alertmanager fa POST, quindi di solito significa che hai provato l'URL in un browser.

Il titolo ha un buco vuoto. commonLabels non conteneva quella label per quel gruppo. Vedi la sezione sopra.

Non squilla, ma la notifica arriva. Il tipo di notifica della sottoscrizione è Normale o Urgente, non Chiamata. Il tipo si sceglie per iscritto, quindi controllalo sul dispositivo che non squilla.

Testare senza rompere la produzione. Aggiungi una regola con expr: vector(1), un alertname distintivo e severity: critical, lasciala scattare una volta e poi eliminala. Oppure lanciane una a mano:

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

Domande frequenti

Prometheus Alertmanager può fare una telefonata nativamente?

No. Alertmanager ha receiver per email, Slack, PagerDuty, OpsGenie e molti altri, ma non esiste un receiver vocale né SMS. Le chiamate richiedono di instradare il receiver webhook generico verso un servizio in grado di effettuarle, come Echobell, oppure di pagare una piattaforma di gestione degli incidenti.

La chiamata scavalca Non disturbare?

Sì. Il tipo di notifica Chiamata di Echobell si presenta come una chiamata in arrivo, che squilla attraverso Full Immersion e Non disturbare di iOS. Dettagli e impostazioni coinvolte in come aggirare la Full Immersion di iOS per gli avvisi critici.

Funziona con Alertmanager dietro un firewall o dentro Kubernetes?

Sì. Il webhook è una richiesta HTTPS in uscita da Alertmanager, quindi gli basta raggiungere hook.echobell.one. Il tuo Alertmanager non ha bisogno di un indirizzo pubblico né di un ingress.

Come smetto di ricevere chiamate quando un avviso si risolve?

Imposta send_resolved: false sulla config webhook che punta al canale di chiamata. Il receiver webhook usa true per impostazione predefinita, a differenza della maggior parte degli altri receiver di Alertmanager, quindi è opt-out e non opt-in. Per continuare a ricevere i ripristini in silenzio, aggiungi un secondo canale con la condizione status == "resolved".

Perché il telefono squilla ogni quattro ore per lo stesso avviso?

È repeat_interval, che vale 4h per impostazione predefinita. Alertmanager rinotifica con questa cadenza un avviso ancora attivo. Impostalo per route: 1h sul critico è una scelta comune. Se le chiamate sono iniziate subito dopo aver aggiunto una route catch-all, il colpevole è più probabilmente l'avviso Watchdog, sempre attivo; vedi il passo 6.

Si possono chiamare più persone per lo stesso avviso?

Sì. Condividi il canale con i colleghi e ogni iscritto sceglie il proprio tipo di notifica. Tutti gli iscritti al canale di chiamata vengono chiamati, senza costi per postazione.

Meglio filtrare la severità in Alertmanager o nelle condizioni di Echobell?

Meglio in Alertmanager: instradare lì ti permette anche di impostare group_wait e repeat_interval per severità, e l'albero di routing resta sotto controllo di versione con il resto della configurazione. Usa le condizioni di Echobell quando non puoi cambiare la config di Alertmanager, o per filtri che Alertmanager non contempla, come l'ora del giorno.

In conclusione

La configurazione è un receiver, un send_resolved: false e un albero di routing che tiene tutto ciò che non è severity: critical lontano dal canale di chiamata. Lascia regole di avviso, raggruppamenti, silenzi e inibizioni esattamente come sono, e chiude il divario tra "Prometheus se n'è accorto" e "se n'è accorto un essere umano".

Scarica Echobell per iPhone oppure prendilo su Google Play, poi fai scattare l'avviso EchobellTest qui sopra prima di affidare a questo percorso qualcosa di reale.

Correlati

Articoli correlati

Avvisi con chiamata da Uptime Kuma: fai squillare il telefono

Uptime Kuma offre oltre 90 provider di notifica, ma nessuno che faccia squillare il telefono. Ecco come aggiungere avvisi con chiamata per i disservizi usando un solo webhook.

Leggi di più

Il tuo agente IA ti sta aspettando: trasforma le approvazioni in telefonate

Gli agenti autonomi si fermano e aspettano in silenzio quando hanno bisogno di una persona. Nello stack degli agenti non c'è niente che faccia squillare il telefono. Ecco come collegare a Echobell le approvazioni bloccate e le esecuzioni fallite.

Leggi di più

Ricevi gli avvisi di TradingView come chiamate telefoniche con Echobell

Collega TradingView a Echobell tramite webhook per ricevere gli avvisi sui prezzi come chiamate telefoniche o notifiche urgenti, con contenuto vocale personalizzato.

Leggi di più