Mettre en place sa première supervision

This post is also available in: Anglais

On vous avait prévenu via la newsletter de juin que cet été, nous revenons aux fondamentaux avec une série d’articles sur l’installation et personnalisation de votre plateforme Centreon.

Nous démarrons donc cette série avec la mise en place de sa première supervision.
Donc, voilà, vous venez de terminer l’installation de votre plate-forme de supervision à partir de Centreon Enterprise Server, via la documentation en ligne de Centreon , et êtes prêt à configurer la supervision de votre système d’information.
Mais par où commencer et comment s’y prendre ?

Avant-propos

Nous ne pourrons passer en revue l’intégralité des objets ni des paramètres associés à chaque objet. Le but de cet article est de vous familiariser avec les concepts de la configuration d’une supervision avec Centreon.

Quelques définitions

Avant de commencer la configuration à proprement parler, passons en revue quelques définitions :

  • Hôte (host) : un hôte correspond à tout équipement du système d’information possédant une adresse IP. Un hôte peut donc être un serveur,  un pare-feu, un routeur, une sonde de température, …
  • Service (service) : un service est un point de mesure (indicateur) rattaché à un hôte tel que le contrôle de la consommation CPU ou mémoire, l’état d’un processus sur un serveur, la consommation de bande passante d’une interface ou encore la détection d’un incident via la réception d’un évènement syslog ou trap SNMP.
  • Sonde de supervision (plugin) : une sonde de supervision est un exécutable binaire ou script, pouvant être exécuté en ligne de commande (shell) avec des arguments, permettant de récupérer la valeur d’un indicateur. C’est donc le résultat de la sonde de supervision qui permettra de connaître la valeur du service et son statut associé.
  • Commande (command) : une commande peut être de plusieurs types : « commande de contrôle », « commande de notification » ou « commande de traitement ». C’est une définition correspondant au chemin d’accès d’un binaire ou script ainsi qu’aux différents arguments nécessaires à son exécution.
  • Contact (contact) : définition d’un utilisateur qui pourra être rattaché à un hôte ou un service afin de recevoir, par notification, les changements de statut de l’élément en question.
  • Groupe (group) : un groupe est un agrégat d’objet de type hôte, service ou contact permettant de manipuler plus simplement ces derniers.
  • Statut (status) : le statut d’un hôte ou d’un service est déterminé par le retour d’exécution de la sonde de supervision. Les différents statuts d’un hôte ou d’un service sont :
    • Hôte
      • UP : l’équipement est présent sur le réseau (ex : réponse positive à une requête ICMP) ;
      • DOWN : l’équipement n’est pas présent sur le réseau ;
      • UNREACHABLE : le statut de l’équipement ne peut être déterminé (situé derrière un équipement en statut « DOWN ») ;
      • PENDING : l’équipement vient juste d’être configuré mais n’a pas encore été contrôlé ;
  • Service
    • OK : la valeur collectée par la sonde de supervision est dans un état nominal ;
    • WARNING : la valeur collectée est supérieure au premier seuil d’alerte ;
    • CRITICAL : la valeur collectée est supérieure au deuxième et dernier seuil d’alerte ;
    • UNKNOWN : la collecte n’a pu aboutir et le statut de l’indicateur ne peut être déterminé. Dans la plupart des cas cela correspond à un problème d’exécution de la sonde de supervision : arguments incorrect ou manquant ;
    • PENDING : l’indicateur vient juste d’être configuré mais n’a pas encore été contrôlé ;
    • Etat (state) : l’état correspond à un statut validé (« HARD ») ou non (« SOFT ») d’un indicateur de supervision (service) ou d’un équipement (hôte). Seule la validation d’un statut (« HARD ») déclenche le processus de notification (mails, SMS, …) vers un contact;
    • Protocole : protocole réseau (ICMP, SNMP, SSH, …) qui sera utilisé par une sonde de supervision afin de collecter la valeur d’un indicateur. Exemple : collecte du pourcentage d’utilisation du CPU via le protocole SNMP.

Prérequis

Nous possédons maintenant les bases de vocabulaire mais voyons ensemble quelques principes.

1. Établir un référentiel de son système d’information

