Lors du premier article de cette série qui vise à vous donner un maximum de clés pour accélérer la résolution de problèmes techniques, nous vous avions donné les outils et des méthodes pour diagnostiquer et identifier la cause des problèmes de connexion entre les Pollers et le serveur Central.
Dans cet article, nous aborderons le cas où les actions sur les objets supervisés ne sont pas prises en compte dans l’interface. Quoi de plus frustrant que d’acquitter une alarme, planifier une période de maintenance ou lancer un contrôle immédiat et avoir le sentiment que… “il ne se passe rien ???”.
Tour d’horizon du fonctionnement
Zoomons sur le fonctionnement des actions lancées par l’utilisateur au travers de l’interface :
- Notre utilisateur connecté sur l’interface Web de Centreon exécute un acquittement (par exemple).
- Le serveur Web Apache (httpd24-httpd) va alors communiquer avec l’API de centreon-gorgone sur le serveur Central et lui envoie la commande à exécuter (dans l’exemple présent : l’acquittement).
- Ensuite ici 2 possibilités : si l’acquittement concerne un équipement supervisé par le serveur Central alors centreon-gorgone écrit dans un fichier pipe ouvert par le moteur de supervision centreon-engine, si l’acquittement concerne un équipement supervisé par un Poller, alors centreon-gorgone du Central communique avec le processus centreon-gorgone du Poller qui se charge aussi d’écrire dans le fichier ouvert par le moteur de supervision centreon-engine du Poller.
- Ce fichier pipe est lu en continu par le processus centreon-engine. Dès lors qu’une nouvelle commande est écrite dans le fichier, centreon-engine exécute celle-ci et renvoie les informations au Central.
Les commandes externes : kézako ?
Les commandes externes désignent toutes les actions de supervision possiblement exécutées par un utilisateur de Centreon au travers de l’interface Web.
- Acquitter (acknowledge) une alerte permet la prise en compte d’une alerte et arrête la notification pour éviter la pollution d’alertes ;
- Planifier une maintenance (set downtime) permet de ne pas désactiver la notification d’une ressource sur une période donnée ;
- Vérifier (check) permet de lancer un contrôle immédiat sur une ressource et ainsi rafraîchir la supervision.
Il en existe d’autres comme soumettre un résultat (submit result) pour les services passifs, vous trouverez toutes les informations relatives à la gestion de la supervision ici.
Résoudre cette anomalie dans Centreon 21.04 : un grand pouvoir entraîne de grandes responsabilités (dixit Spider-Man…)
Ce chapitre doit vous dire quelque chose, mais c’est pour être sûr qu’il soit relu 😉
Nous gardons toujours la même plateforme que dans le précédent article :
- 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 !
Vérification 1 : Contrôler l’accès à l’API de “gorgoned”
Comme vu précédemment, lorsqu’ une action de supervision est déclenchée par l’utilisateur depuis l’interface, l’action est transmise par le serveur Web à centreon-gorgone via son API.
Regardons tout d’abord si l’API du processus centreon-gorgone (‘gorgoned’) écoute bien sur son port par défaut TCP/8085. Pour cela il est possible d’utiliser les utilitaires netstat ou ss :
[root@centreon-central ~]# netstat -plant | grep 8085
LISTEN 0 5 *:8085 *:* users:(("gorgone-httpser",pid=7855,fd=36))
Dans le cas où cette commande ne renverrait pas de résultat, vérifiez que le processus gorgoned est actuellement démarré sur votre serveur Central à l’aide de la commande suivante :
[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 jeu. 2021-08-19 15:43:32 CEST; 1min 12s ago Main PID: 14468 (perl) CGroup: /system.slice/gorgoned.service ├─14468 /usr/bin/perl /usr/bin/gorgoned --config=/etc/centreon-gorgone/config.yaml --logfile=/var/log/centreon-gorgone/gorgoned.log --severity=d... ├─14476 gorgone-nodes ├─14477 gorgone-dbcleaner ├─14478 gorgone-autodiscovery ├─14479 gorgone-cron ├─14480 gorgone-engine ├─14511 gorgone-statistics ├─14512 gorgone-action ├─14513 gorgone-httpserver ├─14514 gorgone-legacycmd ├─14536 gorgone-proxy ├─14537 gorgone-proxy ├─14544 gorgone-proxy ├─14545 gorgone-proxy └─14558 gorgone-proxy août 19 15:43:32 centreon-central systemd[1]: Started Centreon Gorgone.
Cette commande nous confirme que le processus gorgoned est bien active/running. Dans la liste des processus enfant, gorgone-httpserver est le processus relatif à l’API de centreon-gorgone.
Si le processus n’est pas démarré, vous pouvez tout d’abord essayer de le redémarrer avec la commande suivante :
[root@centreon-central ~]# systemctl restart gorgoned
Et si le processus n’est toujours pas démarré, il sera nécessaire d’aller regarder le fichier log de centreon-gorgone dans /var/log/centreon-gorgone/centreon-gorgone.log.
Les erreurs les plus “fréquentes” sont généralement dues aux causes suivantes :
- SElinux en mode ENFORCING ;
- Droits sur les répertoires et les fichiers ;
- Dépendance ou librairie manquante…
Vérification 2 : Sur notre Central, contrôler le fichier pipe
Vérifions qu’une commande qui doit être exécutée par le Central peut l’être.
Précédemment nous avons vu que centreon-gorgone écrit les commandes relatives aux actions de supervision dans un fichier pipe qui est lu en continu par le moteur de supervision centreon-engine.
Vérifions l’existence de ce fichier à l’aide de la commande :
[root@centreon-central ~]# ll /var/lib/centreon-engine/rw/centengine.cmd prw-rw----. 1 centreon-engine centreon-engine 0 18 août 18:20 /var/lib/centreon-engine/rw/centengine.cmd
Ce fichier doit avoir les droits correspondants rw-rw—-, appartenir à l’utilisateur centreon-engine, au groupe centreon-engine et être un fichier pipe ou named pipe identifiable par le premier caractère p dans la chaîne des droits.
Ce fichier est ce qu’on appelle un FIFO (First In/First Out): les écritures effectuées dans ce fichier sont instantanément consommées par centreon-engine.
Dans certains cas, le format de ce fichier ou les droits de celui-ci peuvent être incorrects. Un redémarrage du moteur de supervision est alors requis pour que le fichier soit correctement recréé:
[root@centreon-central ~]# systemctl restart centengine
Ce fichier est créé par un module externe (exactement comme le cbmod.so): externalcmd.so. Si le fichier n’est pas présent, vous pouvez vérifier que le module est bien chargé par centreon-engine au démarrage de celui-ci dans le fichier de log /var/log/centreon-engine/centengine.log:
[root@centreon-central ~]# grep -RIri external /var/log/centreon-engine/centengine.log [1629366622] [29381] Event broker module '/usr/lib64/centreon-engine/externalcmd.so' deinitialized successfully [1629366622] [24389] Event broker module '/usr/lib64/centreon-engine/externalcmd.so' initialized successfully De même vous pouvez vérifier sa présence dans la configuration de centreon-engine, ainsi le bon chargement du module : [root@centreon-central ~]# grep -RIri external /etc/centreon-engine/centengine.cfg broker_module=/usr/lib64/centreon-engine/externalcmd.so check_external_commands=1
Dans le cas où vous ne voyez pas le module chargé ou présent dans la configuration de centreon-engine, vous pouvez vérifier la configuration du collecteur dans le menu Configuration > Collecteurs > Configuration du moteur de collecte, en cliquant sur la configuration du Central et en allant dans l’onglet Données.
Cette configuration doit inclure une directive qui pointe vers :
/usr/lib64/centreon-engine/externalcmd.so:
Dans le cas où cette configuration serait manquante, ajoutez celle-ci en vous référant à la capture d’écran ci-dessus. Sauvegardez le formulaire puis exportez la nouvelle configuration du Central en choisissant la méthode de redémarrage “Redémarrer” :
Pour tester que tout fonctionne correctement, vous pouvez, par exemple, lancer un contrôle immédiat depuis l’interface de Centreon pour un service lié à un hôte supervisé par votre serveur Central.
En parallèle, consultez les fichiers de log /var/log/centreon-gorgone/centreon-gorgone.log et /var/log/centreon-engine/centengine.log, l’action en question devrait apparaître comme ceci :
- Dans /var/log/centreon-gorgone/centreon-gorgone.log:
2021-08-19 17:17:32 - INFO - [engine] Processing external command '[1629386252] SCHEDULE_FORCED_SVC_CHECK;HQ-FW-Inet;Ping;1629386252'
- Dans /var/log/centreon-engine/centengine.log:
[1629386253] [24389] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;HQ-FW-Inet;Ping;1629386252
Vérification 3 : Sur notre Poller, contrôler la communication Gorgone
Maintenant que le bon fonctionnement des actions de supervision est validé sur notre serveur Central, vérifions que ces mêmes actions sont aussi réalisables sur un équipement supervisé par notre Poller.
Lorsque la supervision est réalisée depuis un Poller, le serveur Apache ne communique pas directement avec le Poller, il transfère tout d’abord la commande au processus gorgone du Central. Celui-ci s’occupe alors de répartir puis de transférer les commandes sur le(s) Poller(s) en charge de l’hôte sur lequel on souhaite effectuer l’action.
Vérifions d’abord que la communication des processus centreon-gorgone de notre Central avec notre Poller au niveau Gorgone est effective.
Pour cela, assurons-nous que la communication ZMQ/TCP5556 est établie entre les 2 serveurs (le Poller joue le rôle de serveur) : il doit écouter sur le port en question, le Central joue le rôle de client et s’y connecte) :
[root@centreon-poller ~]# ss -plantu | grep 5556 tcp LISTEN 0 100 *:5556 *:* users:(("gorgone-action",pid=1991,fd=36),("gorgone-engine",pid=1990,fd=36),("gorgone-dbclean",pid=1989,fd=36),("perl",pid=1976,fd=36)) tcp ESTAB 0 0 192.168.56.126:5556 192.168.56.125:45960 users:(("perl",pid=1976,fd=41))
Si dans ce cas vous obtenez un TIME-WAIT ou que vous ne voyez pas de socket ouvert sur le port TCP/5556 du Poller, vérifiez les logs /var/log/centreon-gorgone/gorgoned.log sur ce dernier :
[root@centreon-poller ~]# tailf /var/log/centreon-gorgone/gorgoned.log 2021-08-19 15:09:45 - ERROR - [core] Client pubkey is not authorized. Thumbprint is 'XzVJ5kbmfxYqktqKLLTF62fbf3_qdHn1fH7HLtPj_a8'
Dans l’exemple précédent, la communication ne peut s’établir en raison d’un problème d’authentification du client (le serveur Central). Le thumbprint du Central n’est pas dans la liste de confiance des clients du Poller.
Le plus simple dans ce cas est de récupérer de nouveau la configuration gorgone de votre Poller en vous aidant de la documentation officielle en suivant ce lien.
Vous pouvez tout à fait vous référer à la “Vérification 3” du précédent article de cette série.
(tout est lié dans le Centreon Cinematic Universe)
Vérification 4 : Sur notre Poller, contrôler le fichier pipe
Tout comme le serveur Central, le Poller doit aussi charger le module externe lui permettant de lire et d’exécuter les commandes externes, nous pouvons donc nous baser sur les mêmes points de contrôle que pour le serveur Central :
- Vérifier que le module externalcmd.so est bien chargé au démarrage ;
- Vérifier que le module est bien présent dans la configuration ;
- Dans le cas contraire, l’ajouter dans la configuration de centreon-engine puis exporter la configuration avec un “redémarrage” de votre Poller ;
S’assurer que toute la chaîne fonctionne correctement
Sur l’interface de Centreon, lançons maintenant un contrôle immédiat sur une ressource supervisée par notre Poller afin de valider la bonne exécution de l’action de supervision :
Comme précédemment, en consultant le fichier de log /var/log/centreon-gorgone/centreon-gorgone.log sur notre Central, nous devrions voir l’action en question apparaître :
[root@centreon-central ~]# tailf /var/log/centreon-gorgone/gorgoned.log 2021-08-19 15:43:52 - INFO - [legacycmd] Handling command 'EXTERNALCMD', Target: '3', Parameters: '[1629388009] SCHEDULE_FORCED_SVC_CHECK;HQ-FW-Inet;Ping;1629388009'
Cette fois-ci, on peut voir que le message est légèrement différent lorsque c’est un Poller qui contrôle la ressource: l’occurrence Target: ‘3’ correspond à l’ID du Poller cible, celui à qui le processus gorgone du Central va transférer la requête.
Côté Poller, vous retrouvez notre commande externe dans les logs de gorgone :
[root@centreon-poller ~]# tailf /var/log/centreon-gorgone/gorgoned.log 2021-08-19 15:44:01 - INFO - [engine] Processing external command '[1629388009] SCHEDULE_FORCED_SVC_CHECK;HQ-FW-Inet;Ping;1629388009'
Vérifions enfin le fichier de log de centreon-engine sur notre Poller :
[root@centreon-poller ~]# tailf /var/lib/centreon-engine/centengine.log [1629388012] [2032] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;SV-WINDO-PAR;Ping;1629388009
Mission accomplie !
Vous avez maintenant les principales clés pour comprendre et diagnostiquer au mieux les actions de supervision !
Si cela n’est toujours pas suffisant, vous pouvez augmenter la verbosité du journal de centreon-gorgone en ajustant le fichier /etc/sysconfig/gorgoned afin de modifier l’option –severity=info pour –severity=debug. Cette option peut être définie sur les différents processus centreon-gorgone, aussi bien sur le serveur Central que sur les Pollers.
Il sera ensuite nécessaire de recharger la configuration de systemd puis de redémarrer centreon-gorgone:
[root@centreon-poller ~]# systemctl daemon-reload [root@centreon-poller ~]# systemctl restart gorgoned
N’oubliez pas de désactiver le debug après la fin de votre diagnostic ;-))
Enfin, n’hésitez pas à venir poser vos questions sur notre Slack dédié à la communauté Centreon. Nous serons heureux de vous aider !
Partager
