inlinetoc

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 :

• utiliser n'importe quel plugin NAGIOS, puis traiter les résultats.
• utiliser n'importe quel script/exécutable qui fournisse un résultat respectant le formalisme de NAGIOS

Deux exemples d'intégration seront détaillés:

• celui d'un plugin Nagios
• celui d'un plugin autonome

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

• Le Nom : Check nwc int
• Le Nom de commande : check_nwc_health992224191
• La Ligne de commande : $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$

• la communauté SNMP $ARG1$
• le mode $ARG2$
• l'interface $ARG3$

Retourner dans la commande pour indiquer les libellés à chacun d'eux

puis Sauvegarder

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 :

• la mise en oeuvre de collectd
• la mise en oeuvre de datadomain-monitoring
• l'intégration du plugin dans GLPI

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 :

• un frontend web qui permet une présentation graphique des fichiers RRD.
• le plugin collect-nagios qui permet de mettre en forme les données collectées à destination de NAGIOS

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 :

• l'intégration de la MIB du DATADOMAIN
• l'activation du plugin SNMP dans collectd
• l'ajout de nouveaux types de données dans collectd

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

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

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 : •

• Une commande (ping par exemple)
• Un calendrier (jours et plage horaire)
• Une définition de contrôle ( fréquence a laquelle les contrôles sont effectués, au bout de combien d'essais un service ou un hôte est déclaré “down” et le temps entre chaque essai). On définit ici seulement quel service, quel matériel on veut monitorer chez les hôtes selon quel calendrier et à quelle fréquence. On associera ensuite un ou plusieurs de ces composants à des hôtes, dans le Catalogue de composants.

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 /

• Si le modèle de l'équipement et HP 5500 EI alors l'équipement est automatiquement rajouté au catalogue
  ### Ajouter une rêgle

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

• Sélectionner la caractéristique de l'équipement à analyser
• Sélectionner l'opérateur (contient / est/ n'est pas)
• Sélectionner ou saisir le contenu de la caractéristique (ici le modèle)

  ### 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 :

• Notifier quant l'état d'un hôte devient DOWN :
• Notifier quant l'état d'un hôte devient UNREACHABLE :
• Notifier quant un hôte redevient normal (état OK) :
• Notifier quand l'état des hôtes commencent et arrêtent d'osciller :
• Notifier lorsque l'arrêt programmé de l'hôte commence et se termine:
• L'utilisateur ne va pas recevoir de notifications de type hôte :

La chaîne de notification repose sur 3 objets :

• Gabarit de contact
• Host notifications template
• Commande de notification

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

• Activer la notification pour les hôtes
• Renseigner la période
• Renseigner les éléments à notifier par défaut
  Sauvegarder le 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

• Activer la notification
• Renseigner la période
• Choisir les éléments déclencheurs

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

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:

• Données de performance de contrôle
• Données de performance du plugin

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,

1. la macro OUTPUT contiendrait : PING ok - Perte de paquets = 0%, RTA = 0.80 ms
2. la macro PERFDATA contiendrait : percent_packet_loss = 0, rta = 0,80

Le 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 :

1. Les diagrammes des métriques
2. Les cartes des Weathermap

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.

• Entrer dans le menu système du plugin =
• Sélectionner le menu Modèle de graphique, puis appuyer sur +
• Indiquer Nom et Exemple de perfdata pour ce contrôle.
• Puis cliquer sur Ajouter
• Renseigner les champs des valeurs parsées sur la ligne de commande pour indiquer un libellée humainement interprétable.

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.

• Dans Gabarit (pour la génération des graphiques) sélectionner le modèle graphique à utiliser

  • Activer la génération de graphiques
    • Dans la vue Métriques la prévisualisation n'affiche pas encore le graphique
    • Pour activer la génération graphique entrer dans le graphique
  • Adapter les graphiques, Dans le graphique aller dans Options et adapter les informations pour n'afficher que les valeurs significative et des libellés significatifs
  • Sauvegarder le modifications

  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 :

• Ajout d'une Weathermap
• Ajout des noeuds qui représentent les équipements
• Ajout d'un liens entre ces équipements
  #### Créer une Weathermap
• Dans la vue par défaut du plugin Monitoring appuyer sur = pour accéder à la vue système
• Dans le menu appuyer sur + pour ajouter un nouvel objet
• Donner un Nom et définir les dimensions de l'image qui sera générée

* 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

Définir les liens à superviser

• Ajouter un lien entre les deux équipements (noeuds)
• Pour créer un lien indiquer :
  • le noeud source (un interface)
  • Le noeud cible
  • La bande passante (1G, 100M)
• Puis cliquer sur Ajouter

L'exemple suivant décrit l'intégration d'une Weathermap :

• Dans une vue spécialement créée
• Dans le tableau de bord

• Dans la vue par défaut du plugin Monitoring appuyer sur = pour accéder à la vue système
• Dans le menu Vues appuyer sur + pour créer une nouvelle vue
  • Indiquer le nom
  • Activer l'affichage de la vue dans le dashboard (vue frontale)
  • Pour enrichir la vue de compteurs choisir les compteurs
  • Activer la vue
• Puis cliquer sur ajouter
• Pour sélectionner les items à afficher, retourner dans la vue créée et dans le menu items ajouter les items à afficher :
  • Choisir le type de l'item
  • Choisir l'item à afficher
• Puis enregister la vue

Modifier les options d'affichage de la vue

• Retourner dans la vue pour :
  • Activer l'affichage de la vue dans le tableau de bord

    • Enregister les modifications