Les plugins sont des extensions autonomes de Nagios qui permettent de surveiller n'importe quel élément..
Les plugins traitent les arguments de ligne de commande, effectuent une vérification spécifique, puis renvoient les résultats à Nagios Core.
Ils peuvent être des binaires compilés (écrits en C, C ++, etc) ou des scripts exécutables (shell, Perl, PHP, etc).
Depuis l'extension Monitoring de GLPI (à ne pas confondre avec les plugins de NAGIOS) on peut :
Deux exemples d'intégration seront détaillés:
Le plugin check_nwc_health est utilisé pour vérifier l'utilisation de l'interface et la santé du matériel (CPU, mémoire, alimentation, ventilateurs, température) les composants du réseau.
check_nwc_health étant un module autonome il suffit de l'extraire dans la bibliothèque des plugins de SHINKEN pour pouvoir l'utiliser dans le plugin MONITORING de GLPI.
tar xzf /check_nwc_health-6.4.1.6.tar.gz /check_nwc_health-6.4.1.6/plugins-scripts/check_nwc_health /usr/local/nagios/libexec/check_nwc_health
Dans la vue par défaut du plugin Monitoring appuyer sur = pour accéder à la vue système
Dans le menu Commandes ajouter une élément +
Créer la commande en indiquant
check_nwc_health992224191$PLUGINSDIR$/check_nwc_health --hostname $HOSTADDRESS$ --community $ARG1$ --mode $ARG2$ $ARG3$ --morphperfdata '(?:.\*)_(.\*_.\*)'='$1'Puis Ajouter
Chaque item défini avec un $ARG#$ désigne un argument variable.
Dans l'exemple la commande check_nwc_health attend 3 arguments en plus de l'adresse IP de l'hôte servie par la variable $HOSTADDRESS$
Retourner dans la commande pour indiquer les libellés à chacun d'eux
puis Sauvegarder
Les valeurs des arguments de la commande qui doivent être renseignés pour l'exécution doivent être formalisées : $ARG#$ ou # représente un le numéro d'ordre de l'argument parsé lors de l'exécution.
Le plugin Monitoring de GLPI peut exécuter tout type de commande.
Sans mise en forme le retour de la commande est affiché tel que, cependant si le contrôle retourne des données qui respectent le modèle PERFDATA de NAGIOS ces données peuvent être récupérées pour être présentées de manière graphique.
L'exemple traité ici est la collecte des données de replication du DataDomain, il présentesur :
Collectd est un démon qui collecte à intervalles réguliers des statistiques sur les performances d'un système et qui offre les mécanismes pour stocker les valeurs récupérées de plusieurs façons, comme par exemple des fichiers Fichiers RRD (Reduced Resolution Dataset).
Il est fourni avec :
Récupérer le module mod-collectd pour SHINKEN
shinken install mod-collectd-master --local|
Installer le plugin de confection des graphes rrdtool
yum install collectd-rrdtool|
Editer le fichier /etc/collectd.conf pour vérifier/renseigner les Directory utilisées lors de l'installation :
# # Config file for collectd(1). # Please read collectd.conf(5) for a list of options. # http://collectd.org/ # ############################################################################## # Global # #----------------------------------------------------------------------------# # Global settings for the daemon. # ############################################################################## Hostname "localhost" FQDNLookup true BaseDir "/var/lib/collectd" PIDFile "/var/run/collectd.pid" #PluginDir "/usr/lib/collectd" TypesDB "/usr/share/collectd/types.db"|
Copier coller le répertoire /collection3 à la racine du serveur web
cp /usr/share/collectd/collection3 /var/www/html/ -r
Editer le fichier /var/www/html/etc/collection.conf pour renseigner DataDir (emplacement des fichiers rrd produits par collectd)
DataDir "/var/lib/collectd/" GraphWidth 400 #UnixSockAddr "/var/run/collectd-unixsock"
Lancer le démon
service collectd start
datadomain-monitoring est un script perl qui permet de surveiller la disponibilité et de mesurer les performances des Data Domain de EMC à partir de collectd.
La mise en oeuvre de ce script nécessite :
Télécharger la MIB du Datadomain et la placer dans /usr/share/snmp/mibs/
Le script est fourni avec un exemple de collectd.conf à intégrer dans /etc/collectd.conf
cp /datadomain-monitoring-master/nagios_check/check_datadomain.cfg /etc/shinken/|
Pour activer le plugin SNMP :
<Plugin snmp> #replication <Data "dd_replication"> Type "dd_replication" Table true Scale 0.0039062 Instance "DATA-DOMAIN-MIB::replContext" Values "DATA-DOMAIN-MIB::replPreCompBytesSent" "DATA-DOMAIN-MIB::replPostCompBytesSent" "DATA-DOMAIN-MIB::replPreCompBytesRemaining" "DATA-DOMAIN-MIB::replPostCompBytesReceived" </Data> # HOST <Host "dd4200.sns.dgfip"> Address "xx.xxx.xxx.xxx6.250" Version 2 Community "public" Collect "dd_replication" "dd_systat" "dd_fsspace" "ifmib_if_octets64" "ifmib_if_packets64" Interval 60 </Host> </Plugin>
Le script est fourni avec un exemple de my_types.db à intégrer dans /usr/share/collectd/types.db
cat /datadomain-monitoring-master/collectd/my_types.db >> /usr/share/collectd/types.db
Pour définir les nouveaux types de données :
dd_space size:GAUGE:0:U used:GAUGE:0:U available:GAUGE:0:U dd_systat cpuAvgPercentageBusy:GAUGE:0:100 cpuMaxPercentageBusy:GAUGE:0:100 nfsOpsPerSecond:GAUGE:0:U nfsIdlePercentage:GAUGE:0:100 nfsProcPercentage:GAUGE:0:100 nfsSendPercentage:GAUGE:0:100 nfsReceivePercentage:GAUGE:0:100 cifsOpsPerSecond:GAUGE:0:U diskReadKBytesPerSecond:GAUGE:0:U diskWriteKBytesPerSecond:GAUGE:0:U diskBusyPercentage:GAUGE:0:100 nvramReadKBytesPerSecond:GAUGE:0:U nvramWriteKBytesPerSecond:GAUGE:0:U replInKBytesPerSecond:GAUGE:0:U replOutKBytesPerSecond:GAUGE:0:U dd_replication PreCompBytesSent:GAUGE:0:U PostCompBytesSent:GAUGE:0:U PreCompBytesRemaining:GAUGE:0:U PostCompBytesReceived:GAUGE:0:U
Chaque source de données (Data-source) est définie par un quadruple composé du nom de la source de données, du type, des valeurs minimale et maximale, délimités par deux-points (“:”): ds-name: ds-type: min: max:
La longueur du nom de la source de données est limité, dans l'exemple les ds-name :
- PreCompBytesRemaining a été raccourci en PreCompBytesRemain
- PostCompBytesReceived a été raccourci en PostCompBytesRecv
Redémarrer collectd
service collectd restart
Dés lors collectd doit collecter les informations de performance sur l'host.
Pour s'en assurer on peut consulter les graphiques produits sur le front-end web à l'uRL http://addresse-ip-duserveur/collection3/bin/index.cgi
Sélectionner le nom de l'hôte renseigné dans le plugin SNMP Host "dd4200.sns.dgfip" pour afficher une représentation graphique des données collectées :
collectd-nagios -s /var/run/collectd-unixsock -n snmp/dd_replication-1 -H dd4200.sns.dgfip OKAY: 0 critical, 0 warning, 4 okay | PreCompBytesSent=1444503000000.000000;;;; PostCompBytesSent=851353600.000000;;;; PreCompBytesRemain=0.000000;;;; PostCompBytesRecv=69928410000.000000;;;;
Dés lors il est possible d'intégrer le plugin collectd-nagios dans le module MONITORING pour afficher les données collectées dans GLPI
Télécharger le plugin collectd-nagios puis l'extraire dans la bibliothèque des plugins de SHINKEN pour pouvoir l'utiliser dans le plugin MONITORING de GLPI.
Se reporter à la section du guide pour créer un modèle graphique adapté aux données collected
Nom : check_dd_replication Exemple de perfdata pour ce contrôle : PreCompBytesSent=302719200000000.000000;;;; PostCompBytesSent=187767000000.000000;;;; PreCompBytesRemain=0.000000;;;; PostCompBytesRecv=16139660000000.000000;;;; Nom : PreCompBytesSent Nom dynamique ? Non Position 1 Valeur 1 PreCompBytesSent Valeur 2 value1.2 Valeur 3 value1.3 Valeur 4 value1.4
Pour définir un nouveau model graphique il faut récupérer un exemple de données restituées par la commande lancée dans un terminal:
collectd-nagios -s /var/run/collectd-unixsock -n snmp/dd_replication-1 -H dd4200.sns.dgfip
puis récupérer la sortie
OKAY: 0 critical, 0 warning, 4 okay | PreCompBytesSent=1421240000000.000000;;;; PostCompBytesSent=840693300.000000;;;; PreCompBytesRemain=0.000000;;;; PostCompBytesRecv=69277320000.000000;;;;
Dans la vue Métriques cliquer sur la prévisualisation attachée au composant testé puis ressortir
Les composants sont une association de 3 objets , qui définiront un contrôle avec : •
La définition de règles permet d'ajouter dynamiquement des hôtes à un catalogue de composants.
L'exemple suivant décrit la procédure permettant d'ajouter dynamiquement des équipements réseau de type HP 5500 EI.
Les règles permettent d'ajouter dynamiquement des règles en fonction de caractéristiques et/ou d'autres éléments attachés aux hôtes (contrats, plugins, …)
La règle ajoutée dans cet exemple prend en compte la caractèrisque du modèle d'un équipement réseau /
Dans le catalogue de composants aller dans le menu Règles
sélectionner le type de l'équipement
Puis cliquer sur Ajouter
Renseigner les composants de la règle
### Tester la règle
Appuyer sur Rechercher
Une liste d'hôtes correspondant aux critères de la règle doit s'afficher
Enregistrer la règle
Le nombre d'hôtes dynamiques doit s'incrémenter dans le menu du catalogue
Le plugin Monitoring de GLPI permet de notifier automatiquement les changements suivants :
La chaîne de notification repose sur 3 objets :
Un gabarit de contact permet de décrire la façon dont va étre notifié un contact.
Dans, le menu Gabarits de contact appuyer sur + pour créer un gabarit
Un Hosts Noticiations template permet de décrire les événements déclencheurs de la notification .
Dans, le menu Hosts Noticiations templates appuyer sur + pour créer un template
Sauvegarder le template
Dans le menu »Administration»Utilisateurs» de GLPI sélectionner l'utilisateur auquel seront adressées les notifications
Dans le menu Monitoring-contact Appuyer sur Gérer cet utilisateur dans le système de Monitoring
Choisir le gabarit de contact
Puis Sauvegarder
Dans le menu contacts du Catalogue de composants assigner le contact
Si les événements déclencheurs doivent être différents de ceux définis dans le gabarit de contact
Assigner dans Catalogue de composants Hosts notification options
Nagios est conçu pour permettre aux plugins de renvoyer des données de performance (PERFDATA) optionnelles en plus des données d'état normales, ainsi que pour permettre de transmettre ces données de performance à des applications externes pour traitement.
Il existe deux catégories de données de performance qui peuvent être obtenues à partir de Nagios:
Les données de performance de contrôle sont des données internes qui se rapportent à l'exécution réelle d'un contrôle d'un hôte ou de service. Cela peut inclure des éléments tels que la latence du contrôle de service (c'est-à-dire, la “fin” du contrôle de service à partir de son heure d'exécution planifiée) et le nombre de secondes nécessaires à l'exécution d'un contrôle d'hôte ou de service. Ce type de données de performance est disponible pour toutes les vérifications effectuées
Les données de performance du plugin sont des données externes spécifiques au plugin utilisé pour effectuer le contrôle de l'hôte ou du service. Les données spécifiques au plugin peuvent inclure des éléments tels que le pourcentage de perte de paquets, l'espace disque disponible, la charge du processeur, le nombre d'utilisateurs actuels, etc. - ou tout type de mesure que le plugin mesure lorsqu'il s'exécute. Les données de performance spécifiques au plug-in sont facultatives et peuvent ne pas être prises en charge par tous les plugins.
Au minimum, les plugins Nagios doivent renvoyer une seule ligne de texte lisible par l'homme qui indique l'état de certains types de données mesurables. Par exemple, le plugin check_ping renvoi une ligne de texte comme suit:
PING ok - Perte de paquets = 0%, RTA = 0.80 ms
Les plugins peuvent renvoyer les données de performances facultatives dans leur sortie en envoyant la chaîne de texte normale, lisible par l'utilisateur, généralement suivie d'un caractère pipe (|), puis d'une chaîne contenant une ou plusieurs données de performances métriques .
Prenons le plugin check_ping comme exemple et supposons qu'il a été amélioré pour renvoyer le pourcentage de perte de paquets et le temps d'aller-retour moyen en tant que métriques de données de performances.
Exemple de sortie du plugin pourrait ressembler à ceci:
PING ok - Perte de paquets = 0%, RTA = 0,80 ms | percent_packet_loss = 0, rta = 0,80
Lorsque Nagios verra ce format de sortie de plugin, il divisera la sortie en deux parties:
Tout ce qui précède le caractère pipe est considéré comme la sortie du plugin “normal” et sera stocké dans la macro OUTPUT
Tout ce qui est après le caractère pipe est considéré comme les données de performance spécifiques au plugin et sera stocké dans la macro PERFDATA
Dans l'exemple ci-dessus,
PING ok - Perte de paquets = 0%, RTA = 0.80 mspercent_packet_loss = 0, rta = 0,80Le plugin de monitoring peut utiliser toutes les données de performance fournies par les commandes et dont la sortie respectent le formalisme défini ci dessus afin de produire des vues graphiques.
Le plugin monitoring de GLPI propose divers type de graphiques :
Les modèles de graphiques permettent de représenter les données de performance (PERFDATA) sous une représentation graphique
Le monitoring peut-être visualisé en « temps réel » via la remontée des derniers contrôles ou sur une période via les graphiques RRDs.
Le plugin Monitoring fourni un certain nombre de modèles graphiques qu'il est possible d'enrichir.
Pour récupérer l'exemple de perfdata lancer la commande en local pour en récupérer la sortie.
Le modèle peut être intégrer dans un composant cible afin de visualiser en « temps réel » la remontée des derniers contrôles ou sur une période via les graphiques RRDs.
La vue affichée prend en compte les modifications
Le plugin Monitoring de GLPI offre la possibilité à partir des données RRD, dessiner une carte réseau et d'afficher des données de performance. (WEATHERMAP)
En fonction on peut donc avoir une vue en temps réel de l'état d'une architecture réseau du type :
Le processus de création des weathermaps se décompose en 3 étapes :
Les dimensions doivent rester dans les limites de l'affichage standard de 1024×768
* Retourner dans la Weathermap * Pour créer les noeuds sélectionner le type (ex Matériel Réseau) et le nom de l'équipement (ex : sf034_A5500_013SNS1) * Puis cliquer sur **Ajouter** * Répéter cette opération pour ajouter un second noeud
Au minimum deux noeuds doivent être définis pour pouvoir créer un lien
Définir les liens à superviser
L'exemple suivant décrit l'intégration d'une Weathermap :
Modifier les options d'affichage de la vue