Prometheus Alertmanager

Vue d’ensemble

L’intégration Alertmanager transfère les changements de statut d’un monitor vers une instance Prometheus Alertmanager. À chaque changement, OKStatus envoie un POST vers ‹votre-url›/api/v2/alerts, et Alertmanager route l’alerte vers les receivers que vous avez configurés (email, Slack, PagerDuty…).

Disponible à partir du plan Pro.

Ce qu’OKStatus envoie

Une alerte par changement de statut, au format Alertmanager v2 :

Champ	Valeur
labels.alertname	OKStatusMonitorDown
labels.severity	critical (down) · warning (dégradé) · info (up / pause)
labels.monitor	le nom du monitor
labels.region	la région d’où le check a été exécuté
labels.status	down · degraded · up · paused
labels.source	okstatus
annotations.summary	description lisible
annotations.target	l’URL surveillée

• Les alertes firing (down, degraded) sont envoyées sans endsAt.
• Les alertes de résolution (up, paused) sont envoyées avec endsAt fixé à maintenant, ce qui clôt l’alerte dans Alertmanager.

Routez sur le label source="okstatus" pour séparer les alertes OKStatus du reste de votre alerting.

Configuration

1. Dans OKStatus, allez dans Alerting → Canaux.
2. Cliquez sur Ajouter un canal → Alertmanager / Prometheus.
3. Saisissez l’URL de base de votre Alertmanager — pas le chemin /api/v2/alerts, OKStatus l’ajoute lui-même.
4. (Optionnel) Ajoutez des identifiants basic auth si votre Alertmanager est protégé.
5. Cliquez sur Tester, puis attachez le canal à vos monitors.

Alertmanager auto-hébergé / dans le cluster

Vous pouvez pointer OKStatus vers un Alertmanager qui tourne dans le même cluster Kubernetes. Utilisez le nom DNS du Service Alertmanager, en faisant attention à ces trois points :

1. Utilisez le nom DNS, pas la ClusterIP. Par sécurité, OKStatus refuse les URL qui pointent vers une IP privée/réservée littérale (ex. 10.x, 192.168.x) — mais un nom DNS interne comme *.svc.cluster.local est accepté.
2. Incluez le port — Alertmanager écoute sur 9093, pas 80.
3. Saisissez uniquement l’URL de base — OKStatus ajoute /api/v2/alerts.

Le cross-namespace fonctionne avec le nom pleinement qualifié, par exemple :

http://alertmanager.monitoring.svc.cluster.local:9093

Pointez vers un Service qui a des endpoints

Un Service headless sans pod prêt (0 endpoint) ne résout vers rien : l’envoi échoue avec ENOTFOUND / « injoignable » alors que l’URL semble correcte. Vérifiez que votre cible a des endpoints :

kubectl get endpoints <service-alertmanager> -n <namespace>

Si aucune adresse n’est listée, choisissez le Service qui expose les pods Alertmanager en cours d’exécution.

Tester

Le bouton Tester envoie une seule alerte firing OKStatusMonitorDown (labels ci-dessus, monitor="Test Monitor", region="TEST").

Vous pouvez aussi vérifier l’accessibilité depuis l’intérieur du cluster, depuis le namespace où tourne OKStatus :

kubectl run amtest --rm -i --restart=Never --image=curlimages/curl \
  -n <namespace-okstatus> -- \
  curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST http://alertmanager.monitoring.svc.cluster.local:9093/api/v2/alerts \
  -H 'Content-Type: application/json' -d '[]'

Un 200 signifie qu’Alertmanager a accepté la charge utile.

Comment ça apparaît

• Dans l’UI Alertmanager → Alerts, le test apparaît comme un groupe firing alertname="OKStatusMonitorDown". Comme le test est envoyé une seule fois, Alertmanager le résout automatiquement après son resolve_timeout (5 minutes par défaut) : il n’est donc visible que brièvement — ouvrez l’UI juste après le test, ou filtrez sur source="okstatus".
• Dans vos receivers (email, Slack…), il arrive comme une notification normale et y reste — la confirmation la plus fiable que le pipeline fonctionne.
• Un monitor réellement down renvoie l’alerte à chaque check en échec : son alerte reste donc firing en continu dans Alertmanager jusqu’à ce que le monitor se rétablisse — moment où OKStatus envoie la résolution et Alertmanager marque l’alerte comme résolue.

Dépannage

Symptôme	Cause / solution
« injoignable » / ENOTFOUND	Mauvais hostname, ou le Service a 0 endpoint — vérifiez kubectl get endpoints.
« injoignable » / ECONNREFUSED	Mauvais port — utilisez :9093.
« private or reserved IP address »	Vous avez utilisé une ClusterIP brute — utilisez le nom DNS du Service.
200 mais rien dans les receivers	Alertmanager a bien reçu l’alerte mais aucune route ne correspond — ajoutez une route sur source="okstatus".
Le test marche une fois, puis plus rien dans l’UI	Normal : l’alerte de test unique se résout après le resolve_timeout.
Marche en local mais pas depuis le cluster	Une NetworkPolicy bloque peut-être l’egress du namespace OKStatus vers Alertmanager.