Le plugin Monitoring

La documentation officielle est sur le site du plugin : https://forge.indepnet.net/projects/monitoring/files.

Introduction

Le plugin monitoring à pour but "d'intégrer" Shinken à GLPI. En effet grâce à ce plugin Shinken sera paramétrable à partir de GLPI et les alertes seront visibles dans celui-ci ! GLPI devient donc un outil complet d'inventaire, monitoring et gestion d'assistance.

Pré-requis sur le serveur GLPI :

Pour PHP, le module xmlrpc :

apt-get install php5-xmlrpc
service apache2 reload

Pour GLPI : - Plugin Webservices (Permettra de gérer les communications par service web https://forge.indepnet.net/projects/show/webservices)
- Plugin FusionInventory (Qui gère l'inventaire des machines. http://fusioninventory.org/wordpress/) (NOTE : la partie "fusioninventory SNMP" est optionnelle, on peut ne pas cliquer sur "Installer")
- Le plugin monitoring (https://forge.indepnet.net/projects/monitoring)
- Shinken (Peut être installé sur un serveur distant)

Installation

Pour l'installation des plugins, visiter cette page.

Et pour Shinken celle-ci (Debian) ou celle-ci (CentOS) ou http://www.shinken-monitoring.org/wiki/shinken_10min_start pour d'autres systèmes d'exploitation.

Configuration

Comptes

Il faut créer 2 comptes. Un dans GLPI pour permettre à Shinken de se connecter au plugin Webservices afin de récupérer sa configuration, et un dans la base MySql pour lui donner la possibilité d'altérer la base de données (notamment pour les alertes).

Compte GLPI

Créer un compte local GLPI via Administration > Utilisateur.

Compte MySql

"Il faut créer un compte MySQL car le module Broker de Shinken va ajouter et mettre à jour des évènements dans la base de donées."

Connecter à la base

mysql -u root -p glpi
Enter password: 

La documentation nous dit :
"Vous pouvez définir les droits sur toute la base GLPI mais, pour une meilleure sécurité, donnez les droits uniquement aux tables :

• base glpi\glpi_plugin_monitoring_services (SELECT et UPDATE seulement)
• base glpi\glpi_plugin_monitoring_serviceevents (INSERT seulement)
• glpi database\glpi_plugin_monitoring_servicescatalogs (SELECT et UPDATE uniquement)"

GRANT select,update ON glpi_plugin_monitoring_services TO shinkenbroker IDENTIFIED BY 'password';
GRANT insert ON glpi_plugin_monitoring_serviceevents TO shinkenbroker;
GRANT select,update ON glpi_plugin_monitoring_servicescatalogs TO shinkenbroker;
exit

Notez que le premier "GRANT" va aussi créer l'utilisateur shinkenbroker, il doit donc contenir le mot de passe.

Plugin WebServices

Je n'aurais pas pu faire beaucoup mieux que la doc... :

"Configurer les services web de GLPI pour Shinken Dans GLPI, aller dans le menu Plugins > Web Services, et ajouter un nouveau service web. Mettre les valeurs :
• Nom : Shinken
• Services actifs : Oui
• Activer la compression : Non (pas testé avec la compression activée)
• Tracer les connexions : Non (activez le si vous voulez garder une trace des connexions)
• Debug : Non (activer pour le debugging)
• Motif SQL des services : .*
• Plage d'adressage IP : définir une plage IP, dans ce cas, mettre 2 fois la même IP du serveur ou Shinken est installé
• Utilisateur: (laisser vide dans ce cas)
• Mot de passe: (laisser vide dans ce cas)
Cliquer sur le bouton ajouter. Le service web pour Shinken est bien créé et donne accès à Shinken."

Shinken

Il faut paramétrer les daemons Arbiter et Broker pour qu'il puissent, respectivement, se connecter à GLPI et se connecter à la BDD. La configuration des modules se trouve dans le fichier shinken-specific.cfg dans /usr/local/shinken/etc/

Module Arbiter

Ici on ne modifie pas vraiment la configuration de l'arbiter mais on lui ajoute un module, lui fournissant les infos pour se connecter à GLPI. Modifiez le bloc suivant, en fonction de votre configuration

define module{
module_name GLPI
module_type glpi
uri http://localhost/glpi/plugins/webservices/xmlrpc.php
login_name glpi
login_password glpi
tag
}

"Les valeurs à modifier pour votre environnement sont :
• uri: url de GLPI, se termine toujours par /plugins/webservices/xmlrpc.php
• login_name: compte GLPI créé dans "créer des comptes GLPI"
• login_password: mot de passe du compte GLPI
• tag: défini l'étiquette si on l'utilise, sinon laisser vide"

Il faut ensuite ajouter le module a l'Arbiter. Chercher le bloc define arbiter et ajoutez GLPI à la ligne modules. L'arbiter chargera alors le module GLPI à son lancement.

define arbiter {
 modules PickleRetentionArbiter, GLPI
 spare 0
 address localhost
 port 7770
 arbiter_name Arbiter-Master
}

Module Broker

C'est la même chose qu'avec Arbiter sauf qu'on définit cette fois l'accès à la base MySql. Dans shinken-specific.cfg modifier le module glpidb

define module{
module_name glpidb
module_type glpidb
database glpi
user root
password root
host localhost
}

Les valeurs à modifier sont :
• database: nom de la base MySQL de GLPI
• user: compte MySQL créé plus haut (dans notre exemple, c'est shinkenbroker )
• password: mot de passe du compte GLPI
• host: IP ou nom du serveur où le serveur MySQL est installé.

Il faut ensuite ajouter le module au Broker. Chercher le bloc define broker et ajoutez GLPI à la ligne modules.

define broker {
  broker_name broker-1
  data_timeout 120
  check_interval 60
  modules Livestatus, Simple-log, WebUI,NPCDMOD, GLPI
  port 7772
[...]

Objets communs

Par défaut, Shinken charge les object communs comme les commandes, timeperiod, hôtes, services avec ses fichiers locaux. Nous voulons charger la configuration avec GLPI. Pour cela, modifier le fichier nagios.cfg dans /usr/local/shinken/etc/ et commenter les lignes en début de fichier comme suit :

#Configuration files with common objects like commands, timeperiods,
#or templates that are used by the host/service/contacts
#cfg_file=commons.cfg
#cfg_file=commands.cfg
#cfg_file=timeperiods.cfg
#cfg_file=escalations.cfg
#cfg_file=dependencies.cfg
#cfg_file=contacts.cfg
#cfg_dir=/opt/omd/sites/pilot/etc/nagios/conf.d/pilot/dynamic

#Now templates of hosts, services and contacts
#cfg_file=templates.cfg

#Now groups
#cfg_file=servicegroups.cfg
#cfg_file=hostgroups.cfg
#cfg_file=contactgroups.cfg

#and now real hosts, services, packs and
# discovered hosts
#cfg_dir=hosts
#cfg_dir=services
#cfg_dir=packs
#cfg_dir=objects/discovery

# And read triggers from packs too!
#triggers_dir=packs

# Uncomment this for a sample configuration
#cfg_dir=sample

# Some macros
#resource_file=resource.cfg
[...]

Plugin Monitoring

Cette partie permet de créer des configurations qui seront récupérés par le système de monitoring, ici Shinken. On va donc configurer :

• Des Calendriers (sur quelle période monitorer ?) • Des Définitions de contrôle (fréquence des checks) • Des Commandes • Des Composants (quoi monitorer ?) • Un Catalogue de composant regroupant les configurations précédentes + les hôtes que l'ont souhaite monitorer selon ces configurations.

Les Calendriers

Les calendriers sont relativement simples à configurer. Créez un nouveau calendrier, donnez lui un nom et cliquez sur ajouter. Il suffit ensuite d'entrer les périodes sur lesquels vous souhaitez monitorer vos hôtes grâce aux menus déroulants.

Pour accéder aux calendriers et en créer : Monitoring > Calendriers

Note : En raison d'un bug, il faut créer un calendrier nommé '24x7' qui définit un monitoring continu (tous les jours de 00:00 à 24:00), sinon Shinken va le chercher mais ne le trouvera pas. Vous pourrez vous servir de ce calendrier pour monitorer des hôtes constamment.

Les Définitions de contrôles

Les définitions de contrôle vont permettre de définir la 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 nombre de temps entre chaque essai.

On ne peut pas créer de définition de contrôles (Pourquoi ? Bonne question...), il vous faudra donc utiliser et éventuellement modifier les 3 déjà éxistants.

Pour les voir aller dans Monitoring > Définition d'un contrôle.

Les commandes

Ici sont définies toutes les commandes que Shinken va utiliser pour surveiller les hôtes (exemple : ping, requètes http...). Habituellement on ne touche pas à ces configurations. On va juste se servir des objets commandes ici pour les ajouter à notre Catalogue de commandes.

Note : Pour dépannage, les scripts se trouvent dans /usr/local/Shinken/libexec.
Attention : Si vous n'avez pas installé les plugins Nagios, il manquera certaines commandes et elle ne fonctionnerons pas (le check HTTP par exemple).

Les Composants

Les composants sont une association des 3 objets précédents, qui définiront un contrôle avec : • Une commande (ping par exemple) • Un calendrier • Une définition de contrôle

On définit ici seulement quel service, quel matériel on veut checker chez les hôtes. On associera ensuite un ou plusieurs de ces composants à des hôtes, dans le Catalogue de composants.

Pour accéder aux Composants aller sous Monitoring > Commandes.

Les Catalogues de Composants

Et voilà la dernière étape. Un fois les Composants intéressant créés, on les regroupe dans les catalogues de composants, puis on y ajoutera des hôtes. Une fois ceci fait, vos hôtes seront monitorés suivant les contrôles définis dans le catalogue !

Pour commencer, créer un nouveau Catalogue, lui donner un nom puis cliquer sur ajouter. Pour ajouter des Composants au Catalogue, utilisez le menu déroulant sous "Nouvelle fiche" pour sélectionner les composants.

Ajoutez ensuite vos Hôtes via l'onglet Hôtes statiques.

Contacts

Avec cette intégration à GLPI, Shinken ne perd pas sa fonction d'envoie de mails ! Pour pouvoir envoyer des mails sur des alertes il faut :

Définir et assigner un gabarit de contact

L'accès à ce menu se fait par Plugins > Monitoring > Gabarits de contact.

Note : Il faut créer au moins un gabarit par défaut.

Après avoir créé des gabarits, il faut assigner ce gabarit à un compte utilisateur. Pour faire celà, voir l'onglet Monitoring-Contact dans le formulaire utilisateur (menu Administration > Utilisateurs).

Ajouter un contact dans le catalogue

Une fois le gabarit créé et assigné à un utilisateur, il faut ajouter cet utilisateur dans le Catalogue de composants via l'onglet Contacts.

Les mails seront alors envoyé à l'adresse mail définie dans la fiche de l'utilisateur.