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…