Avec cet article, nous ouvrons une série de d’articles dédiés à la résolution d’anomalies fréquemment rencontrées par nos clients et gérés régulièrement par nos équipes.
Commençons donc par un petit guide pratique pour connaître quelles sont les pistes d’investigation et de résolution à étudier lorsqu’un Poller se montre récalcitrant. Ce tuto devrait vous permettre d’identifier rapidement la cause du dysfonctionnement de votre Poller.
Deux cas où votre Poller ne fonctionne pas
Cas n°1 : Le Poller est marqué comme inactif sur la page de gestion des collecteurs
Cas n°2 : Les données d’un Poller sont indiquées comme n’étant plus mises à jour
Résoudre cette anomalie dans Centreon 21.04 : un grand pouvoir entraîne de grandes responsabilités (dixit Spiderman…)
Pour comprendre et résoudre ces cas, nous utiliserons une plateforme Centreon 21.04 en architecture distribuée « simple », c’est-à-dire :
- un serveur Central embarquant les composants principaux de Centreon ainsi que les instances de Base de données (IP 192.168.56.125)
- un Poller (IP 192.168.56.126)
Dans cet article, les commandes passées en SSH sur les serveurs utilisent root. Comme il est de coutume de le dire dans ces cas-là, n’oubliez pas qu’un grand pouvoir entraîne de grandes responsabilités !
Avoir en tête le fonctionnement d’une plateforme
Afin de mener une investigation ciblée et efficace, il est nécessaire de comprendre quels sont les éléments qui composent une plateforme Centreon et comment ceux-ci interagissent.
Voici un bref rappel sur un exemple de plateforme comprenant un serveur Central et un Poller :
- Le moteur de supervision centreon-engine du Poller exécute les scripts de supervision (sondes) pour interroger les équipements supervisés
- Les résultats sont remontés au module centreon-broker du serveur Central en TCP/5669 par le module cbmod du Poller
- Le module centreon-broker du Central traite les résultats, les transfère en base de données et lance la génération des graphiques de performance
- L’interface Web reposant sur un serveur Apache et un backend PHP affiche les éléments à l’utilisateur
- Le module centreon-gorgone se charge d’exporter les configurations sur les Pollers et lance les commandes externes. Ces modules sont à la fois présents sur le serveur Central et sur les Pollers. La communication se fait via le protocole ZMQ sur le port TCP/5556 (où le Poller est serveur et le Central client)
Vérification 1 : Contrôler les connexions réseau
Le Poller doit être connecté à l’IP du Central sur le port TCP/5669 (pour les flux BBDO) ; à l’inverse le Central doit être connecté au Poller sur le port TCP/5556 (flux ZMQ centreon-gorgone).
La commande netstat permet de déterminer l’état de ces connexions (cette commande est fournie par le package net-tools disponible sur les repos base de CentOS).
En lançant la commande depuis le Poller, on peut connaître l’état de ces connexions :
[root@centreon-poller ~]# netstat -plant | egrep '5556|5669' tcp 0 0 0.0.0.0:5556 0.0.0.0:* LISTEN 3761/perl tcp 0 0 192.168.56.126:5556 192.168.56.125:57466 ESTABLISHED 3761/perl tcp 0 0 192.168.56.126:33598 192.168.56.125:5669 ESTABLISHED 3554/centengine
Sur le Central, on doit retrouver ces connexions dans le sens inverse :
[root@centreon-central ~]# netstat -plant | egrep '5669|5556' tcp 0 0 0.0.0.0:5669 0.0.0.0:* LISTEN 1436/cbd tcp 0 0 192.168.56.125:57466 192.168.56.126:5556 ESTABLISHED 1781/gorgone-proxy tcp 0 0 192.168.56.125:5669 192.168.56.126:33574 ESTABLISHED 1436/cbd tcp 0 0 127.0.0.1:5669 127.0.0.1:58200 ESTABLISHED 1436/cbd tcp 0 0 127.0.0.1:58200 127.0.0.1:5669 ESTABLISHED 1430/centengine
Dans le cas où le retour serait différent de “ESTABLISHED”, une vérification des ouvertures de flux et un contrôle des logs firewall permettent en général de repérer le point de blocage.
Attention ! Si votre Poller a été installé via les packages RPM sur un OS existant, il est possible que le firewall Linux soit toujours actif.
Ce point peut être vérifié à l’aide de la commande suivante :
[root@centreon-central ~]# systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1)
Dans le cas où cette commande retournerait un état « active », stoppez puis désactivez le processus firewalld :
[root@centreon-central ~]# systemctl stop firewalld [root@centreon-central ~]# systemctl disable firewalld
Dans le cas où une erreur de configuration serait identifiée à ce stade (par exemple, une adresse IP erronée lors de la création d’un Poller), il sera nécessaire de vérifier et corriger l’entrée à divers niveaux de la configuration de Centreon, nous verrons cela dans un un prochain article 😉.
Vérification 2 : Contrôle du bon fonctionnement de centreon-engine
La deuxième étape consiste à vérifier le bon fonctionnement des instances du moteur de supervision. Dans cet exemple, les vérifications se porteront sur le Poller mais la méthode serait identique pour le module centreon-engine au niveau Central.
Tout d’abord, il faut vérifier que le processus centengine est actif sur le Poller :
[root@centreon-poller ~]# systemctl status centengine centengine.service - Centreon Engine Loaded: loaded (/usr/lib/systemd/system/centengine.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-02-10 09:56:35 CET; 1h 6min ago Main PID: 4463 (centengine) CGroup: /system.slice/centengine.service └─4463 /usr/sbin/centengine /etc/centreon-engine/centengine.cfg
Le processus doit être affiché comme « active (running) » ; il convient également de vérifier que le processus est bien « enabled ». De cette manière, celui-ci démarrera automatiquement avec le système, dans le cas d’un reboot serveur ou d’une panne d’alimentation par exemple.
Dans le cas d’un état « disabled », activez le service au démarrage à l’aide de la commande suivante :
[root@centreon-poller ~]# systemctl enable centengine Created symlink from /etc/systemd/system/centreon.service.wants/centengine.service to /usr/lib/systemd/system/centengine.service.
Dans le cas où le processus serait défaillant, la commande renverrait un message de ce type :
[root@poller ~]# systemctl status centengine centengine.service - Centreon Engine Loaded: loaded (/usr/lib/systemd/system/centengine.service; enabled; vendor preset: disabled) Active: inactive (dead) since Wed 2021-02-10 09:56:35 CET; 22s ago Process: 22846 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 4547 ExecStart=/usr/sbin/centengine /etc/centreon-engine/centengine.cfg (code=exited, status=0/SUCCESS) Main PID: 4547 (code=exited, status=0/SUCCESS)
Essayez alors de redémarrer le service : systemctl restart centengine
Vérifiez également les logs associés à centreon-engine dans le fichier /var/log/centreon-engine/centengine.log
Dans la plupart des cas, ceux-ci vous indiqueront l’origine du problème ; mêmes si ceux-ci sont relativement rares, on peut notamment citer :
- Configuration SELinux
- Droits sur les répertoires et fichiers
- Dépendance ou librairie manquante…
Vérification 3 : contrôler le bon fonctionnement et l’interconnexion centreon-gorgone
Comme rapidement présenté ci-dessus, le module centreon-gorgone (porté par le processus gorgoned) introduit dans Centreon 20.04 vise à remplacer l’ancien module centcore.
Ce module fonctionne sur le principe d’une connexion persistante client/serveur là où l’ancien module centcore initiait uniquement des connexions SSH et imposait un échange de clés préalable.
Dans le cadre de l’anomalie que nous traitons, il peut arriver que le module centreon-gorgone soit en cause, dans la mesure où celui-ci est en charge de la récupération de l’état du Poller (« Is running » : yes or no). On peut, par exemple, se retrouver dans le cas où la supervision est bien opérationnelle (les informations temps réel sont à jour) mais où le Poller est indiqué comme étant en statut « Not running ». Voici les vérifications à effectuer dans ce cas :
- Récupérez et notez l’ID de votre Poller récalcitrant, cet ID sera indispensable pour l’exploitation des logs. Pour cela, rendez-vous sur la page « Collecteurs » de la configuration Centreon et passez la souris sur le nom du Poller concerné.
L’ID sera affiché dans l’URL du lien (ici, l’ID du Poller est 2).
- Vérifiez que les processus gorgoned sont bien opérationnels des 2 côtés :
[root@centreon-central ~]# systemctl status gorgoned gorgoned.service - Centreon Gorgone Loaded: loaded (/etc/systemd/system/gorgoned.service; enabled; vendor preset: disabled) Active: active (running) since mer. 2021-02-10 09:56:03 CET; 2h 10min ago Main PID: 3413 (perl) CGroup: /system.slice/gorgoned.service ├─3413 /usr/bin/perl /usr/bin/gorgoned --config=/etc/centreon-gorgone/config.yaml --logfile=/var/log/centreon-gorgone/gorgoned.log --severity=info ├─3421 gorgone-nodes ├─3428 gorgone-dbcleaner ├─3435 gorgone-autodiscovery ├─3442 gorgone-cron ├─3443 gorgone-engine ├─3444 gorgone-statistics ├─3445 gorgone-action ├─3446 gorgone-httpserver ├─3447 gorgone-legacycmd ├─3478 gorgone-proxy ├─3479 gorgone-proxy ├─3486 gorgone-proxy ├─3505 gorgone-proxy └─3506 gorgone-proxy févr. 10 09:56:03 cent7-2010-ems systemd[1]: Started Centreon Gorgone.
[root@centreon-poller centreon-engine]# systemctl status gorgoned gorgoned.service - Centreon Gorgone Loaded: loaded (/etc/systemd/system/gorgoned.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2021-02-10 09:53:16 CET; 2h 13min ago Main PID: 4384 (perl) CGroup: /system.slice/gorgoned.service ├─4384 /usr/bin/perl /usr/bin/gorgoned --config=/etc/centreon-gorgone/config.yaml --logfile=/var/log/centreon-gorgone/gorgoned.log --severity=info ├─4398 gorgone-dbcleaner ├─4399 gorgone-engine └─4400 gorgone-action
- Sur le serveur Central, vérifiez la présence de messages liés au Poller dans les logs de centreon-gorgone
Dans la capture ci-dessus, on voit bien les instructions échangées avec notre Poller identifié avec l’ID « 2 ». L’absence d’erreurs nous indique que l’interconnexion s’effectue correctement.
- Sur le Poller, vérifiez la présence de la configuration gorgone dans le fichier /etc/centreon-gorgone/config.d/40-gorgoned.yaml (cette configuration est normalement réalisée lors de la procédure de déploiement d’un Poller) :
[root@centreon-poller centreon-engine]# cat /etc/centreon-gorgone/config.d/40-gorgoned.yaml name: gorgoned-Poller description: Configuration for poller Poller gorgone: gorgonecore: id: 2 external_com_type: tcp external_com_path: "*:5556" authorized_clients: - key: 3H2jXp7D7PC7OTM1ifosCO0l7iqJkf60lHWGWYnR5qY privkey: "/var/lib/centreon-gorgone/.keys/rsakey.priv.pem" pubkey: "/var/lib/centreon-gorgone/.keys/rsakey.pub.pem" modules: - name: action package: gorgone::modules::core::action::hooks enable: true - name: engine package: gorgone::modules::centreon::engine::hooks enable: true command_file: "/var/lib/centreon-engine/rw/centengine.cmd"
Si votre fichier est vide ou n’existe pas, suivez ce lien pour redéployer la configuration.
Vérification 4 : Contrôler le fonctionnement et l’interconnexion Centreon-broker
Le bon fonctionnement et l’interconnexion des flux Broker sont des éléments primordiaux d’une plateforme Centreon opérationnelle et efficiente.
Au-delà d’un dysfonctionnement réseau (perte de communication BBDO sur le port TCP/5669), il peut arriver que le traitement des informations temps réel se bloque et de ce fait que le Poller ne soit plus indiqué comme « à jour ».
Les vérifications au niveau Centreon Broker passent par les étapes suivantes :
- Vérification de la cohérence des versions. Les versions des modules cbmod des Pollers doivent correspondre à la version de Centreon broker sur le Central :
[root@centreon-central ~]# rpm -qa | grep centreon-broker centreon-broker-cbd-21.04.3-5.el7.centos.x86_64 centreon-broker-storage-21.04.3-5.el7.centos.x86_64 centreon-broker-21.04.3-5.el7.centos.x86_64 centreon-broker-cbmod-21.04.3-5.el7.centos.x86_64 centreon-broker-core-21.04.3-5.el7.centos.x86_64 [root@centreon-poller ~]# rpm -qa | grep cbmod centreon-broker-cbmod-21.04.3-5.el7.centos.x86_64
- Vérification de l’état du processus cbd (Centreon broker Daemon) sur le serveur Central :
[root@centreon-central ~]# systemctl status cbd cbd.service - Centreon Broker watchdog Loaded: loaded (/usr/lib/systemd/system/cbd.service; enabled; vendor preset: disabled) Active: active (running) since mer. 2021-02-10 09:41:01 CET; 5h 13min ago Main PID: 1529 (cbwd) CGroup: /system.slice/cbd.service ├─1529 /usr/sbin/cbwd /etc/centreon-broker/watchdog.json ├─1537 /usr/sbin/cbd /etc/centreon-broker/central-broker.json └─1538 /usr/sbin/cbd /etc/centreon-broker/central-rrd.json
Le processus doit être indiqué comme actif (« active (running)) et toujours comporter les 3 processus enfants cbwd, cbd broker et cbd rrd.
- Contrôle des logs : ceux-ci se trouvent dans le dossier /var/log/centreon-broker. Les fichiers de logs intéressants ici sont central-broker-master.log sur le Central et module-poller.log sur le Poller :
[root@centreon-central ~]# ls -ltr /var/log/centreon-broker/ total 8 -rw-rw-r-- 1 centreon-broker centreon-broker 1039 5 févr. 10:43 central-broker-master.log-20210205 -rw-rw-r-- 1 centreon-broker centreon-broker 360 5 févr. 10:43 central-module-master.log-20210205 -rw-rw-r-- 1 centreon-broker centreon-broker 240 5 févr. 10:43 central-rrd-master.log-20210205 -rw-rw-r-- 1 centreon-broker centreon-broker 3610 5 févr. 10:43 watchdog.log-20210205 -rw-rw-r-- 1 centreon-broker centreon-broker 1402 10 févr. 09:41 watchdog.log -rw-rw-r-- 1 centreon-broker centreon-broker 669 10 févr. 09:41 central-broker-master.log -rw-rw-r-- 1 centreon-broker centreon-broker 200 10 févr. 09:41 central-rrd-master.log -rw-rw-r-- 1 centreon-broker centreon-broker 400 10 févr. 10:00 central-module-master.log [root@centreon-poller ~]# ls -ltr /var/log/centreon-broker/ total 4 -rw-r--r--. 1 centreon-engine centreon-engine 1330 Feb 10 11:12 module-poller.log
Ces fichiers ne doivent pas comporter d’erreurs récentes.
Dans les précédentes versions de Centreon, il n’était pas rare de trouver des erreurs du type :
Error : conflict_manager : error in the main loop
Dans ce cas, redémarrez simplement le processus Broker sur le serveur Central :
[root@centreon-central ~]# systemctl restart cbd
- Enfin, au niveau Poller, contrôler que le module cbmod est bien chargé dans centreon-engine, l’information doit se trouver dans le fichier de log centengine.log :
[root@centreon-poller ~]# grep -i cbmod.so /var/log/centreon-engine/centengine.log [1612947395] [4463] Event broker module '/usr/lib64/nagios/cbmod.so' initialized successfully
Et ensuite ?
Nous avons vu ici les étapes indispensables de contrôles à effectuer lorsqu’un Poller semble présenter un souci opérationnel. Bien entendu, ce tuto ne saurait couvrir l’ensemble des situations ni répondre de manière absolue à chaque problème ; il vous donnera néanmoins quelques pistes de réflexions sur les questions à se poser dans ce type de situation.
Toujours bloqué ? Avant de fracasser votre clavier par terre, keep calm et visitez le Slack de la communauté ! Il y a toujours quelqu’un (ou presque) prêt à vous aider. Toute suggestion d’articles est également bienvenue !
Dans la suite de cette série d’articles sur la résolution de problèmes, nous verrons les réflexes à adopter lors de problèmes d’exploitation : sondes en erreur, acquittements ou temps d’arrêt non pris en compte…
Partager
