NEWInfogérance serveur Linux à 119 €/mois HT — sauvegardes testées, monitoring inclus.OFFREFrais d'installation offerts pour tout engagement ferme de 12 mois.SÉCURITÉDurcissement serveur : 5 règles à appliquer ce mois-ci. Guide gratuit sur demande.MONITORINGAlertes 24/7 sur vos sites et serveurs — surveillance continue par un technicien.CONSEILSauvegardes : testées ou supposées ? On teste la restauration chaque mois pour vous.VEILLEVeille CVE proactive : on lit, on teste, on patch — avant vos clients.NEWInfogérance serveur Linux à 119 €/mois HT — sauvegardes testées, monitoring inclus.OFFREFrais d'installation offerts pour tout engagement ferme de 12 mois.SÉCURITÉDurcissement serveur : 5 règles à appliquer ce mois-ci. Guide gratuit sur demande.MONITORINGAlertes 24/7 sur vos sites et serveurs — surveillance continue par un technicien.CONSEILSauvegardes : testées ou supposées ? On teste la restauration chaque mois pour vous.VEILLEVeille CVE proactive : on lit, on teste, on patch — avant vos clients.
[ Monitoring ]

Alertes serveur : éviter les notifications inutiles

OWL SYSTEMS30 oct. 20263 min
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)

[ Discussion ]
TB
Thomas B.Il y a 2 jours

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.

OWL
OWL SYSTEMSÉquipeIl y a 1 jour

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.

SL
Sarah L.Il y a 5 heures

Est-ce que vous recommandez Wazuh pour une infra de moins de 10 serveurs ? Ou c'est trop lourd à maintenir ?

[ Laisser un commentaire ]