Charles JUDITH

Un grand nombre de personnes utilise l’agent NSClient++ pour surveiller les serveurs Win****.

Parfois vous installez et ça fonctionne sans problème mais vous pouvez avoir des erreurs. L’erreur que je rencontre souvent est celle qui concerne les « Performance Data Helper ».

Pour les curieux, voici un lien avec les codes d’erreurs et leur description:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa373046%28v=vs.85%29.aspx

Prenons un exemple d’erreurs que vous pourriez avoir dans le message de sortie du plugin que vous utilisez:

• CPU

NSClient – ERROR: Could not get data for 5 perhaps we don’t collect data this far back?

• Mémoire

NSClient – ERROR: Failed to get PDH value.

• Uptime

NSClient – ERROR: Could not get value

Dans le fichier de log NSC.log (disponible uniquement si les logs sont activés):

2008-07-03 14:13:35: error:.\PDHCollector.cpp:286: Failed to get UPTIME value: No value has been collected yet
2008-07-03 14:13:36: error:.\PDHCollector.cpp:264: Failed to get CPU value: No value has been collected yet
2008-07-03 14:13:37: error:.\PDHCollector.cpp:327: Failed to get MEM_CMT value: No value has been collected yet

Pas de panique, il y a une solution pour corriger ce problème.

Pour résoudre ce problème, il faut réaliser les action suivantes sur le serveur supervisé:

1. Éteindre le service NSClient++
2. Lancer la commande LODCTR /R en ligne de commande
3. Relancer le service NSClient

Une fois ces actions effectuées, votre problème devrait être résolu.

J’espère que ce billet vous aidera si un jour vous rencontrez cette erreur.

Le premier livre sur Centreon « centreon maitrisez la supervision de votre système d’information » a été publié le 06 octobre 2012. L’ouvrage aux éditions ENI est écrit par Loic FONTAINE et Bruno LEGROS avec une préface de Cédric TEMPLE (aka le sérial préfaceur ).

Que vous êtes débutant, utilisateur de Centreon, administrateur système, DSI, etc et que vous désirez apprendre ou approfondir vos connaissances sur Centreon, ce livre est fait pour vous.

L’auteur familiarise le lecteur peut à peut avec l’interface de Centreon, ce qui lui permet de monter rapidement en compétence sur le sujet.

Plusieurs ordonnanceurs et brokers sont abordés comme Nagios, Centreon-Engine et NDO utils et Centreon-Broker.

Un livre complet qui donne même des astuces pour développer ses propres sondes (plugins ou greffons) ainsi qu’une section troubleshoot.

Vous pouvez acheter ce livre sur le site des éditions ENI.

Bonne lecture si vous achetez cet ouvrage.

Pour ce qui ne le savais pas il est possible de personnaliser l’affichage des graphiques dans Centreon. Effectivement il est possible de choisir la couleur du fond, la couleur des lignes ou des aires des graphiques, etc. Je ne vais pas cité toutes les fonctionnalités car le but de cet article n’est pas de toutes les cités mais d’attirer votre attention sur les plus importantes.

Une des personnalisation possible qui me plaît particulièrement à cœur, c’est l’empilage des graphiques ou courbes (stack). Cette fonctionnalité est pratique pour afficher les graphiques du Load Average ou encore les statistiques CPU comme par exemple le cpu_idle, spu_system, …

Dans cette article, nous allons vous montrer comment configurer l’empilage des graphiques ou courbes sur l’indicateur « Load Average ». Pour ce faire, connectez-vous à Centreon avec un compte administrateur de préférence. Cliquez sur l’onglet « Views » puis sur « Graphs » et enfin sur « Curves« . Il faudra cliquer sur la métrique load_1 pour la modifier et y ajouter les informations comme dans la capture d’écran ci-dessous:

Vous remarquerez que nous avons coché les case « Stack » (empilage) et « Filling » (remplissage), puis ajouter un numéro 1 pour « order » qui correspond à l’ordre d’affichage des métriques. Une fois la métrique load_1 configuré il vous faudra configurer les métriques load_5 puis load 15 comme les captures d’écran ci-dessous.

