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

Par exemple 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 checknwchealth 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 :

1. la mise en oeuvre de collectd
2. la mise en oeuvre de datadomain-monitoring
3. 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 pour activer le font-end 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 ext 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/

Activer le plugin SNMP dans collectd

  <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.xxx"
  Version 2
  Community "public"
  Collect "dd_replication" "dd_systat" "dd_fsspace" "ifmib_if_octets64" "ifmib_if_packets64"
  Interval 60
  </Host>
  </Plugin>

Maintenant il faut ajouter les nouveaux types de données dans collectd. 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 :

On peut également tester le plugin:

  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

Pour Installer le plugin, procéder comme dans l'exemple d'installation précédent

Pour définir un modèle graphique, se reporter à la section du guide pour créer un modèle graphique adapté aux données collecter

Activer l'affichage des données collectées, 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
  Pour 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)
  • Enregistrer la règle

  Le nombre d'hôtes dynamiques doit s'incrémenter dans le menu du catalogue.
  
  Pour tester la règle appuyer sur Rechercher une liste d'hôtes correspondant aux critères de la règle doit s'afficher

Le plugin Monitoring de GLPI permet de notifier automatiquement les changements suivants :

• Notifier quand l'état d'un hôte devient DOWN :
• Notifier quand l'état d'un hôte devient UNREACHABLE :
• Notifier quand 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
  #### Créer un gabarit de contact

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 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,

• la macro OUTPUT contiendrait : PING ok - Perte de paquets = 0%, RTA = 0.80 ms

  1. la macro PERFDATA contiendrait : percentpacketloss = 0, rta = 0,80

  ### Enrichissement des graphiques

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 :

• Les diagrammes des métriques
• 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.

Pour créer un modèle graphique:

• 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
• Sélectionner le menu Modèle de graphique
• Créer le nouveau modèle en appuyant sur +
  • Indiquer Nom et Exemple de perfdata pour ce contrôle.
  • Puis cliquer sur Ajouter

Maintenant il faut Ajuster le nouveau modèle, en renseignant les champs des valeurs parsées sur la ligne de commande pour indiquer un libellée humainement interprétable.

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.

Intégrer le modèle dans le composant cible:

• 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
  • La prévisualisation est alors activée

Maintenant il faut 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 doit prendre 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
  

Pour 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 (Les dimensions doivent rester dans les limites de l'affichage standard de 1024×768)

Définir les équipements (noeuds):

• 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

Ajouter une vue :

• 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

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 enregistrer 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
• Enregistrer les modifications

Mesure le PreCompBytesRemaining de chaque contexte de réplication afin de surveiller la quantité de données en attente de réplication. Si cette valeur ne retourne pas à zéro, il y à un problème de réplication.

Ligne de commande dans GLPI

  collectd-nagios -s /var/run/collectd-unixsock -n snmp/dd_replication-$ARG1$ -H dd4200.sns.dgfip

Les paramètres sont à adaptés selon la syntaxe propre au démon collectd (/etc/collectd.conf)

https://collectd.org/documentation/manpages/collectd.conf.5.shtml

Ce plugin surveille certains états d'un datadomain via snmp. Il peut surveiller par exemple l'état des PSU, NVRAM, disques et ainsi de suite.

  check_datadomain -H [-C ] [-p ] [-P ] -m ( FSSPACE [-w <warning % USED>] [-c <critical % USED>] | IFSTATE -i )

Ligne de commande sans GLPI

  $PLUGINSDIR$/check_datadomain -H $HOSTADDRESS$ -C $ARG1$ -m $ARG2$

Ce plugin permet de surveiller un périphérique réseau (routeur, commutateur, serveur, par exemple) sans connaître chaque interface en détail. Seul le nom d'hôte (ou l'adresse IP) et la chaîne de communauté snmp sont requis.

L'objectif de conception principal de ce plugin est de surveiller un périphérique réseau avec un plugin. Il est optimisé pour la vitesse et permet de surveiller de grands réseaux avec des centaines de commutateurs et de routeurs.

Les systèmes de serveur comme Unix, Windows, réseau peuvent également être surveillés. D'une manière plug and play, il parcourt beaucoup de mibs snmp et stocke toutes les propriétés de l'interface dans une jolie table. Si quelqu'un modifie les propriétés de l'interface, le plugin le reconnaît et affiche ces changements.

  ./check_interface_table_v2.pl -H server1 -C public

Ligne de commande dans GLPi

  $PLUGINSDIR$/check_interface_table_v2/check_interface_table_v2.pl -H $HOSTADDRESS$ -C $ARG1$ -HTMLDir '/var/www/html/interfacetable' -HTMLUrl 'http://xx.xx.xxx.xx/interfacetable/'

Ce plugin permet de vérifier par snmp v1, v2c ou v3 l'état des interfaces d'un hôte, leur utilisation (bande passante, erreurs, pertes) et sortir des informations de performances.

  ./check_snmp_int.pl [-v] -H <host> -C <snmp_community> [-2] | (-l login -x passwd [-X pass -L <authp>,<privp>) [-p <port>] -n <name in desc_oid> [-i -a -D] [-r] [-f[eSyY]] [-k[qBMGu] -g -w<warn levels> -c<crit levels> -d<delta>] [-o <octet_length>] [-t <timeout>] [-s] --label [-V]

Ligne de commande dans GLPI

  $PLUGINSDIR$/check_snmp_int -H $HOSTADDRESS$ -C $ARG1$ -n $ARG2$ -k -w 200,250 -c 0,350 -d 600 --label -G -t 60 -f -S -Y

Ce plugin est utilisé pour surveiller la santé du matériel (CPU, mémoire, alimentation, ventilateurs, température) et l'utilisation des composants réseau.

À l'origine, il était écrit pour vérifier l'utilisation de l'interface et la santé du matériel (CPU, mémoire, alimentation, ventilateurs, température) des commutateurs Cisco. Aujourd'hui, il couvre les principaux fabricants.

check_nwc_health [ -v|--verbose ] [ -t <timeout> ] --mode <what-to-do> --hostname <network-component> --community <snmp-community> ...]

Ligne de commande dans GLPI

$PLUGINSDIR$/check_nwc_health --hostname $HOSTADDRESS$ --community $ARG1$ --mode $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$

Options du paramètre mode