Vous êtes ici:

Débogage Centreon Broker sur un Central

Cette page sera consacrée aux méthodes pour contrôler le bon fonctionnement de notre broker préféré. Nous partirons du principe que nous sommes sur une installation standalone sous CentOS principalement. Nous avons un seul service, il s'agit de check_centreon_ping.
La page suivante est consacrée au bon fonctionnement d'un poller distant dans une architecture distribuée.

Les différents points de contrôles

Fonctionnement de Centreon-Broker

Ci-dessus, voici une représentation simpliste des différents flux intervenant dans Centreon-Broker. Chaque numéro correspond à un point de contrôle pour vérifier notre installation, vous pouvez survolez l'image avec votre souris et cliquez sur le numéro désiré. Voici la liste chronologique des actions que vous pouvez réaliser pour vous aider dans vos éventuels diagnostics.

1 - Vérification du fonctionnement du plugin

Pour vérifier le fonctionnement d'un plugin comme check_centreon_ping, nous utiliserons tcpdump. Nous devons vérifier les flux icmp entre le serveur de supervision (ou poller) et l'hôte supervisé. Afin d'obtenir un résultat plus rapide, il suffit de cocher le service voulu et de sélectionner l'action Schedule immédiate check (forced). Pour vérifier sur la boucle locale TCP/IP, saisir la ligne suivante :

tcpdump -i lo icmp

Exemple avec la boucle lo

Pour vérifier un hôte distant, nous devrons connaître le nom de la carte réseau (en général eth0 sur debian). Afin de limiter la recherche, nous appliquerons des filtres source et destination. Pour vérifier dans le sens Supervision vers Hôte, saisir la ligne suivante :

tcpdump -i eth0 src [IP Centreon] and dst [IP hote distant] and icmp

Exemple avec eth0, sens Centreon vers Hôte

Pour vérifier dans les deux sens, saisir la ligne suivante :

tcpdump -i eth0 host [IP Centreon] and host [IP hote distant] and icmp

Exemple avec eth0

Autre point très intéressant depuis la version 2.8.x, il est possible de connaître la commande effectivement envoyée par le moteur de supervision. Pour cela, afficher le détail du service dans la vue temps réel. Par exemple pour le service Connection-Time d'une base de données MSSQL.

Vue détail d'un service

Vous avez un bouton pour copier la ligne et l'exécuter en ligne de commande. Ne copiez pas la ligne directement sur le navigateur, vous aurez des retours chariots qui empêcherons d'exécuter la commande. Bien évidemment, il faut au moins une exécution du service pour avoir cette information.

2 - Vérification du fonctionnement de Centreon-Engine

La meilleure façon de vérifier si le moteur du Central fonctionne, c'est la ligne de commande. En effet, il faut bien interpréter l'interface Web comme je vous l'indiquerai plus bas. Voici plusieurs commandes pour tester le fonctionne du démon centengine :

[root@vmtechcentreon ~]# service centengine status
centengine status: running                                 [  OK  ]

[root@vmtechcentreon ~]# ps aux |  grep centengine
494       6629  0.5  0.8 650928  8552 ?        Sl   Feb05  96:45 /usr/sbin/centengine /etc/centreon-engine/centengine.cfg
root     24405  0.0  0.0 103344   856 pts/0    S+   17:17   0:00 grep centengine

Autre commande très intéressante, centenginestats permet de vérifier le fonctionnement du moteur indépendamment du broker. Ce programme donne les statistiques complètes du moteur.

[root@centreon35 ~]# /usr/sbin/centenginestats

Centreon Engine Statistics Utility 1.8.1

Copyright 2003-2008      Ethan Galstad
Copyright 2011-2013,2016 Centreon
License: GPLv2

CURRENT STATUS DATA
------------------------------------------------------
Status File:                            /var/log/centreon-engine/status.dat
Status File Age:                        0d 0h 0m 12s
Status File Version:                    (null)

