GLPI est une solution open-source de gestion de parc informatique et de servicedesk, GLPI (Gestion Libre de Parc Informatique) est une application Full Web pour gérer l'ensemble des problématiques de gestion de parc informatique : de la gestion de l'inventaire des composantes matérielles ou logicielles d'un parc informatique à la gestion de l'assistance aux utilisateurs :
Le plugin de supervision Monitoring pour GLPI permet d'intégrer SHINKEN pour :
Il permet de paramétrer depuis celui-ci les éléments essentiels de la supervision par SHINKEN :
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.
Installer le module xmlrpc pour PHP:
yum install xmlrpc service apache2 reload
Installer Mongodb:
vi /etc/yum.repos.d/mongodb-org-4.4.repo [mongodb-org-4.4] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.4/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc
sudo yum install -y mongodb-org systemctl enable mongod systemctl start mongod
Installer Shinken:
git clone https://github.com/naparuba/shinken yum install git cd shinken ./install -i && ./install -p nagios-plugins && ./install -a pnp4nagios ln -s /usr/local/shinken/etc /etc/shinken ln -s /bin/mail /usr/bin/mail cd /etc/shinken/
Installer la Webui2:
pip install -r https://raw.githubusercontent.com/shinken-monitoring/mod-webui/develop/requirements.txt shinken install webui2 htpasswd -c /etc/shinken/htpasswd.users admin
Installer le “vrai” paquet nagios-plugins, et copier ceux-ci dans le répertoire utilisé pour les plugins de Shinken.
yum install nagios-plugins-all cp -u /usr/lib*/nagios/plugins/* /usr/local/shinken/libexec/ chown shinken.shinken /usr/local/shinken/libexec/* chmod 755 shinken.shinken /usr/local/shinken/libexec/*
Pour que l'authentification par fichier htpasswd soit prise en compte, il faut dé-commenter la ligne contenant le paramètre htpasswd_file dans /etc/shinken/modules/webui2.cfg
Installer les plugins NRPE:
yum install nagios-plugins-nrpe cp /usr/lib*/nagios/plugins/check_nrpe /usr/local/shinken/libexec/ chown shinken.shinken /usr/local/shinken/libexec/* chmod 755 /usr/local/shinken/libexec/*
Il faut installer:
Pour installer un plugin dans GLPI, il suffit de télécharger son archive puis de l'extraire dans le dossier …/glpi/plugins, et de l'installer via l'interface de GLPI.
cd /var/www/glpi/plugins wget https://github.com/ddurieux/glpi_monitoring/releases/download/0.90%2B1.1/glpi_monitoring_0.90.1.1.tar.gz tar -xvzf glpi_monitoring_0.90.1.1.tar.gz rm glpi_monitoring_0.90.1.1.tar.gz wget https://github.com/fusioninventory/fusioninventory-for-glpi/releases/download/glpi090%2B1.3/fusioninventory-for-glpi_0.90.1.3.tar.gz tar -xvzf fusioninventory-for-glpi_0.90.1.3.tar.gz rm fusioninventory-for-glpi_0.90.1.3.tar.gz wget https://forge.glpi-project.org/attachments/download/2263/glpi-webservices-1.9.0.tar.gz tar -xvzf glpi-webservices-1.9.0.tar.gz rm glpi-webservices-1.9.0.tar.gz chown -R www-data.www-data *
Certains plugin comme FusionInventory sont composés de plusieurs modules. En règle général l'ordre dans lequel on doit installer et activer ces modules est indiqué directement dans l'interface de Configuration des plugins de GLPI.
Ensuite, dans l'interface GLPI, aller sous Configuration > Plugins cliquer sur Installer puis Activer.
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).
Administration > UtilisateurSe connecter à la base
mysql -u root -p glpi Enter password:
On peut définir les droits sur toute la base GLPI, ou pour une meilleure sécurité, donner les droits uniquement aux tables :
- base glpi\glpipluginmonitoringservices (SELECT et UPDATE seulement)
- base glpi\glpipluginmonitoringserviceevents (INSERT seulement)
- glpi database\glpipluginmonitoring_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
Le premier “GRANT” va aussi créer l'utilisateur shinkenbroker, il doit donc contenir le mot de passe.
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 :
Cliquer sur le bouton ajouter. Le service web pour Shinken est bien créé et donne accès à 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/
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 :
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
}
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 :
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
[...]
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 [...]
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 :
Les calendriers sont relativement simples à configurer. Créer un nouveau calendrier, lui donner un nom et cliquer sur ajouter. Il suffit ensuite d'entrer les périodes sur lesquels on souhaite monitorer less hôtes grâce aux menus déroulants.
Pour accéder aux calendriers et en créer : Monitoring > Calendriers
En raison d'un bug, il faut créer un calendrier nommé '24×7' qui définit un monitoring continu (tous les jours de 00:00 à 24:00), sinon Shinken va le chercher mais ne le trouvera pas. VOn peut se servir de ce calendrier pour monitorer des hôtes constamment.
Les calendriers définissent les périodes pour monitorer les hôte :
Un objet calendrier décrit :
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, il faudra donc utiliser et éventuellement modifier les 3 déjà éxistants.
Pour les voir aller dans Monitoring > Définition d'un contrôle.
Pour créer un nouvel élément de calendrier:
Renseigner les éléments de planification
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 au Catalogue de commandes.
Les scripts se trouvent dans /usr/local/Shinken/libexec.
Il est préférable de tester les commandes localement afin de voir si cela fonctionne bien. Par exemple
user@shinken:~$./check_snmp_storage.pl -H 127.0.0.1 -C public -m / -w 80% -c 90% -G\\ /dev: 0%used(0GB/0GB) /: 20%used(11GB/57GB) (<80%) : OK
Si on n'a pas installé les plugins Nagios, il manquera certaines commandes et elle ne fonctionnerons pas (le check HTTP par exemple).
Les composants sont une association des 3 objets précédents, qui définiront un contrôle avec :
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 composants sont une association de 3 objets, qui définiront un contrôle avec :
- La commande à exécuter et ses arguments (ping par exemple)
- Définition d'un contrôle (le délai entre deux contrôles))
- La période 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).
Example of perfdata for this control et Enregistrer. Le plugin va générer un nouveau modèle.
Certains arguments passés par une commande peuvent être variabilisés dans l'objet commande (cf guide avancé)
Il est possible d'utiliser des mots-clefs (tags)
Ces tags représentent des valeurs qui seront récupérées dans les informations de l'hôte afin de servir l'argument concerné:
- [[HOSTNAME]] : Nom du matériel
- [[IP]] : IP du matériel
- [[NETWORKPORTNUM]] : Numéro de port réseau
- [[NETWORKPORTNAME]] : Nom de port réseau
- [[NETWORKPORTDESCR]] : Port réseau ifDescr des matériels réseaux
- [SNMP:version] : Version SNMP de l'équipement réseau ou imprimante
- [SNMP:authentication] : Communauté SNMP de l'équipement réseau ou imprimante
Ainsi le tag [SNMP:authentication] va passer en argument la communaté SNMP (pour équipement réseau uniquement)
Si le composant fourni des informations de perfdata (cf . guide utilisateur avancé) renseigner les informations permettant de formater ces informations si l'on souhaite les utiliser dans un WeatherMap.
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, les hôtes seront monitorés suivant les contrôles définis dans le catalogue ! Configurer le catalogue de composants
Un catalogue de composant décrit pour un processus de monitoring :
- la listes des hôtes
- la liste des composants
- la liste des contacts
Mettre à jour le catalogue en indiquant les composants
Une fois le catalogue défini, Shinken devrait normalement redémarrer automatiquement.
Retourner dans le catalogue ainsi créer pour vérifier la présence de tous les éléments .
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.
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).
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.
Les plugins nagios (et donc les commandes) ont été normalement installés avec Shinken.
Toutes les commandes fournies par Shinken ne sont pas définies dans le plugin glpi_monitoring.
Tableau comparatif des commandes NAGIOS/PLUGIN MONITORING
| N° | Commande GLPI | Commande SHINKEN | Détail | |
|---|---|---|---|---|
_echo | ||||
_internal_host_up | _internal_host_up | |||
| 3 | Business rules | bp_rule | bp_rule | |
check_dig|``$NAGIOSPLUGINSDIR$/check_dig -H $HOSTADDRESS$ -l $ARG1$ | ||||
check_host_alive | $NAGIOSPLUGINSDIR$/check_ping -H $HOSTADDRESS$ -w 1000,100% -c 3000,100% -p 1 | |||
check_nrpe | $NAGIOSPLUGINSDIR$/check_nrpe -H $HOSTADDRESS$ -t 9 -u -c $ARG1$ | |||
check_nrpe_args | $NAGIOSPLUGINSDIR$/check_nrpe -H $HOSTADDRESS$ -t 9 -u -c $ARG1$ -a $ARG2$ $ARG3$ $ARG4$ $ARG5$ | |||
check_ping | $NAGIOSPLUGINSDIR$/check_icmp -H $HOSTADDRESS$ -w 3000,100% -c 5000,100% -p 10 | |||
check_snmp_service | $NAGIOSPLUGINSDIR$/check_snmp_service -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ | |||
check_snmp_storage | $NAGIOSPLUGINSDIR$/check_snmp_storage.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -m $ARG1$ -f -w $ARG2$ -c $ARG3$ -S0,1 -o 65535 | |||
check_snmp_time | $NAGIOSPLUGINSDIR$/check_snmp_time.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -f -w $ARG1$ -c $ARG2$ | |||
check_tcp | $NAGIOSPLUGINSDIR$/check_tcp -H $HOSTADDRESS$ -p $ARG1$ | |||
configuration-check|sudo /etc/init.d/shinken check | ||||
detailled-host-by-email | $PLUGINSDIR$/notify_by_email.py -n host -S localhost -r $CONTACTEMAIL$ -f html -c "$NOTIFICATIONTYPE$,,$HOSTNAME$,,$HOSTADDRESS$,,$LONGDATETIME$"" -o ""$HOSTSTATE$,,$HOSTDURATION$" -d "$_HOSTDETAILLEDDESC$" -i "$_HOSTIMPACT$" | |||
detailled-service-by-email | $PLUGINSDIR$/notify_by_email.py -n service -S localhost -r $CONTACTEMAIL$ -f html -c "$NOTIFICATIONTYPE$,,$HOSTNAME$,,$HOSTADDRESS$,,$LONGDATETIME$" -o "$SERVICEDESC$,,$SERVICESTATE$,,$SERVICEOUTPUT$,,$SERVICEDURATION$" -d "$_SERVICEDETAILLEDESC$" -i "$_SERVICEIMPACT$" -a "$_SERVICEFIXACTIONS$" | |||
notify-host-by-android-sms|android_sms $CONTACTPAGER$ Host: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: $HOSTSTATE$\nInfo: $OUTPUT$\nDate: $DATETIME$ | ||||
notify-host-by-email | $PLUGINSDIR$/notify_by_email.py -n host -S localhost -r $CONTACTEMAIL$ -f html -c "$NOTIFICATIONTYPE$,,$HOSTNAME$,,$HOSTADDRESS$,,$LONGDATETIME$" -o "$HOSTALIAS$,,$HOSTSTATE$,,$HOSTDURATION$" | |||
notify-host-by-xmpp | $PLUGINSDIR$/notify_by_xmpp.py -a $PLUGINSDIR$/notify_by_xmpp.ini "Host '$HOSTNAME$' is $HOSTSTATE$ - Info : $HOSTOUTPUT$" $CONTACTEMAIL$ | |||
notify-service-by-android-sms|android_sms $CONTACTPAGER$ Service: $SERVICEDESC$\nHost: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\nInfo: $OUTPUT$\nDate: $DATETIME$ | ||||
notify-service-by-email | $PLUGINSDIR$/notify_by_email.py -n service -S localhost -r $CONTACTEMAIL$ -f html -c "$NOTIFICATIONTYPE$,,$HOSTNAME$,,$HOSTADDRESS$,,$LONGDATETIME$" -o "$SERVICEDESC$,,$SERVICESTATE$,,$SERVICEOUTPUT$,,$SERVICEDURATION$" | |||
notify-service-by-xmpp | $PLUGINSDIR$/notify_by_xmpp.py -a $PLUGINSDIR$/notify_by_xmpp.ini "$NOTIFICATIONTYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ $SERVICEOUTPUT$ $LONGDATETIME$" $CONTACTEMAIL$ | |||
| 12 | Check local disk | pm-check-host-alive | $PLUGINSDIR$/check.sh $HOSTADDRESS$ -c $ARG1$ SERVICE $USER1$ | |
| 11 | Check local cpu | pm-check_cpu_usage | $PLUGINSDIR$/check_cpu_usage -w $ARG1$ -c $ARG2$ | |
| 4 | Check a DNS entry | pm-check_dig | $PLUGINSDIR$/check_dig -H $HOSTADDRESS$ -l $ARG1$ | |
| 6 | Check disk | pm-check_disk | $PLUGINSDIR$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ | |
| 17 | Dummy check | pm-check_dummy | $PLUGINSDIR$/check_dummy $ARG1$ "$ARG2$" | |
| 18 | ESX hosts checks | pm-check_esx_host | $PLUGINSDIR$/check_esx3.pl -D $VCENTER$ -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p $VCENTERPASSWORD$ l $ARG1$ | |
| 19 | ESX VM checks | pm-check_esx_vm | $PLUGINSDIR$/check_esx3.pl -D $VCENTER$ -N $HOSTALIAS$ -u $VCENTERLOGIN$ -p $VCENTERLOGIN$ -l $ARG1$ | |
| 5 | Check a FTP service | pm-check_ftp | $PLUGINSDIR$/check_ftp -H $HOSTADDRESS$ | |
| 7 | Check host alive (ICMP) | pm-check_host_alive | $NAGIOSPLUGINSDIR$/check_icmp -H $HOSTADDRESS$ -w 1000,100% -c 3000,100% -p 1 | |
pm-check_hpjd | $PLUGINSDIR$/check_hpjd -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ | |||
pm-check_http | $PLUGINSDIR$/check_http -H $HOSTADDRESS$ | |||
pm-check_https | $PLUGINSDIR$/check_http -H $HOSTADDRESS$ -S | |||
pm-check_https_certificate | $PLUGINSDIR$/check_http -H $HOSTADDRESS$ -C 30 | |||
pm-check_ldap | $PLUGINSDIR$/check_ldap -H $HOSTADDRESS$ -b "$LDAPBASE$" -D $DOMAINUSER$ -P "$DOMAINPASSWORD$" | |||
pm-check_ldaps | $PLUGINSDIR$/check_ldaps -H $HOSTADDRESS$ -b "$LDAPBASE$" -D $DOMAINUSER$ -P "$DOMAINPASSWORD$" | |||
pm-check_linux_host_alive | $PLUGINSDIR$/check_tcp -H $HOSTADDRESS$ -p 22 -t 3 | |||
| 10 | Check load | pm-check_load | $PLUGINSDIR$/check_load -r -w $ARG1$ -c $ARG2$ | |
pm-check_mssql_connexion | $PLUGINSDIR$/check_mssql_health --hostname $HOSTADDRESS$ --username "$MSSQLUSER$" --password "$MSSQLPASSWORD$" --mode connection-time | |||
| 16 | Distant mysql check | pm-check_mysql_connexion | $PLUGINSDIR$/check_mysql -H $HOSTADDRESS$ -u $MYSQLUSER$ -p $MYSQLPASSWORD$ | |
| 1 | Ask a nrpe agent | pm-check_nrpe | $NAGIOSPLUGINSDIR$/check_nrpe -H $HOSTADDRESS$ -t $ARG1$ -u $ARG2$ -c $ARG3$ | |
| 2 | Ask a nrpe agent with arguments | pm-check_nrpe_args | $NAGIOSPLUGINSDIR$/check_nrpe -H $HOSTADDRESS$ -t $ARG1$ -u $ARG2$ -c $ARG3$ -a $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$ | |
pm-check_oracle_listener | $PLUGINSDIR$/check_oracle --tns $HOSTADDRESS$ | |||
| 8 | Check host alive (ping) | pm-check_ping | $NAGIOSPLUGINSDIR$/check_ping -H $HOSTADDRESS$ -w 3000,100% -c 5000,100% -p 1 | |
pm-check_smtp | $PLUGINSDIR$/check_smtp -H $HOSTADDRESS$ | |||
pm-check_smtps | $PLUGINSDIR$/check_smtp -H $HOSTADDRESS$ -S | |||
| 13 | Check snmp | pm-check_snmp | $PLUGINSDIR$/check_snmp -H $HOSTADDRESS$ -P $ARG1$ -C $ARG2$ -o $ARG3$,$ARG4$,$ARG5$,$ARG6$,$ARG7$,$ARG8$,$ARG9$,$ARG10$ | |
pm-check_ssh | $PLUGINSDIR$/check_ssh -H $HOSTADDRESS$ | |||
| 9 | Check Linux host alive | pm-check_tcp | $PLUGINSDIR$/check_tcp -H $HOSTADDRESS$ -p $ARG1$ | |
| 14 | Check users connected | pm-check_users | $PLUGINSDIR$/check_users -w $ARG1$ -c $ARG2$ | |
| 15 | Check Windows host alive | pm-check_windows_host_alive | $PLUGINSDIR$/check_tcp -H $HOSTADDRESS$ -p 139 -t 3 | |
pm-detailled-host-by-email | /usr/bin/printf "%b" "Shinken Notification\n\nType:$NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nDate/Time: $DATE$/$TIME$\n Host Output : $HOSTOUTPUT$\n\nHost description: $_HOSTDESC$\nHost Impact: $_HOSTIMPACT$" | /usr/bin/mail -s "Host $HOSTSTATE$ alert for $HOSTNAME$" $CONTACTEMAIL$ |
||
pm-detailled-service-by-email | /usr/bin/printf "%b" "Shinken Notification\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $DATE$ at $TIME$\nService Output : $SERVICEOUTPUT$\n\nService Description: $_SERVICEDETAILLEDESC$\nService Impact: $_SERVICEIMPACT$\nFix actions: $_SERVICEFIXACTIONS$" | /usr/bin/mail -s "$SERVICESTATE$ on Host : $HOSTALIAS$/Service : $SERVICEDESC$" $CONTACTEMAIL$ |
||
| 20 | Host action | pm-host_action | host_action | |
pm-notify-host-by-email | /usr/bin/printf "%b" "Shinken Notification\n\nType:$NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\nDate/Time: $DATE$ $TIME$\n" | /usr/bin/mail -s "Host $HOSTSTATE$ alert for $HOSTNAME$" $CONTACTEMAIL$ |
||
pm-notify-host-by-email-py | $PLUGINSDIR$/send_mail_host.py -n "$NOTIFICATIONTYPE$" -H "$HOSTALIAS$" -a "$HOSTADDRESS$" -i "$SHORTDATETIME$" -o "$HOSTOUTPUT$" -t "$CONTACTEMAIL$" -r "$HOSTSTATE$" -S shinken@localhost | |||
pm-notify-host-by-xmpp | $PLUGINSDIR$/notify_by_xmpp.py -a $PLUGINSDIR$/notify_by_xmpp.ini "Host $HOSTNAME$ is $HOSTSTATE$ - Info : $HOSTOUTPUT$" $CONTACTEMAIL$ | |||
pm-notify-service-by-email | /usr/bin/printf "%b" "Shinken Notification\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $DATE$ $TIME$\nAdditional Info : $SERVICEOUTPUT$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ alert - $HOSTNAME$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ |
||
pm-notify-service-by-email-py | $PLUGINSDIR$/send_mail_service.py -s "$SERVICEDESC$" -n "$NOTIFICATIONTYPE$" -H "$HOSTALIAS$" -a "$HOSTADDRESS$" -i "$SHORTDATETIME$" -o "$SERVICEOUTPUT$" -t "$CONTACTEMAIL$" -r "$SERVICESTATE$" -S shinken@localhost | |||
pm-notify-service-by-xmpp | $PLUGINSDIR$/notify_by_xmpp.py -a $PLUGINSDIR$/notify_by_xmpp.ini "$NOTIFICATIONTYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICESTATE$ $SERVICEOUTPUT$ $LONGDATETIME$" $CONTACTEMAIL$ | |||
reload-shinken | nohup sh -c '/etc/init.d/shinken reload' > /dev/null 2>&1 & | |||
restart-shinken | nohup sh -c '/etc/init.d/shinken restart' > /dev/null 2>&1 & | |||
restart_shinken | nohup sh -c '/usr/local/shinken/bin/stop_arbiter.sh && sleep 3 && /usr/local/shinken/bin/launch_arbiter.sh' > /dev/null 2>&1 & |
Afin d'utiliser un chemin relatif dans la ligne de commande renseigner le $PATH dans: SHINKEN_DIR/resource.d/paths.cfg (sur le serveur Shinken).
Shinken est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes vont mal et quand ils vont mieux. C'est un logiciel libre sous licence GNU AGPL. Elle est complètement compatible avec le logiciel Nagios et elle a pour but d'apporter une supervision distribuée et hautement disponible facile à mettre en place. Démarrée comme une preuve de concept pour Nagios sur les architectures distribuées.
À la suite d'un refus en décembre 2009 des développeurs de Nagios de voir Shinken devenir la nouvelle branche de développement de Nagios dans le futur, Shinken peut désormais être considéré comme un projet indépendant de système de surveillance système et réseau
Shinken prend en charge l'importation d'hôtes de GLPI. Les hôtes importés de GLPI seront traités comme des hôtes standard à partir de fichiers plats (héritage, groupes, etc.).
En fait, le plugin monitoring de GLPI permet d'offrir un interface d'administration graphique à SHINKEN (les modules WEB de celui-ci n'ontr qu'une approche utilisateur). Mais on peut toujours avoir des fichiers plats ET GLPI pour administrer SHINKEN.
L'interface est accessible à l'adresse http://xx.xx.xxx.xxx:7767
Dans le menu configuration de SHINKEN on peut rapidement voir les limites de celui-ci puisqu'il ne permet pas d'ajouter des éléments de configuration, mais juste de les visualiser.
Dans SHINKEN la configuration est faite dans les fichiers plats de l'application.
En fait le plugin Monitoring de GLPI permet la configuration et l'exécution planifiée de SHINKEN, mais il fait écran :
Pour ces raisons il est inintéressant d'utiliser le GUI de SHINKEN.
La définition des commandes est réalisée dans GLPI ou à partir de fichiers à plat. Mais il est préférable de mettre au poit les commandes en les testant depuis SHINKEN