Résumons, nous avons modifié les 3 métriques suivantes: load_1, load_5 et load_15. Nous avons aussi configuré le remplissage des graphiques pour chaque métriques et donné un ordre précis d’affichage à savoir load_1, load_2 et load_5.

Comme toutes les modifications concerne que Centreon, aucun redémarrage de Nagios ne sera nécessaire et les modifications seront pris en compte directement. Visualisons à présent le résultat de nos modifications.

Vous pourrez constater que l’affichage est beaucoup plus « jolie » et le graphique de l’indicateur plus lisible à mon sens.

Maintenant que nous savons comment empiler des métriques sur un graphique, nous allons voir comment choisir les couleurs des aires et des lignes des graphiques. Pour ce faire, il faudra se rendre dans le menu « Views>Graphs>Curves« . Par exemple pour personnaliser les couleurs du graphique de la métrique « connection_time« , il faudra cliquer sur le nom de la métrique pour la modifier.

Pour modifier la couleur de la  ligne du graphique il faudra changer la valeur du champ « Line color« ;

Pour modifier la couleur de l’air du graphique, il faudra changer la valeur du champ « Area color« ;

Si vous modifier la valeur du champ « Area color, » n’oubliez pas de cocher la case « Filling » (remplissage) au sinon votre modification ne sera pas pris en compte.

Vous pouvez aussi ajouter une légende, en ajoutant votre texte dans le champ « Legend Name« .

Voici un exemple de configuration, de la métrique connection_time.

C’est la fin de cet article, en espérant que ces petites astuces vous plairont et rendront service.

Il arrive parfois que certains équipements envoient des traps en hexadécimal à votre plate-forme de supervision. Tout ceux qui ont déjà vu ce type de trap passé peuvent conclure que ces traps ne sont pas du tout lisibles. De ce fait l’interprétation de ces alertes est très difficile voir impossible.

Pour vous donné un cas concrêt de la situation, voici un Exemple de trap reçu en hexadécimal:

Thu Jun 28 13:37:30 2012 .1.3.6.1.4.1.6876.4.3.0.203 3 "Status Event" srv-esx-1.domain.local - This notification is sent on entity alarm state change, by the vCenter Server SNMP agent. '4' 'Gris' 'Gris' '61 6C 61 72 6D 2E 48 69 67 68 41 76 61 69 6C 61  62 69 6C 69 74 79 45 72 72 6F 72 20 2D 20 C3 89  76 C3 A9 6E 65 6D 65 6E 74 3A 20 52 65 73 73 6F  75 72 63 65 73 20 64 65 20 62 61 73 63 75 6C 65  6D 65 6E 74 20 69 6E 73 75 66 66 69 73 61 6E 74  65 73 20 28 37 30 35 38 34 35 36 29 0A 52 C3 A9  73 75 6D C3 A9 3A 20 52 65 73 73 6F 75 72 63 65  73 20 69 6E 73 75 66 66 69 73 61 6E 74 65 73 20  70 6F 75 72 20 73 61 74 69 73 66 61 69 72 65 20  61 75 20 6E 69 76 65 61 75 20 64 65 20 62 61 73  63 75 6C 65 6D 65 6E 74 20 48 41 20 73 75 72 20  6C 65 20 63 6C 75 73 74 65 72 20 43 4C 55 42 41  43 4B 4F 33 33 35 20 64 61 6E 73 20 44 43 5F 43  6F 6C 6C 65 67 69 65 6E 0A 44 61 74 65 3A 20 32  38 2F 30 36 2F 32 30 31 32 20 31 31 3A 33 37 3A  32 39 0A 50 6F 6F 6C 20 64 65 20 72 65 73 73 6F  75 72 63 65 73 3A 20 43 4C 55 42 41 43 4B 4F 33  33 35 0A 44 61 74 61 63 65 6E 74 65 72 3A 20 44  43 5F 43 6F 6C 6C 65 67 69 65 6E 0A ' 'FERME-WEB'

On s’aperçoit que cela n’est vraiment pas pratique à lire. Comment faire pour que votre plate-forme de supervision puisse afficher correctement ce type de trap ?

