Superviser sa supervision – part 1

This post is also available in: Anglais

Alors, comment s’est passé votre configuration ?
Bien ?
Si oui, parfait !
Si non, reprenez bien les étapes ici et revenez après.
Aujourd’hui, nous allons tordre le cou à ce vieil adage qui dit que « Les cordonniers sont toujours les plus mal chaussés » !
Si superviser son système d’information permet de garantir de la fiabilité de ce dernier, que se passe-t-il si votre plate-forme de supervision n’est plus disponible ? Comment être sûr de la fiabilité de son infrastructure si l’on ne peut garantir celle de son système de supervision ? Comment être sûr de la mesure des SLA si vous ne connaissez pas celle(s) de votre système de référence ?
Pour résumer : pourquoi vouloir superviser son système d’information si l’on n’y attache aucune priorité

Théorie

Il faut donc superviser sa solution de supervision. Cependant, que faut-il contrôler et comment le superviser ? A cette question, la réponse est simple : tout va dépendre de l’architecture de votre plate-forme de supervision.
Premièrement, classons en deux catégories les principales architectures de supervision possibles afin de définir nos besoins en termes de supervision :
• Architecture simple : un seul serveur de supervision avec un serveur de bases de données MySQL déporté ou non ;
• Architecture distribuée : un serveur central, un serveur de bases de données MySQL déporté ou non et un ensemble de collecteurs de supervision distants ;

Architecture simple

Une architecture simple est composée d’un unique serveur servant à la fois à collecter/superviser le système d’information et à héberger l’interface web Centreon et ses processus. Les composants présents sur le serveur sont les suivants :
• Un moteur de supervision (Centreon Engine, Nagios, …) ;
• Un multiplexeur de flux (Centreon Broker, NDOutil, …) ;
• Un serveur de présentation Web (Apache, ….) ;
• Une interface de configuration et de présentation de la collecte (Centreon Web) ;
• Un serveur de bases de données MySQL (déporté ou non) ;
• Des bases de données : « centreon », « centreon_storage » ;
• Des bases de données de type RRD pour la génération de graphiques de performance ;
• Des processus de traitement Centreon (workflow) ;
• Des journaux d’évènements (logs) ;
• Des processus de notifications.

Maintenant que nous avons la liste des composants hébergés sur ce serveur, il faut définir les indicateurs à superviser pour chaque composant ainsi que la manière dont superviser ces derniers.

Moteur de supervision

Le moteur de supervision, dans notre exemple Centreon Engine, est un processus « centengine » démarré par le script « /etc/init.d/centengine », exécuté par l’utilisateur « centreon-engine » et journalisant ses informations dans le fichier « /var/log/centreon-engine/centengine.log ».

Pour valider son fonctionnement, il suffira :
• De contrôler la présence du processus et de l’utilisateur ayant lancé le processus ;
• De contrôler la présence d’éventuelles erreurs dans le journal (log) du processus.

Multiplexeur de flux

Le multiplexeur de flux est la liaison entre le moteur de supervision et l’interface Centreon. C’est lui qui a la charge d’insérer en base de données MySQL les données issues de la supervision ainsi que d’alimenter les bases de données RRD. Suivant votre configuration, au moins un processus « cbd » (pour centreon broker daemon) lancé via le script d’initialisation « /etc/init.d/cbd » doit être démarré. Ces processus lancés par l’utilisateur « centreon-broker » journalisent leurs informations dans les fichiers « /var/log/centreon-broker/central-*.log ».

Pour valider son fonctionnement, il suffira :
• De contrôler la présence d’au moins un processus et de l’utilisateur ayant lancé le(s) processus ;
• De contrôler la présence d’éventuelles erreurs dans les journaux (log) du (des) processus.

Serveur de présentation web

Le serveur de présentation web, généralement Apache, permet à l’utilisateur d’accéder l’interface web de Centreon.
Pour valider son fonctionnement, il suffira :
• De contrôler la présence d’un moins un processus (apache2, httpd, …) et de l’utilisateur ayant lancé le(s) processus (apache, www-data, …) ;
• De contrôler la présence d’éventuelles erreurs dans le journal (log) du serveur web.

