Administration avancée et optimisations
Architecture
1. Continuité de service
a. Introduction
En tant qu’outil de détection des incidents et de remontée d’alertes du SI, la supervision est un élément essentiel et critique du SI. Il est nécessaire de mettre en œuvre des mécanismes de restauration rapide ou de haute disponibilité de la plateforme.
Les éléments à considérer
Quatre éléments doivent être pris en considération dans la mise en œuvre de la haute disponibilité d’une plateforme Centreon :
-
La continuité de la supervision et des alertes en cas de perte d’un collecteur.
-
La continuité de la consolidation des historiques des données de performance et des journaux d’évènements en cas de perte de communication entre les collecteurs et le serveur central.
-
La continuité de service du serveur Centreon central et de sa base de données.
-
la continuité de service malgré l’arrêt des autres serveurs assurant les services de l’infrastructure Centreon (comme Centreon MAP, Centreon MBI).
b. Continuité de la supervision et des alertes
En cas de perte d’un collecteur, la supervision des hôtes qui lui sont rattachés ainsi que les alertes associées s’arrêtent. Ceci provoque une perte de données de supervision et des vides dans les graphiques de performance.
Plusieurs pistes existent pour traiter la haute disponibilité des collecteurs, notamment le déploiement d’un serveur satellite de secours qui peut prendre le relais d’un autre serveur satellite en cas de panne.
c. Continuité de la consolidation des données
Centreon Broker propose un mécanisme de cache pour éviter la perte des données de supervision en cas de coupure réseau entre le serveur central et les collecteurs : toutes les informations de supervision sont enregistrées dans un fichier tampon lors d’une coupure de communication, puis retransmises à la reconnexion. Aucune information n’est ainsi perdue. Ce mécanisme est intégré nativement dans Centreon Broker, il n’est pas nécessaire de le configurer.
d. Continuité de service du serveur central et de sa base de données
La supervision est permanente et enregistre...
Intégration
1. Piloter Centreon en ligne de commande
a. Présentation
Le binaire centreon permet d’interagir avec Centreon en ligne de commande. Ce module est au cœur de la stratégie d’intégration de Centreon. Il permet d’automatiser l’ajout ou la suppression de ressources, de déplacer les ressources d’un collecteur à un autre, de modifier la configuration des ressources, etc.
Installation
Auparavant proposé sous forme de module, le binaire centreon est maintenant directement intégré avec Centreon Web.
Exécution et syntaxe générale
Le binaire centreon est utilisable en ligne de commande sur le serveur central. Il se trouve dans le répertoire /bin/.
# cd /bin/
# ./centreon
La syntaxe standard est la suivante (exception faite pour l’import et l’export des données : voir chapitre précédent) :
# ./centreon -u <LOGIN> -p <PASSWORD> [-o <OBJECT>] -a <ACTION>
[-v <ARGS>]
-
LOGIN et PASSWORD sont les identifiants d’un utilisateur Centreon autorisé à effectuer les opérations qui vont suivre.
-
OBJECT représente le type d’objets sur lequel l’action va porter.
-
ACTION est l’action à effectuer.
-
ARGS est la liste d’arguments de l’action indiquée, séparés par des points-virgules.
b. Interagir avec les hôtes
Lister les hôtes
Pour lister tous les hôtes supervisés :
# ./centreon -u admin -p <pass_de_admin> -o HOST -a show
Ajouter un hôte
Pour ajouter un hôte :
# ./centreon -u admin -p <pass_de_admin> -o HOST -a ADD -v
"MySQLServer;Serveur MySQL;192.168.15.12;HOST-MYSQLSERVER;
Central;Linux|MYSQLServer"
# ./centreon -u admin -p <pass_de_admin> -o HOST -a APPLYTPL -v
"MySQLServer"
Ici, deux commandes sont utilisées : la première permet d’ajouter des hôtes et la seconde permet de générer automatiquement les services à partir des modèles de services liés aux modèles d’hôtes.
Les arguments passés dans l’option -v sont :
-
Nom de l’hôte : MySQLServer
-
Alias de l’hôte : Serveur MySQL
-
Adresse IP : 192.168.15.12
-
Modèle associé à...
Optimisations
1. Optimisations standards de l’ordonnanceur
Configuration
De manière générale, il est conseillé de :
-
utiliser le plus possible les connecteurs Perl et SSH,
-
utiliser des sondes de confiance optimisées : les Centreon Plugins sont développés par l’éditeur.
Architecture distribuée
L’architecture distribuée est une piste très intéressante d’optimisation si l’infrastructure de supervision connaît une latence importante. Augmenter le nombre de collecteurs permet de répartir la charge. Il est notamment recommandé d’avoir le minimum possible de points de contrôle sur le serveur central.
Timeout
Les temps d’attente subis par les sondes induisent de la latence sur la plateforme de supervision. Réduire les timeouts d’exécution des sondes au minimum donne en général de bons gains de performance.
2. Optimisations de Centreon Broker
Si votre infrastructure de supervision est importante (> 10 000 services), il peut être nécessaire d’optimiser Centreon Broker afin de réduire de manière assez importante la charge de votre serveur Centreon central.
Les optimisations proposées dans ce chapitre sont conseillées par l’auteur mais peuvent être adaptées à tout environnement Centreon.
Deux catégories de paramètres...
Sécurité
Les informations qui transitent sur la plateforme de supervision ne contiennent aucune donnée métier de l’entreprise et ne sont pas sensibles de ce point de vue. Savoir que tel ou tel équipement est dans un état correct ou en alerte n’est pas une information très sensible. Même les mots de passe enregistrés sur la plateforme ne donnent souvent qu’un accès en lecture seule aux ressources.
Néanmoins, les informations d’architecture, de niveaux de criticité, les politiques de nommage, etc. peuvent être sensibles et orienter des actions malveillantes.
Pour compléter les mécanismes d’authentification et de gestion des droits traités dans le chapitre Administration, les sections ci-dessous s’attachent à sécuriser au maximum les flux de données d’une plateforme Centreon.
1. Sécuriser les flux de supervision
Le protocole majoritairement utilisé en supervision est SNMP en version 2c. Cette version est malheureusement non sécurisée. Seule une simple chaîne de caractères protège l’accès aux agents. Néanmoins, des mécanismes complémentaires existent : l’agent SNMP peut interdire purement et simplement les accès en écriture ou encore filtrer sur des plages IP. La mise en œuvre de ces mécanismes est...
Centreon Open Tickets
1. Présentation du module
Le module Centreon Open Tickets permet d’ouvrir depuis l’interface web (via un widget) un ticket auprès de votre outil d’ITSM, le but étant de pouvoir suivre administrativement parlant un incident sur votre plateforme.
Avec l’outil Centreon Open Tickets, l’ouverture du ticket est manuelle et contrôlée par l’administrateur de supervision. Néanmoins, il est possible d’ouvrir automatiquement des tickets grâce à une commande de notifications et/ou un script de notifications développé.
Pour installer le module Centreon Open Tickets :
Exécutez la commande ci-dessous :
# dnf install centreon-open-tickets
Rendez-vous dans Administration - Extensions - Gestionnaire et lancez l’installation du module et du widget.
Centreon Open Tickets permet, au travers d’un provider, d’ouvrir des tickets au sein de l’outil.
Par défaut, il existe un provider pour :
-
BmcFootprints 11
-
BmcItsm
-
EasyVista
-
GLPI
-
iTop
-
JIRA
-
Mail (envoi d’e-mail vers une boîte pour ouvrir un ticket)
-
OTRS
-
Request Trackeer 2
-
Serena
-
ServiceNow
2. Utilisation du provider GLPI
Afin de mener à bien cette partie, vous devez déjà avoir configuré un utilisateur qui peut ouvrir des tickets au sein de GLPI. De même, vous devez déjà avoir configuré l’accès...