Pour permettre à votre plate-forme de supervision d’afficher les traps hexadécimal en numérique, il faudra modifier le script d’init de SNMPTRAPD. Effectivement la ligne à modifier est la suivante:
OPTIONS="-Lsd -p /var/run/snmptrapd.pid"
par
OPTIONS="-Oa -Lsd -p /var/run/snmptrapd.pid"
L’option -Oa permet d’afficher la traps sous forme numérique et ainsi d’avoir des traps lisibles.

Après cette modification, il faudra redémarrer le service SNMPTRAPD afin que le daemon soit lancé avec cette nouvelle option.

Vérifions si nos nouvelles traps sont affichés correctement, pour ce faire nous avons deux solutions:

1. Attendre que des nouvelles traps du même type arrivent et analyser le résultat;
2. Simuler la réception d’une trap via la commande snmptrap

Fri Jun 29 17:14:39 2012 .1.3.6.1.4.1.6876.4.3.0.203 3 "Status Event" srv-esx-1.domain.local - This notification is sent on entity alarm state change, by the vCenter Server SNMP agent. '2' 'Gris' 'Gris' 'alarm.StorageConnectivityAlarm - evenement: Connectivite de stockage perdue (7113840) Resume: Connectivite avec le peripherique de stockage naa.700808d7000gdl70000u000008e0000 perdue. Chemin d'acces vmhba1:C0:T0:L1 en panne. Banques de donnees affectees..: \"FERME-WEB\". Date: 29/06/2012 15:14:26 Hote: srv-web-projet-armagedon.domain.local Pool de ressources: FERME-WEB Datacenter: DC-PAR-TH2 Arguments:     eventTypeId = esx.problem.storage.connectivity.lost     objectId = ha-eventmgr     1 = naa.700808d40006gdl70000u000008e0000     2 = vmhba1:C0:T0:L1     3 = \"FERME-WEB\" ' ''

On s’aperçoit que la modification permet bien d’avoir un affichage plus lisible des traps en héxadécimal.

La sortie de la version de Nagios Plugins 1.4.16 a été annoncé il y a quelques heures. Vous pouvez consulter le changelog en cliquant sur le lien suivant:

http://nagiosplugins.org/nagiosplugins-1.4.16

Cette nouvelle release arrive quasiment deux ans après la 1.4.15 qui était sortie le 27 juillet 2010.  Cela peut « réconforter » les personnes qui comme moi était surpris et se posaient des questions sur après le départ de Ton Voon le 4 novembre 2011. Pour rappel Ton Voon a été le leader du projet Nagios Plugins pendant 7 ans.

L’archive est disponible en téléchargement en cliquant sur le lien suivant:

http://sourceforge.net/projects/nagiosplug/files/

A mon vis elle sera testé puis packagé prochainement (si tout se passe bien) dans les distributions comme FAN ou encore CES.

Pour ce qui ne l’aurait pas remarqué, il y a deux nouvelles versions de NDO qui ont été publié depuis le début de l’année 2012 (NDOutils 1.5 et 1.5.1). A la grande surprise ces deux versions sont « stables », pour ceux qui utilisent ce addon de Nagios depuis assez longtemps c’est étonnant quand on sait que la version 1.4 beta 9 a été installée en production pendant longtemps.

La version de NDO 1.5 n’est pas compatible avec Centreon, donc il faudra penser à ne pas mettre à jour NDOutils sur votre plate-forme. Pour information, ce problème de compatibilité a été remonté sur la forge de  Centreon, vous pouvez lire le ticket en cliquant sur le lien suivant:

http://forge.centreon.com/issues/3076

Un des développeurs de Centreon a fait plusieurs tests et n’a pu que constater le problème de « provisionning » de la base de données de NDO qui gère la supervision en temps réelle dans Centreon. Qui dit Supervision en temps réelle, dit aussi statut des hôtes et des services.

Si vous avez NDOutils et que vous constatez des problèmes de performances, je vous recommande d’utiliser la version patché de NDO. Effectivement lorsque que NDO a été développé, il semblerait que certains optimisations comme l’utilisation des indexes aient été oubliés. En installant la version patchée vous pourrez alors bénéficier de ces optimisations.