Program Running Time:                   0d 1h 14m 12s
Centreon Engine PID:                    13588
Used/High/Total Command Buffers:        0 / 0 / 4096

Total Services:                         12
Services Checked:                       12
Services Scheduled:                     12
Services Actively Checked:              12
Services Passively Checked:             0
Total Service State Change:             0.000 / 0.000 / 0.000 %
Active Service Latency:                 0.009 / 0.198 / 0.093 sec
Active Service Execution Time:          0.131 / 1.875 / 0.354 sec
Active Service State Change:            0.000 / 0.000 / 0.000 %
Active Services Last 1/5/15/60 min:     2 / 5 / 12 / 12
Passive Service Latency:                0.000 / 0.000 / 0.000 sec
Passive Service State Change:           0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min:    0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit:              12 / 0 / 0 / 0
Services Flapping:                      0
Services In Downtime:                   0

Total Hosts:                            1
Hosts Checked:                          1
Hosts Scheduled:                        1
Hosts Actively Checked:                 1
Host Passively Checked:                 0
Total Host State Change:                0.000 / 0.000 / 0.000 %
Active Host Latency:                    0.161 / 0.161 / 0.161 sec
Active Host Execution Time:             0.087 / 0.087 / 0.087 sec
Active Host State Change:               0.000 / 0.000 / 0.000 %
Active Hosts Last 1/5/15/60 min:        0 / 1 / 1 / 1
Passive Host Latency:                   0.000 / 0.000 / 0.000 sec
Passive Host State Change:              0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min:       0 / 0 / 0 / 0
Hosts Up/Down/Unreach:                  1 / 0 / 0
Hosts Flapping:                         0
Hosts In Downtime:                      0

Active Host Checks Last 1/5/15 min:     0 / 1 / 1
   Scheduled:                           0 / 1 / 1
   On-demand:                           0 / 0 / 0
   Parallel:                            0 / 1 / 1
   Serial:                              0 / 0 / 0
   Cached:                              0 / 0 / 0
Passive Host Checks Last 1/5/15 min:    0 / 0 / 0
Active Service Checks Last 1/5/15 min:  2 / 9 / 9
   Scheduled:                           2 / 9 / 9
   On-demand:                           0 / 0 / 0
   Cached:                              0 / 0 / 0
Passive Service Checks Last 1/5/15 min: 0 / 0 / 0

External Commands Last 1/5/15 min:      0 / 0 / 0

Nous pouvons vérifier le bon fonctionnement de Centreon-Engine sur l'interface de Centreon. Attention tout de même a bien interpréter les icônes. Si l'icône des bases de données est également rouge, le moteur peut fonctionner mais dans ce cas, ce sera le broker qui ne fonctionne pas. Mais au bout de quelques minutes l'icône des bases de données sera rouge malgré le bon fonctionnement du broker.

Vérification du fonctionnement de Centreon-engine avec Centreon-Web < 2.7.x

Vérification du fonctionnement de Centreon-engine avec Centreon-Web > 2.7.x

Autre vue intéressante pour voir le dysfonctionnement du moteur, c'est la page statistiques du broker (page Home). Pour un fonctionnement normal, vous devriez voir l'encart du central-module-master comme ci-dessous. Cet encart disparait lorsque le moteur engine s'arrête.

Page statistique : le module cdmod est chargé par le moteur centreon-engine.

On peut aussi vérifier le fichier de log et/ou debug s'il est activé.

tail -f /var/log/centreon-engine/centengine.log

3 - Vérification des processus des brokers

3.1 - Centreon >= 2.8.x vérification du fonctionnement du watchdog cbwd

Avec la nouvelle version 2.8.x, nous avons un processus supplémentaire qui est chargé de lancer les processus broker. Par défaut dans une installation standalone, il y a deux processus cbd fonctionnant en mode deamon. Pour afficher ces processus, la commande ps nous est très utile. voici un exemple :

