Funk-lab/ansible/roles/alertmanager_webhook/README.md
Alkatrazz 0aa4c3650d docs(ansible): README par rôle (19) + gaps IaC découverts à l'audit
Audit complet des rôles vs état réel du cluster. Chaque rôle a maintenant
un README.md : but, variables (défauts + surcharges host_vars/vault),
handlers, vérifications, caveats.

Gaps découverts et documentés :
- minio : rôle VIDE (tasks/main.yml sans aucune tâche), service inactif —
  placeholder à implémenter ou retirer (ports 9000/9001 ouverts pour rien)
- llama_server : ne gère que l'instance GPU :1234 — les services CPU
  llama-server-system :1236 et llama-server-monitor :1237 sont créés à la
  main sur gpu-01, non reproductibles par make apply-gpu (+ un
  llama-server-dev.service non documenté présent sur l'hôte)
- hermes_auto_improve : defaults port/repo/branch/log non consommés
  (valeurs en dur dans les scripts), défaut branch obsolète
- lm_studio : README de dépréciation, candidat suppression

Tables admin/ops/ansible.md, README.md et CLAUDE.md corrigées en conséquence.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-10 15:21:24 +02:00

1.2 KiB

alertmanager_webhook

Pont AlertManager → Hermes : reçoit les alertes Prometheus en webhook et les délègue au profil monitor via ask-agent/LiteLLM.

Ce que fait le rôle

  • Déploie webhook.py dans /opt/alertmanager-webhook (serveur HTTP :9093, user hermes)
  • Service systemd alertmanager-webhook
  • Ouvre le port 9093 dans nftables (cluster + pods — AlertManager tourne dans k8s)

Variables principales

Variable Défaut
webhook_port 9093
webhook_user hermes
litellm_url http://127.0.0.1:4000/v1

Configuration côté AlertManager

Le receiver est défini dans k8s/infra/monitoring/values.yaml → URL http://192.168.10.1:9093/. (n8n a aussi son propre receiver pour les emails — les deux coexistent.)

Test manuel

curl -X POST http://192.168.10.1:9093/ -H 'Content-Type: application/json' \
  -d '{"alerts":[{"status":"firing","labels":{"alertname":"Test","severity":"warning"},"annotations":{"summary":"test"}}]}'

Caveat

Le traitement est asynchrone (thread) pour répondre vite à AlertManager — incident passé : BrokenPipeError quand la réponse LLM dépassait le timeout AlertManager (voir progress 2026-05-14).