Pour plus d’informations sur la version de NDO patché, je vous invite à cliquer sur le lien suivant:

http://forum.centreon.com/showthread.php/10287-Passage-NDO-en-version-SVN-NDO-%28Patch-NDOutils%29

Si vous utilisez Fully Automated Nagios ou encore Centreon Enterprise Server vous bénéficiez déjà de cette optimisation.

Vous avez sans doute remarqué que toutes vos traps SNMP sont stockés dans le fichier /var/log/messages.

Le but de cet article est de mieux organiser les journaux de snmptt et ainsi d’identifier si notre serveur de supervision reçoit des traps inconnus.

Pour configurer les journaux de SNMPTT, il faut éditer le fichier /etc/snmp/centreon_traps/snmptt.ini en y apportant les modifications suivantes:

log_enable = 1
log_file = /var/log/snmptt.log
unknown_trap_log_enable = 1
unknown_trap_log_file = /var/log/snmpttunknown.log

Vous pouvez faire des tests de bon fonctionnement en utilisant la commande snmptrap, puis vous pourrez consulter les fichier de log suivants:

• snmptt.log 

root@central-centreon:~# tail -f /var/log/snmptt.log
Thu Mar  1 11:48:18 2012 .1.3.6.1.6.3.1.1.5.1 1 "Status Event" localhost.localdomain - SNMP is restarting
Mon Jun 18 18:05:27 2012 .1.3.6.1.6.3.1.1.5.1 1 "Status Event" localhost.localdomain - SNMP is restarting

• snmpttunknown.log 

root@central-centreon:~# tail -fn 15 /var/log/snmpttunknown.log
Tue Jun 12 17:07:49 2012: Unknown trap (.1.3.6.1.2.1.1.3.0) received from localhost.localdomain at:
Value 0: localhost.localdomain
Value 1: 127.0.0.1
Value 2: 0:0:00:00.00
Value 3: .1.3.6.1.2.1.1.3.0
Value 4: 127.0.0.1
Value 5:
Value 6:
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .0.1=

Comme vous le savez certainement, la mise en place de traps SNMP n’est pas chose facile. Le but de cet article permet de vous guider à travers un cas pratique que vous pourrez appliquer à un autre contexte.

Avant de créer notre service passif, nous allons crée un modèle de service passif. Pour ce faire il faudra se rendre dans le menu Configuration=>Services=>Templates puis créer un nouveau template en cliquant sur « Add ». Il vous faudra ajouter les informations comme dans le screenshot ci-dessous:

Dans ce modèles nous avons créer une commande qui renvoie toujours OK (check_dummy) et avec le code de retour zéro donc qui sera toujours en OK. Effectivement c’est notre trap qui enverra une alerte et donc changera le status du service. Il ne faudra pas oublier de cocher la case « Is volatile » à « Yes » pour être notifié du changement de statut (OK à CRITICAL).

Dans cette exemple les notifications ne sont pas activées mais si vous utilisez ce mécanisme pour être alerté en cas de changement de statut, il faudra l’activer.

Nous pouvons aussi ajouter un « contrôle de fraîcheur », effectivement dans le cadre de la supervision passive l’échange est unidirectionnelle. C’est à dire que c’est la ressource supervisé qui va envoyé son état (en cas d’interruption événementielle) au serveur de supervision. Ce contrôle de fraîcheur permet de s’assurer que nous avons bien le dernier état de notre ressource supervisé, en lançant le check_dummy à intervalle régulier. Cette intervalle régulier est la valeur du paramètre « Freshness Threshold ».

Ces deux paramètres se configurent dans l’onglet « Data Processing », comme dans l’onglet ci-dessous:

Voilà notre modèle de service passif a été crée. Maintenant nous allons créer notre service, et pour ce faire il faudra se rendre dans le menu Configuration=>Services.

Nous allons créer un service nommé « trap-test-2″, les paramètres ajoutés sont ceux présents dans le screenshot ci-dessous:

Vous remarquerez que vous avons mis un contrôle actif toute les heures car Nagios refuse de créer un service sans intervalle de contrôle. Puis nous allons relier une trappe de la catégorie « générique » à notre service. Pour ce faire nous irons dans le menu relation et allons rajouter notre serveur « Centreon-Server » puis notre trappe « ColdStart ». Pour information ColdStart signifie que le service snmpd redémarre. Donc le but de cette trappe SNMP est de nous avertir lorsque le service snmpd redémarre. Vous pouvez voir l’onglet relation ci-dessous:

Une fois notre service enregistré, il ne faudra pas oublier de générer les traps, pour ce faire Configuration=>Nagios=>Snmp traps.

Une fois les trappes générés, il faudra générer la configuration de Nagios, pour ce faire Configuration=>Nagios.

Une fois la configuration de Nagios généré nous allons démarrer le service snmptrapd, puis nous simulerons la réception d’une trappe.

Dans votre terminal, il faudra lancer la commande suivante:

root@central-centreon:~# snmptrap -v2c -c public 127.0.0.1 0 .1.3.6.1.6.3.1.1.5.1 .1 s ''

Vous vous apercevrez que le service test-trap-2 change de statut et passe en WARNING.

Voilà vous avez mis en place un service passif avec traps SNMP sur votre serveur Centreon.

Vous connaissez certainement CES (Centreon Enterprise Server), une ditribution Linux orientée supervision qui se base sur une CentOS. Cette distribution intègre Centreon, Nagios, NRPE, etc.
Vous pouvez ainsi installer et mettre à jour Nagios, Centreon, etc plus facilement par l’intermédaire du gestionnaire de paquet yum.

Pour utiliser les paquets de CES sur RedHat, il vous faut une installation de RedHat 5 puis ajouter le repository de CES dans /etc/yum.repo.d/ces-standard.repo. Le fichier ces-standard.repo n’existe pas il faudra le créer et y ajouter le contenu suivant:

[ces-standard]
name=Centreon Entreprise Server RPM repository for ces $releasever
baseurl=http://yum.centreon.com/standard/stable/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CES

[ces-standard-noarch]
name=Centreon Entreprise Server RPM repository for ces $releasever
baseurl=http://yum.centreon.com/standard/stable/noarch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CES

[ces-standard-deps]
name=Centreon Entreprise Server dependencies RPM repository for ces $releasever
baseurl=http://yum.centreon.com/standard/stable/dependencies/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CES

[ces-standard-deps-noarch]
name=Centreon Entreprise Server dependencies RPM repository for ces $releasever
baseurl=http://yum.centreon.com/standard/stable/dependencies/noarch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CES

