Alertes serveur : éviter les notifications inutiles

Recevoir des dizaines de notifications chaque jour n'est pas forcément le signe d'une bonne supervision. Si les équipes ne distinguent plus les alertes importantes des événements sans conséquence, elles risquent de passer à côté d'un incident réel.
Définir des seuils cohérents
Un seuil doit tenir compte du fonctionnement habituel de la machine. Une utilisation élevée du processeur pendant une opération planifiée peut être normale. Une charge élevée qui dure longtemps, sans explication connue, mérite davantage d'attention.
Regrouper les alertes liées
Lorsqu'un équipement réseau devient indisponible, plusieurs serveurs situés derrière lui peuvent envoyer une notification. Il est préférable de faire apparaître la cause probable en priorité plutôt que de traiter chaque message comme un incident indépendant.
Faire évoluer les règles
Les seuils et les notifications doivent être revus après les changements d'infrastructure. Une nouvelle application, une hausse du nombre d'utilisateurs ou une modification des horaires d'activité peut rendre les anciennes règles moins pertinentes.
Une supervision bien réglée ne cherche pas à signaler chaque variation. Elle met en évidence les événements qui nécessitent réellement une vérification ou une intervention.
Commentaires (3)
Très bon retour d'expérience. Le coup du `pg_advisory_lock` au lieu du `sleep`, c'est tellement vrai. On a eu le même souci sur un projet Django.
Merci Thomas ! Oui, on a mis du temps à comprendre pourquoi le `sleep` bloquait nos workers de façon aléatoire. Depuis, on ne jure que par l'idempotence.
Est-ce que vous recommandez Wazuh pour une infra de moins de 10 serveurs ? Ou c'est trop lourd à maintenir ?