affichage du processus cbwd et de tous les processus cbd

ps aux | grep "cb[wd|d]"

résultat

496       5992  0.0  0.1 237528  1568 ?        Sl   Feb05   0:00 /usr/sbin/cbwd /etc/centreon-broker/watchdog.xml
496       5995  1.2  0.8 948992  8940 ?        Sl   Feb05 242:32 /usr/sbin/cbd /etc/centreon-broker/central-broker.xml
496       5996  0.3  0.8 561984  8872 ?        Sl   Feb05  66:24 /usr/sbin/cbd /etc/centreon-broker/central-rrd.xml

Si vous constatez qu'il vous manque un processus alors que le service cbd est bien démarré, vérifiez le fichier watchdog se trouvant dans le dossier etc de configuration du broker. Celui-ci permet de lancer les différents processus cbd. Vérifiez aussi que paramètre Link to cbd service est à yes pour les modules central-broker-master et central-rrd-master. Une trace des actions est mémorisée dans le fichier de log /var/log/centreon-broker/watchdog.log.

tail -f /var/log/centreon-broker/watchdog.log

3.2 - Centreon < 2.8.x vérification des process cbd

Dans notre configuration, nous devrions avoir deux processus cbd fonctionnant en mode deamon. Pour afficher ces processus, la commande ps nous est très utile. voici un exemple :

affichage de tous les processus cbd

ps aux | grep cbd

résultat

6002     17389  0.1  1.9 105740 10148 ?        Sl   04:29   0:13 /usr/local/centreon-broker/bin/cbd /usr/local/centreon-broker/etc/central-broker.xml
6002     17412  0.1  1.6  54640  8404 ?        Sl   04:29   0:11 /usr/local/centreon-broker/bin/cbd /usr/local/centreon-broker/etc/central-rrd.xml
root     20879  0.0  0.1   3324   828 pts/1    S+   07:26   0:00 grep cbd

Si vous constatez qu'il vous manque un processus alors que le service cbd est bien démarré, vérifiez le fichier master.run se trouvant dans le dossier etc de configuration du broker. Celui-ci permet de lancer ou non les différents processus cbd.

cat /usr/local/centreon-broker/etc/master.run 
## This file define the Centreon Broker daemons to start
# Example :
# central-cbd	central-cbd.xml	y	y
# central-rrd	central-rdd.xml	y	n
#
# The first line the daemon central-cbd is started with start action from
# /etc/init.d/cbd and it's reload by action reload of init script
#
# The second line the daemon central-rrd is started but it is not reload by
# action in /etc/cbd reload
#
#
# daemon_name	daemon_config	running		reload
central-broker	central-broker.xml	y	y
central-rrd	central-rrd.xml	y	y

Dans le cas ci-dessus, tous les processus seront lancés au démarrage et au rechargement de la configuration.

rechargement de la configuration

Un point important à vérifier est le rechargement du broker lors d'un changement de configuration de votre supervision. Centreon utilise le mécanisme de sudo, un moyen très simple de vérifier son bon fonctionnement est de visualiser le fichier /var/log/auth.log pour debian et /var/log/audit/audit.log pour CentOS.

tail -f /var/log/auth.log

Après un rechargement de la configuration, vous devriez voir ces lignes.