Afin de ne pas entrer l’option –nogpgcheck à chaque installation, il faudra rajouter les lignes suivantes dans le fichier /etc/pki/rpm-gpg/RPM-GPG-KEY-CES . Ce fichier n’existe pas il faudra donc le créer.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEy28fYRBADHbNta9G3rwLDRdN+v4KjjNVkFWr1AgbjHW8t1dH3jE/RW99HL
VJFoW1pS29BwZG/LjQiQbHJkn9cqzOxV26LMMAdncfeAiXEBVzQMH1lRBw/LmIQz
QgLcvsldpn04Op0qNl3ZFFZnnKYZsIn16Du1uNqfClOBiceL2lXvk7k0vwCggd5F
DtRJJvFQycOq/1/M/8ZuXgMD/3jYXLDfPDVRQZMeGN25jcn4o+LhvNOqpeBe7rfF
xSwBi1fwh0lvNqPTR7GXxvtfaYeU9swMZZ/+ZMbPgBJ29mnzpo3yfJrt3fP9WgOe
mgOTBH+96YAHXY+jWxi+Lk1oxQCbdPMbtZ59wz6WCirb0X+89qLvouXPCZzMp/eG
2a77A/9S9sKa6fbX74a24suurN+ZhmZZSEJldh3HoofByoF92Gzv2DKKZIpFb1GN
qFa8jVt4JVF60N3bn9ir6uxno5ARuSWTVIF+WTvoNMiEdjvWRU3oLJtJL1luUyLT
Dffb8NEej3e87IEH/4ehA6mv7a6i/7zrY5nDf5zXiqZ3HsGMSbRGQ2VudHJlb24g
RW50ZXJwcmlzZSBTZXJ2ZXIgT2ZmaWNpYWwgU2lnbmluZyBLZXkgPGNlcy1rZXlA
Y2VudHJlb24uY29tPohgBBMRAgAgBQJMtvH2AhsDBgsJCAcDAgQVAggDBBYCAwEC
HgECF4AACgkQ9vxK44p2UrywwQCfSC57qk19N6sBRcbAi+wwbpgmLRQAnAjONYcT
J4DasO87MOFV2oaj7dEpuQINBEy28fwQCAC2W2g5LoyOOOaGKmAvClee2dbLqMj/
b+rdk06FN9avQCg7q45IL1E9j2b4iZayY/DSxB+FZ1bu2vDkci9pMPOdiv/aa+i6
VyFQOO4/LgiNI9siMczf+Uwy5SqOUJNH/6c2Dy+PvYTOqx4F650EnQCVfy1lxMUS
EiWIz21RfnXIJgC4TzJJHr8+hfnORZp44g5PwuA1qgdgRCgbe8WA+mcKsacC639P
fD4iCLYnruNfMKBxIn9lJCmAlSRRdtnvG8UvUtPcdC3USXWnGmp8IZsJk8fq3Pdb
aQqLj5gifdpfyN9kch+jSGmwOnXBQjoJVahoO/vHYlFPCFS4sFHtQ+ZXAAMFB/94
HBPCobYYfD1sG+LUBxBTOfhAWGF26dIR5GUfuI0e6xdqj6tzUzS9rMznQEWK93pE
QX7fKCzOYnpime85L7YHHDi2Buk69qJnYiB4RJyY1hKloHCOVMbhXxsCBStEphZM
j5irY0igeOPRj/NW/h75l3FWXmU51TdoiBSE5NRKqCkj+8thAKLbA99B3Oo5/jlG
7BHQDyVlYAE1vMXKXjl17B9TnTJITkzERebqoQiVwngWRvgsHBl8QG8Jh43GQty5
NqpkHshLED37V5rbp9EOIY1nugxUpZSUcSSHNvWUk34yL9XGZE32L0js69MGT0hq
/6pVMNcgBjtJoqo+p1GLiEkEGBECAAkFAky28fwCGwwACgkQ9vxK44p2UryUzwCe
KFbF6AzjpXX4QuXAL2FwkRpaZfEAnAvM8pfjca6BVWlT3bmimKbMYkGP
=+us4
-----END PGP PUBLIC KEY BLOCK-----

A présent vous disposez d’un server de supervision sous RedHat. Grâce au paquets de CES vous pourrez mieux gérer les l’installation et la mise à jour de vos logiciels de supervision tel que Centreon, Nagios, etc

FAN est une distribution linux (basé sur une CentOS) orientée supervision. Cette solution s’installe rapidement et propose de nombreux outils tels que Nagios, Centreon, Nareto, Nagvis, …

Le développement du projet s’était peu à peu ralentit depuis ces derniers mois par manque de temps de la part des développeurs.

Le leader du projet, Cédric Temple, a décidé de passer les rênes au développeur le plus actif du projet qui est Olivier LI-KIANG-CHEONG (LKCO).

Cédric Temple confie les clés de la maison à LKCO, pour les raisons suivantes:

• LKCO continue à développer FAN;
• LKCO répond aux questions des utilisateurs sur le forum;
• LKCO propose et met en oeuvre des nouvelles idées;

Olivier LI-KIANG-CHEONG prévoit de sortir une nouvelle version de F.A.N, on attend avec impatience la roadmap qui mijote dans son grimoire.

Pour de plus d’informations, je vous invite à lire l’article du blog de Cédric Temple en cliquant sur le lien suivant:

http://cedrictemple.net/dotclear/post/2011/02/21/LKCO-devient-le-nouveau-responsable-de-FAN-Fully-Automated-Nagios