Supervision

Supervision d'un parc en production

Prometheus, Grafana et Alertmanager pour détecter la panne d'un service ou d'un conteneur avant que les utilisateurs ne la signalent.

Problème

L'équipe infrastructure n'avait pas de vue d'ensemble sur son parc : l'arrêt d'un service ou d'un conteneur n'était connu que lorsqu'un utilisateur le signalait. Le parc est hétérogène : serveurs Windows, machines Linux, hôtes Docker et un serveur hébergé dans le cloud.

Objectif : collecter les mêmes types d'indicateurs sur toutes ces machines, et prévenir l'équipe automatiquement quand un service s'arrête.

Architecture

Serveurs Windows  --windows_exporter--\
Machines Linux    --node_exporter------+--> Prometheus (scrape toutes les 15 s)
Hôtes Docker      --cAdvisor----------/          |
Serveur cloud     --cAdvisor + node----/          | évalue alerts.yml
                                                  v
                                  Alertmanager --> webhook --> canal de l'équipe
                                  Grafana (tableaux de bord, lecture seule sur Prometheus)

Chaque machine expose ses métriques via un exporter. Prometheus les récupère toutes les 15 secondes (modèle pull), évalue les règles d'alerte et transmet les alertes déclenchées à Alertmanager, qui les envoie par webhook au canal de l'équipe. Grafana interroge Prometheus pour l'affichage.

Mise en œuvre

Cycle de vie d'une alerte

État	Signification
`Inactive`	Condition fausse, rien à signaler
`Pending`	Condition vraie, délai `for:` en cours
`Firing`	Alerte déclenchée et transmise à Alertmanager

Le délai for: 1m évite de notifier l'équipe pour une coupure de quelques secondes.

Exemple : détecter un conteneur arrêté

cAdvisor expose container_last_seen, un horodatage mis à jour à chaque collecte. La règle couvre deux cas : la série a disparu, ou elle est encore présente mais n'est plus mise à jour.

- alert: ContainerDown_mon-conteneur
  expr: |
    absent(container_last_seen{job="cadvisor-serveur", name="mon-conteneur"})
    or
    time() - container_last_seen{job="cadvisor-serveur", name="mon-conteneur"} > 60
  for: 1m
  labels:
    severity: critical
    type: docker
  annotations:
    summary: "Conteneur DOWN : mon-conteneur"

Pour un service Windows, la même logique s'applique avec windows_service_state{state="running"} == 0.

Procédure d'ajout d'une alerte

Identifier le nom exact de la métrique : curl -s http://cible:port/metrics | grep …
Écrire la règle dans /etc/prometheus/alerts.yml.
Valider la syntaxe : promtool check rules alerts.yml.
Recharger sans interruption : curl -X POST localhost:9090/-/reload.
Vérifier que la règle apparaît en Inactive dans l'onglet Alerts.

Cette procédure a été rédigée pour que l'équipe puisse ajouter ses propres alertes de manière autonome.

Limites et pistes d'amélioration

Une règle par conteneur ou par service (le nom figure dans l'expression) : à chaque nouveau service, il faut écrire et recharger une règle à la main.
Le délai for: 1m ajouté à l'intervalle de collecte de 15 s signifie qu'un arrêt est notifié au bout d'environ une minute, pas immédiatement.
La chaîne d'alerte dépend du webhook : si le canal de destination est indisponible, la notification n'arrive pas.

Compétences du référentiel mobilisées

Exploiter, dépanner et superviser une infrastructure
Mettre à disposition un service informatique
Documenter une solution technique