Oct 31 07:37:48 centreon240 sudo: www-data : TTY=unknown ; PWD=/usr/local/centreon/www ; USER=root ; COMMAND=/etc/init.d/cbd reload
Oct 31 07:37:48 centreon240 sudo: www-data : TTY=unknown ; PWD=/usr/local/centreon/www ; USER=root ; COMMAND=/etc/init.d/centengine restart
Oct 31 07:37:51 centreon240 su[21151]: Successful su for centreon-engine by root
Oct 31 07:37:51 centreon240 su[21151]: + ??? root:centreon-engine
Oct 31 07:37:51 centreon240 su[21151]: pam_unix(su:session): session opened for user centreon-engine by (uid=0)
Oct 31 07:37:51 centreon240 su[21151]: pam_unix(su:session): session closed for user centreon-engine
Oct 31 07:37:51 centreon240 su[21156]: Successful su for centreon-engine by root
Oct 31 07:37:51 centreon240 su[21156]: + ??? root:centreon-engine
Oct 31 07:37:51 centreon240 su[21156]: pam_unix(su:session): session opened for user centreon-engine by (uid=0)
Oct 31 07:37:51 centreon240 su[21156]: pam_unix(su:session): session closed for user centreon-engine

4 - Vérification du chargement du module cbmod

Relancez Centreon-Engine en surveillant le fichier de log sur une autre terminal SSH.

Premier terminal

service centengine restart

Deuxième terminal

tail -f /var/log/centreon-engine/centengine.log

Vérifier le chargement du module au démarrage de Centreon-engine. Vous devriez retrouver cette ligne dans le fichier de log :

4.1 - CentOS

[1518975609] [27197] Event broker module '/usr/lib64/centreon-engine/externalcmd.so' initialized successfully

Chargement du module cbmod

4.2 - Debian

[1518976002] [24235] Event broker module '/usr/lib/centreon-broker/cbmod.so' initialized successfully

Chargement du module cbmod

5 - Vérification des logs de Centreon-Broker

Dans une configuration standard, les logs du broker sont situés dans le dossier /var/log/centreon-broker. les processus cdb doivent pouvoir créer des fichiers de log, la particularité venant du processus cbmod lancé par le moteur de supervision. Le user de centreon-engine doit lui aussi pouvoir écrire un fichier de log dans ce dossier. Voici quelques exemples de vérifications de log :

module central-module-master.log (cbmod)

tail -f /var/log/centreon-broker/central-module-master.log

module central-broker-master (événements)

tail -f /var/log/centreon-broker/central-broker-master.log

module central-rrd-master (graphe de parformances)

tail -f /var/log/centreon-broker/central-rrd-master.log

Pour obtenir plus ou moins d'informations dans ces logs, vous devrez régler les niveaux de détails dans la configuration du broker dans l'interface Centreon (onglet Logger de chaque module).

5.1 - exemples du module central-module-master (cbmod)

Voici ci-dessous la configuration par défaut du fichier de log.

configuration par défaut

Vous avez la possibilité d'ajouter ou non des informations avec trois niveaux de détail (Base, Détaillé, très détaillé). Attention, lorsque vous déboguez, Centreon-Broker étant très verbeux, je vous conseille de limiter la taille du fichier de log ou d'utiliser un mécanisme de rotation de log. Ci-dessous, un tableau indiquant les informations que vous pouvez afficher avec les différents réglages avec le module cbmod. N'oubliez pas de recharger votre configuration à chaque modification.

Configuration des Logs du module cbmod
	Base	Detailled	Very detailled
Configuration messages	Informations essentielles liées à la configuration	Plus de détail sur la configuration statistique et sur "endpoint applier"	idem
Debug messages	affichage création output, input	logs très verbeux, chargement des modules, activités du module NDO	logs très verbeux, chargement des modules, activités du module NDO, taille fichier retention
Error messages	affichage erreurs	affichages erreurs callbacks	idem
Informational messages	information création fichier rétention	très verbeux, affichage information chargement modules, activités NDO	idem, affichage création des macros personnalisées

6 - Vérification des flux TCP-IP de Centreon-Broker

C'est la partie la plus délicate dans le fonctionnement de Centreon-Broker. Nous utilisons des flux TCP pour communiquer entre les différents modules. Assurez-vous que les ports utilisés ne rentrent pas en conflit avec d'autres applications. Généralement, nous utiliserons les ports entre 5667 et 5670. Les modules travaillent en client-serveur, c'est-à-dire qu'un module écoute le port (serveur) tandis que le l'autre émet (client). Avec la commande netstat, vous pouvez lister les communications établies (ETABLISHED) et les ports en écoute (LISTEN). Voici un exemple de commande filtrant les flux TCP ayant la chaine 56 (ce qui correspond en général au port utilisé pour Centreon-Broker.

