Vote de consensus dans le monitoring uptime | pourquoi cela a du sens

Le multi-region classique reduit les faux negatifs mais augmente les faux positifs. Le vote par consensus resout les deux. Analyse pedagogique du pattern.

Le point faible du monitoring mono-région

Le monitoring mono-région signifie que votre checker s'exécute depuis un seul emplacement. Si un problème réseau se produit sur le chemin entre cet emplacement et votre serveur (BGP flap, changement de routage, maintenance d'un FAI), le moniteur signale DOWN même si le serveur fonctionne correctement.

C'est un faux positif. Vous recevez l'alerte, vous vous réveillez à 3 heures du matin, vous ouvrez votre ordinateur et vous constatez que le site fonctionne.

Les faux positifs posent problème pour deux raisons :

Fatigue d'alerte. Si vous recevez des notifications qui s'avèrent fausses, vous commencez progressivement à les ignorer. Même les vraies.
Perte de confiance dans le monitoring. L'équipe cesse de réagir aux alertes parce que «c'est probablement encore BGP».

Le multi-région naïf résout un problème et aggrave l'autre

La manière courante de résoudre cela est le monitoring multi-région. Le checker s'exécute depuis plusieurs emplacements et une alerte se déclenche dès que l'un d'eux signale DOWN.

Cela améliore la détection des vraies pannes : lorsque le serveur est réellement injoignable, ce n'est pas un seul checker qui se tait, mais plusieurs. Jusque-là, tout va bien.

Mais le problème des faux positifs s'aggrave. Avec un seul checker, vous aviez un certain taux de fausses alertes. Avec trois checkers, il est mathématiquement plus probable qu'au moins l'un d'entre eux signale faussement DOWN. Vous finissez par recevoir plus de fausses alertes, et non moins.

Le vote de consensus résout les deux côtés

Le vote de consensus fonctionne différemment : sur le premier signal DOWN, aucune alerte n'est déclenchée. Le système interroge d'abord les autres régions. Si la majorité d'entre elles signale également DOWN, c'est une vraie panne. Sinon, il s'agit simplement d'une anomalie réseau dans une seule région.

Pseudocode :

result = check_http(monitor)  # primary region
if result.status == 'down':
    secondary_results = check_from_other_regions(monitor)
    if secondary_results:
        # Default rule: 2 of 3 regions must agree on DOWN
        if count_down(secondary_results) + 1 >= 2:
            result.status = 'down'
        else:
            result.status = 'up'
            result.note = 'consensus mismatch'

Exemple de scénario :

primary  -> DOWN  (un checker a eu un BGP flap)
region_a -> UP    (les autres régions voient le serveur normalement)
region_b -> UP

Résultat : UP. Pas d'alerte. Entrée dans le debug log.

Et l'inverse, une vraie panne :

primary  -> DOWN
region_a -> DOWN
region_b -> DOWN

Résultat : DOWN. L'alerte part via Telegram/email/webhook.

Compromis : latence

Le vote de consensus a un coût : sur un signal DOWN, il ajoute quelques secondes de latence supplémentaires, le temps d'interroger les autres régions. Pour la plupart des cas d'usage (uptime monitoring avec un intervalle d'une minute), c'est négligeable. Pour des SLA extrêmement stricts avec un temps de détection inférieur à 30 secondes, cela peut devenir un compromis sensible.

Quand le multi-région n'a aucun sens

APIs internes sur 192.168.x.x. Personne en dehors de votre réseau ne peut les atteindre, donc le multi-région depuis Internet n'a aucun sens. Pour le LAN, utilisez un pattern pull-agent : l'agent s'exécute dans votre réseau et pousse les résultats vers l'extérieur via HTTPS.
Application interne mono-client. Si seules quelques personnes l'utilisent et que vous en faites partie, vous serez au courant d'une panne avant le monitoring.
Un service qui ne fonctionne que dans une seule région du monde. Si votre service est uniquement européen et que vous le voyez DOWN depuis les États-Unis, ce n'est pas un faux positif, mais un comportement attendu.

Comment nous le faisons dans ePulz.io

ePulz.io a le vote de consensus dans son architecture. gather_multiregion() et combine_consensus() dans monitoring.py implémentent le pattern ci-dessus. Le seuil (combien de régions doivent confirmer DOWN) est configurable via le paramètre min_down.

Dans la table Check, chaque ligne stocke un champ consensus avec CSV (par exemple "primary:up,region_a:up,region_b:down"), donc pour le débogage vous avez l'enregistrement exact de la façon dont la décision a été prise.

Conclusion

Le vote de consensus n'est pas une solution magique. Il ne vous donnera pas zéro faux positif et il ne vous sauvera pas lors d'une vraie panne. Mais c'est un meilleur compromis que le mono-région (taux élevé de faux positifs lors d'anomalies réseau) ou le multi-région naïf (multiplication des faux positifs).

Découvrez ePulz.io. Essai de 7 jours, 3 moniteurs, sans carte de crédit.

Vote de consensus dans le monitoring uptime - pourquoi cela a du sens