Avant de se lancer dans la configuration de la supervision de vos hôtes et services, il convient de déterminer votre référentiel.
Allez-vous déployer la supervision sur tout ou partie de votre SI ? Quels équipements sont présents dans votre SI ? Sont-ils redondés ? Quel est l’OS installé sur vos serveurs ? Quelles applications hébergent-ils ?

Pour répondre à ces questions, il convient de créer un document référençant par constructeur / modèles / version [/ version OS] / adresse IP ou DNS de ces objets.

2. Déterminer les indicateurs à superviser.

Une fois votre référentiel créé ou extrait à partir d’une CMDB, il convient de référencer les indicateurs à collecter. Ces indicateurs sont à classer selon différents profils :

  • Matériel : référencer l’ensemble des indicateurs permettant de connaître le statut de votre équipement (statut du boitier, température, statut des ventilateurs / FAN, contrôleur RAID, intégrité des disques physiques, …) ;
  • Système d’exploitation : référencer les principaux indicateurs tel que :
    • Pourcentage d’utilisation CPU ;
    • Pourcentage d’utilisation mémoire vive et mémoire virtuel (SWAP, fichier de pagination, …) ;
    • Pourcentage d’utilisation des partitions / volumes ;
    • Pourcentage d’utilisation des interfaces réseau ;
    • Statut  des principaux processus système (statut de l’enregistreur de journaux, …) ;
    • Applicatif : référencer les applications hébergées ainsi que les processus associé (statut du service httpd, contrôle d’accès à l’URI d’une application web, test de connexion à une instance de base de données, …)

Remarque : il est très difficile de déterminer le référentiel des indicateurs à superviser. En effet, définir trop d’indicateurs peut noyer l’utilisateur final dans la masse d’information alors que trop peu d’indicateurs peuvent engendrer la non-détection d’un problème par la supervision. Il est conseillé de revoir périodiquement la configuration de la supervision afin de supprimer les indicateurs inutiles et ajouter ceux qui auraient permis la détection d’un problème non détecté par votre plate-forme.

3. Définir les seuils d’alertes

Votre liste des équipements et des indicateurs liés est maintenant terminée. L’action suivante consiste à définir les niveaux d’alertes.
Pour cela, deux questions : « A partir de quelle valeur un indicateur collecté demande une intervention afin de corriger un éventuel comportement problématique (proactif) ? A partir de quand cet indicateur est considéré critique et le service rendu associé non délivré ? ».

Voici un exemple : le taux d’utilisation du CPU du serveur srv-web-002 est à 91% d’utilisation et les utilisateurs ressentent certains ralentissements en accédant aux applications Web hébergé par le serveur. Le service applicatif rendu est dégradé mais non défaillant. Quels seuils positionner ? Après plusieurs tests de charges, les ralentissements commencent à être ressentis à partir de 85%. Le choix des seuils peut alors être le suivant : « WARNING3 si le % est supérieur à 80% (petite marge) et « CRITICAL » si supérieur à 90% (là aussi une petite marge, car attendre d’atteindre 95% peut être très pénalisant).

4. En cas de défaillance, qui avertir et comment ?

Vous venez de définir les seuils d’alerte pour vos indicateurs, cependant votre référentiel n’est pas encore complet. Qui notifier en cas de détection d’une anomalie ou d’un incident ? Est-ce que ces personnes sont les mêmes suivant la criticité du problème ? Est-ce les mêmes personnes suivant le profil de l’indicateur ?

La réponse la plus probable est « non ». Si votre serveur GNU/Linux héberge un serveur de base de données, il y a de forte change que les incidents matériel et système doivent être pris en charge par l’équipe système et ceux concernant la base de données par l’équipe DBA.

D’autres questions sont aussi essentielles : « Quel sera le moyen de notifications : mail ? SMS ? Autres ? », « Sur quelle plage horaire avertir ? ».

C’est tout pour aujourd’hui !
Mais restez dans les parages, dès la semaine prochaine, on passe à la configuration !

Incoming search terms:

  • définir un seuil d\alerte
  • MemoGuard installation et configuration
  • relancer un service avec centreon
  • sonde centreon

Une réflexion au sujet de « Mettre en place sa première supervision »

  1. Nos outils de supervision réseau évoluent, et nous avons le plaisir d’annoncer l’intégration de l’interface Centreon (ex Oreon) à notre solution de supervision Memoguard, dans ses dernières versions.

Leave a Reply