netstat -an | grep ^tcp | grep 56

Vous obtiendrez, par exemple ce résultat :

tcp        0      0 0.0.0.0:5669            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:5670            0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:5670          127.0.0.1:50993         ESTABLISHED
tcp        0      0 127.0.0.1:50993         127.0.0.1:5670          ESTABLISHED
tcp        0      0 127.0.0.1:5669          127.0.0.1:40067         ESTABLISHED
tcp        0      0 127.0.0.1:40067         127.0.0.1:5669          ESTABLISHED

Nous pouvons utiliser tcpdump pour vérifier s'il y a effectivement des informations circulant entre le moteur et le broker. Dans l'exemple ci-dessous, nous vérifions le flux entrant dans le module cdb-central-broker. Comme vous l'aurez constaté, il s'agit d'une installation standalone avec le poller communicant par la boucle locale lo.

tcpdump -i lo tcp dst port 5669

Nous obtenons, les trames suivantes (données pour l'exemple), preuve qu'il y a bien un traffic entre le moteur et le broker.

16:57:20.925661 IP localhost.40069 > localhost.5669: Flags [P.], seq 13764:13913, ack 1, win 1025, options [nop,nop,TS val 28384352 ecr 28383101], length 149
16:57:20.928305 IP localhost.40069 > localhost.5669: Flags [P.], seq 13913:14395, ack 1, win 1025, options [nop,nop,TS val 28384352 ecr 28384352], length 482
16:57:20.928424 IP localhost.40069 > localhost.5669: Flags [P.], seq 14395:14877, ack 1, win 1025, options [nop,nop,TS val 28384352 ecr 28384352], length 482
16:57:21.928956 IP localhost.40069 > localhost.5669: Flags [P.], seq 14877:15026, ack 1, win 1025, options [nop,nop,TS val 28384603 ecr 28384352], length 149
16:57:26.933568 IP localhost.40069 > localhost.5669: Flags [P.], seq 15026:15175, ack 1, win 1025, options [nop,nop,TS val 28385854 ecr 28384603], length 149

Admettons, maintenant, que vous vous êtes trompé dans la configuration TCP du module cbmod. Mais si, c'est possible :-) vous avez mis 5662 au lieu de 5669. la commande précédente n'affichera rien. Si vous lister les informations sortantes du modules cbmod, vous afficherez des trames mais de longueur vide preuve qu'il n'y a pas d'accusé de réception.

liste le flux sans succès

tcpdump -i lo tcp dst port 5669
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

liste le flux sortant, trame vide (length = 0)

tcpdump -i lo tcp src port 5662
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
17:00:41.678100 IP localhost.5662 > localhost.53443: Flags [R.], seq 0, ack 538189214, win 0, length 0
17:00:41.678256 IP localhost.5662 > localhost.53444: Flags [R.], seq 0, ack 4201357894, win 0, length 0
17:01:11.705533 IP localhost.5662 > localhost.53445: Flags [R.], seq 0, ack 527048862, win 0, length 0
17:01:11.705653 IP localhost.5662 > localhost.53446: Flags [R.], seq 0, ack 1344875028, win 0, length 0

Le mécanisme sera le même pour le flux entre le module central-broker-master et central-rrd-master. Précision, cette méthode de vérification ne vérifie que le protocole tcp, pour connaître le type d'information qui véhicule dans ces trames, nous regarderons cela au niveau des logs (voir point 5)

7 - Vérification du chargement dans la base - événements

Le module central-broker-master comprend deux connexions MySQL. La première enregistre tous les événements de notre supervision. Dans notre exemple, il s'agit de notre service ping avec l'hôte central. Nous partirons de la création de l'hôte. Pour visualiser les événements, il faut paramétrer l'affichage des logs au maximum pour le module central-broker-master. Voici les logs de création de l'hôte et de son service dans la base centreon_storage. Les données relatifs à l'Hôte vont être stockées dans la table hosts et les services dans la table services.

tail -f /var/log/centreon-broker/central-broker-master.log

Création de l'hôte et de son service

[1384340300] [0x9946b40] info:    SQL: processing host event (instance: 1, id: 25, name: central)
.....
[1384340300] [0x9946b40] info:    SQL: processing service event (host id: 25, service_id: 46, description: Ping)

Lancement de la vérification du service

[1384340323] [0x9946b40] info: SQL: processing service check event (host: 25, service: 46, command: /usr/local/plugins/libexec/check_icmp -H 172.16.209.221 -n 3 -w 200,20% -c 400,50%)

Ajout des données de statut à la suite d'une vérification

[1384340324] [0x9946b40] info: SQL: processing service status event (host: 25, service: 46, last check: 1384340323, state (4, 1))

Tables hôte et service dans centreon_storage

8 - Vérification du chargement dans la base - données de performance

Le service ping autorise les données de performance. Le broker va stocker ses données dans 3 tables de la table centreon_storage. La table index_data fait le lien entre les hôtes et services avec les métriques de données de performances. Les métriques seront stockés dans la table metrics puis les valeurs de ses métriques dans la table data_bin

tail -f /var/log/centreon-broker/central-broker-master.log

Création de la relation hôtes/services - métrique

[1384340323] [0x99a22c8] debug:   storage: processing service status event
[1384340323] [0x99a22c8] debug:   storage: found index 13 of (25, 46) in cache
[1384340323] [0x99a22c8] debug:   storage: generating status event for (25, 46) of index 13

Création des métriques

[1384340324] [0x99a22c8] debug: storage: processing service status event

[1384340324] [0x99a22c8] debug: storage: found index 13 of (25, 46) in cache

[1384340324] [0x99a22c8] debug: storage: generating status event for (25, 46) of index 13

[1384340324] [0x99a22c8] debug: storage: parsing perfdata string 'rta=0.019ms;200.000;400.000;0; pl=0%;20;50;; rtmax=0.041ms;;;; rtmin=0.007ms;;;;'

[1384340324] [0x99a22c8] debug: storage: got new perfdata (name=rta, value=0.019000, unit=ms, warning=200.000000, critical=400.000000, min=0.000000, max=nan)

[1384340324] [0x99a22c8] debug: storage: parsing perfdata string 'pl=0%;20;50;; rtmax=0.041ms;;;; rtmin=0.007ms;;;;'

[1384340324] [0x99a22c8] debug: storage: got new perfdata (name=pl, value=0.000000, unit=%, warning=20.000000, critical=50.000000, min=nan, max=nan)

[1384340324] [0x99a22c8] debug: storage: parsing perfdata string 'rtmax=0.041ms;;;; rtmin=0.007ms;;;;'

[1384340324] [0x99a22c8] debug: storage: got new perfdata (name=rtmax, value=0.041000, unit=ms, warning=nan, critical=nan, min=nan, max=nan)

[1384340324] [0x99a22c8] debug: storage: parsing perfdata string 'rtmin=0.007ms;;;;'

[1384340324] [0x99a22c8] debug: storage: got new perfdata (name=rtmin, value=0.007000, unit=ms, warning=nan, critical=nan, min=nan, max=nan)

[1384340324] [0x99a22c8] debug: storage: creating new metric for (13, rta)

..........

[1384340324] [0x99a22c8] info: storage: new metric 52 for (13, rta)

[1384340324] [0x99a22c8] debug: storage: inserting perfdata in data_bin (metric: 52, ctime: 1384340323, value: 0.019000, status: 4)