Interface web Centreon

L’interface Web Centreon est le cœur de la supervision. C’est au travers de cette interface que l’utilisateur pourra configurer/modifier les ressources à superviser, visualiser le résultat de la collecte ainsi que les éventuelles alertes remontées.

Pour valider son fonctionnement, il suffira de tester l’accès à l’uri de Centreon (http://@ip_serveur_supervision/centreon) ;

Serveur de bases de données MySQL

Le serveur de bases de données MySQL permet de sauvegarder la configuration de la supervision dans la base « centreon » ainsi que le résultat de la collecte dans la base « centreon_storage ». Initialisé par le script « /etc/init.d/mysql », les processus « mysqld » et « mysqld_safe », exécutés par l’utilisateur « root », sauvegardent leurs bases de données dans le répertoire « /var/lib/mysql ». Le journal de fonctionnement est lui disponible à l’emplacement « /var/log/mysqld.log ».

Pour valider son fonctionnement, il suffira :
• De contrôler la présence des processus « mysqld » et « mysqld_safe » ;
• De contrôler la présence d’éventuelles erreurs dans le journal (log) du serveur de base de données ;
• De réaliser des tests de connexions aux bases « centreon » et « centreon_storage » via l’utilisateur MySQL « centreon » dont les propriétés sont disponibles au travers du fichier « /etc/centreon/centreon.conf.php » ;
• De vérifier l’espace libre sur la partition « /var/lib/mysql “.
Note : en cas de partition pleine, le serveur de base de données devient inaccessible empêchant l’utilisateur de se connecter à l’interface Centreon ainsi que l’insertion des données issues de la supervision en base de données.

Base de données RRDs

Les bases de données RRDs sont alimentées par un module spécifique au multiplexeur de flux appelé « cbd-rrd » et sont stockées dans les répertoires « /var/lib/centreon/metrics » et « /var/lib/centreon/status ». Ces bases de données permettent d’afficher les graphiques d’évolution au travers de l’interface web Centreon.

Pour valider leurs fonctionnements, il suffira :
• De vérifier l’espace libre sur la partition hébergeant les deux répertoires ;
• De vérifier la présence du processus « cbd-rrd » ;
• De vérifier la présence d’éventuelles erreurs dans le journal (log) « /var/log/centreon-broker/central-*-rrd.log ».

Processus et workflow Centreon

Afin de fonctionner correctement, Centreon exécute de nombreux processus en tâche de fond, invisible à l’utilisateur et pourtant essentielle à son fonctionnement. Ces processus sont exécutées par des tâches cron définies dans les fichiers « /etc/cron.d/centreon » et « /etc/cron.d/centstorage ». A chaque exécution, le journal associé au processus est mis à jour. Ces journaux sont disponibles dans le répertoire « /var/log/centreon ».

En plus de ces processus, le démon « centcore », initialisé par le script « /etc/init.d/centcore », doit fonctionner en permanence afin de faire la liaison entre les actions ordonnées par l’utilisateur de l’interface web Centreon et le moteur de supervision.

Pour valider leurs fonctionnements, il suffira :
• De vérifier la présence d’éventuelles erreurs dans le journal (log)
« /var/log/centreon/*.log » ;
• De contrôler la présence du « centcore ».

C’est tout pour aujourd’hui.
Nous verrons au prochain article comment mettre en pratique les différents points à contrôler afin de garantir le fonctionnement de sa plate-forme de supervision pour une architecture simple.
Retenez bien ces bases car elles serviront les semaines suivantes pour la supervision d’une plate-forme de supervision sur une architecture distribuée !

Restez connectés !

Incoming search terms:

  • interface centreon moteurs de supervision main cfg

Une réflexion au sujet de « Superviser sa supervision – part 1 »

  1. Tu as tout à fait raison sur le fait qu’il vaut mieux superviser le serveur de supervision par un autre serveur que lui-même. Cela sera vue dans le cas d’une architecture distribuée dans une autre partie ;)

Leave a Reply