julien michaud · 2018. 9. 5. · le tutoriel suivant explique comment installer la version 2.4 du...

1

Julien

Michaud

J’ai eu comme tâche d’installer Shinken sur une machine Debian et de monitorer différents

équipements comme des ordinateurs LINUX, routeurs, switch et différents services.

Ce qui différencie Shinken de son aîné Nagios n'est pas tant le langage de programmation utilisé que

son architecture, qui repose sur le principe Unix : à une tâche un outil. C'est pour cette raison que

Shinken n'est pas monolithique comme Nagios, mais utilise six processus différents qui travaillent

ensemble et permettent d'obtenir une flexibilité bien supérieure au Nagios originel.

C'est cette architecture qui permet d'obtenir la mise en place facile d'une supervision distribuée : un

processus s'occupe de lire la configuration de l'utilisateur et la découpe intelligemment (en

respectant les relations entre les éléments) afin de distribuer les morceaux vers des processus

chargés d'absorber la charge de supervision. De cette manière, en cas de nouvelle charge,

l'utilisateur peut rajouter des processus sans avoir à modifier sa configuration en profondeur. C'est

un lissage de charge automatique.

C'est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de katana très

tranchant, représente l'objectif du projet, à savoir de découper la configuration pour la renvoyer sur

des daemons.

2

Sommaire :

1.Principes de fonctionnement

2. Installation de shinken

3. Installation de Webui2

4. Monitorer l’hôte shinken avec SSH

5. Monitorer des hôtes LINUX avec SNMP

6. Monitorer un routeur

7. Monitorer un switch

8. Monitorer serveur ESXi

9. Monitorer hôte WIndows

10. Monitorer imprimante

11. Conclusion

12. Bibliographie

3

1. Principes de fonctionnement

Shinken se découpe en 6 modules :

L’arbitre (Arbiter) : Il est responsable de la validation et du chargement de la configuration, la

découpe en différentes parties (N ordonnanceurs = N parties), et l’envoie aux autres éléments. Il gère

également la haute disponibilité : si un élément devient injoignable, il redirige la configuration sur un

autre. Il ne peut y en avoir qu’un seul actif dans l’architecture avec des "spare" aux fins de relève.

L’ordonnanceur (Scheduler) : Il est chargé d’ordonnancer les checks, d’analyser leurs résultats et de

déclencher une action en fonction de ces derniers si c’est nécessaire. Ce n’est pas lui qui lance les

checks ou les notifications, il ne fait que rediriger les informations. Il garde juste dans une file

d’attente les checks en attentes (pending) et notification pour les autres éléments (collecteurs ou

"Réactionneur"). Il peut y avoir plusieurs ordonnanceurs, c'est d'ailleurs conseillé.

Le collecteur (Poller) : Son rôle est de lancer les plugins en fonction des requêtes des ordonnanceurs.

Ces plugins, qui peuvent être ceux de Nagios, vont aller interroger le système surveillé et retourner

un résultat indiquant l'état. Lorsqu’un plugin renvoie un résultat, il le transmet à l’ordonnanceur. Il

peut y avoir plusieurs collecteurs.

Le « réactionneur » (Reactionner) : il est chargé de l'envoi des notifications et de lancer les «

event_handlers » (action automatique programmable). Il peut en voir autant que l’administrateur en

veut.

Le « courtier » (Broker) : Son rôle est de prendre des données sur les schedulers (comme les statuts

par exemple) et de les rendre disponibles à l'externe de Shinken. Il fonctionne avec des modules. Il

existe plusieurs de ces modules : export dans une base NDO, exporter vers une base de donnée

Graphite, API interactif Livestatus, export vers syslog et autres modules. Un seul broker par Scheduler

ou 1 broker pour multiples schedulers.

Le « receveur » (Receiver) : Son rôle est de recevoir les données d'acquisition passive et de les acheminer vers le bon scheduler responsable de faire la corrélation et le traitement des statuts. Il possède divers modules d'Acquisition tels que NSCA, TSCA, Service Web, Command Pipe et autres. Il peut y avoir plusieurs receveurs.

Les fichiers services et commands nous intéresseront le plus pour ce REX. Services : Les services correspondent aux différents tests / sondes : on test le bon fonctionnement d'un service. Conf : /etc/shinken/services/*.cfg Pour chaque service on définit l'hôte ou le groupe d'hôtes concerné (grâce à “host_name” ou “hostgroup_name”). Le but n'est pas de décrire comment effectuer le test ici (quelle commande utiliser…) mais plutôt de donner le nom du test à réaliser (la check_command) avec éventuellement des paramètres *séparés par un point d'exclamation*.

4

Structure :

Commands : Les services ne sont pas faits pour décrire de quel façon réaliser un test, mais plutôt quel test à

effectuer. La partie plus technique du test se trouve dans ce fichier de conf :

/etc/shinken/commands.cfg (Il est possible de créer un fichier .cfg pour chaque hôte, ce que nous

ferons pour ce REX)

La structure est très simple : on a le nom de la commande de test (qui est donnée dans la

configuration des services) et la commande à réellement effectuer pour réaliser le test.

Dans la commande à exécuter, on peut utiliser des variables :

$PLUGINDIR$ : Le dossier où sont stockés les programmes de tests. Certains sont fournis directement

avec shinken, d'autres sont inclus dans des plugins à installer. On peut bien sûr ajouter ses propres

fichiers. Ce répertoire est, pour notre installation : /var/lib/shinken/libexec.

$HOSTADDRESS$ : L'adresse de l'hôte sur lequel le test est effectué.

$ARGx$ : Les arguments donnés dans la configuration des services. $ARG1$ correspond à la chaîne

entre le premier et le deuxième point d'exclamation, $ARG2$ le deuxième et le troisième…

D'autres, moins importants…

Structure :

5

Avant-propos :

Le tutoriel suivant est réalisé avec une machine virtuelle Debian Wheezy ayant une adresse IP fixe.

Je vous partage ma procédure d’installation pour une mise en place simple et rapide. Le tutoriel

suivant explique comment installer la version 2.4 du logiciel Shinken

2. Installation de Shinken

Il faut dans un premier temps créer un utilisateur shinken et installer les dépendances nécessaires

puis installer shinken.

a) Création d’un utilisateur : adduser shinken

b) Installation des dépendances nécessaires : aptitude install python-pycurl python-setuptools

python-pip sysstat curl python-cherrypy3 python-crypto-y

- Une fois l’utilisateur shinken crée et les dépendances installées, il est possible d’installer Shinken.

On utilisera Pip : pip install shinken

- Une fois l’installation terminée, on s’identifie avec l’utilisateur shinken : su shinken

- La CLI de Shinken a besoin d'être initialisée afin de générer le fichier Ini contenant les chemins vers

les différents répertoires de configuration de l'outil. Pour ce faire : shinken –init (à exécuter avec

l’utilisateur shinken, deux tirets du 6)

Les chemins utilisés par Shinken :

- /etc/shinken : Tous les fichiers de configurations sont ici.

- /usr/bin/shinken-* : Les scripts des daemons shinken

- /usr/lib/nagios/plugins Les plugins Nagios sont stockés à cet endroit.

- /var/lib/shinken : Les modules shinken ou les plugins permettant de réaliser des checks seront ici.

- /var/log/shinken : Les logs shinken

Cette étape dépendra en grande partie de votre connexion internet. Comptez 10 minutes

6

3. Installation de Webui2

Shinken est accessible via une interface web. J’ai choisis de mettre en place Webui2 pour toutes les

améliorations qu’elle apporte par rapport à la première version. Je trouve cette version bien plus

jolie et lisible que l’ancienne.

- Avec l’utilisateur shinken, on éxecute la commande : shinken install webui2

- Vous devrez peut-être installé certaines dépendances python en utilisant pip :

sudo pip install pymongo>=3.0.3 requests arrow bottle==0.12.8

- Il faut installer également un module pour stocker les données des utilisateurs dans une base de

données. Si vous oubliez cette étape, vous aurez l’erreur “Warning: You didn’t define a WebUI

module for saving user preferences like the MongoDB one. You won’t be able to use this page!” lors

de la connexion à l’interface web. Je choisis le module mongodb : apt-get install python-pip mongodb

- Il faut maintenant dire à shinken d’utiliser Webui2. Il faut pour cela modifier le fichier

/etc/shinken/brokers/broker-master.cfg et rajouter modules webui2

Redémarrez Shinken : service shinken restart

Rendez-vous maintenant sur l’interface http://ip_serveur:7767

http://ip_serveur:7767/

7

Vous pouvez modifier les informations de l’utilisateur admin en modifiant le fichier

/etc/shinken/contacts/admin.cfg

10 minutes sont nécessaires pour cette étape.

8

4. Monitorer l’hôte shinken avec SSH

Nous allons installer des packs qui vont permettre la remontée d’information des hôtes distants vers

le serveur Shinken.

Dans un premier temps, on va choisir le pack linux-ssh qui est un mode agent: le script ouvre une

connexion ssh pour exécuter une commande sur l’hôte distant et récupérer l’information. Il faut

savoir que ce mode n'est pas le plus recommandé, car il consomme plus de ressources qu'une

requête SNMP classique.

Nous utiliserons SSH pour monitorer notre machine Shinken.

- Avec l’utilisateur shinken, installer le pack SSH : shinken install ssh

- Ces plugins ont besoin d’une librairie nommé python-paramiko. On repasse en root pour effectuer

cette installation : aptitude install python-paramiko

- Ces plugins lancent une connexion ssh sur l’hôte distant (dans notre cas le serveur local). On va

donc générer une paire de clé sssh et donner la clé publique à l’utilisateur shinken : ssh-keygen

Ne pas saisir de passphrase sinon le script attendrait une intervention humaine pour saisir cette

dernière à chaque exécution.

On déploie la clé publique : ssh-copy-id -i ~/.ssh/id_rsa shinken@localhost

Il faut maintenant ouvrir le fichier localhost.cfg qui indiquera à shinken ce que nous voulons

monitorer.

Il faut créer un fichier .cfg pour chaque hôte que vous souhaitez monitorer. Ces fichiers doivent être

crées à l’endroit suivant /etc/shinken/hosts/

Pour le localhost exécutez : nano /etc/shinken/hosts/localhost.cfg et changez la valeur generic-host

par linux-ssh . Redémarrez ensuite l’arbiter avec la commande /etc/init.d /shinken-arbiter restart

Cette étape ne présente aucunes difficultés particulières, elle ne prendra pas plus de 15 minutes.

9

5. Monitorer des hôtes LINUX avec SNMP

J’utilise le pack SNMP pour monitorer les hôtes LINUX et non SSH car ce dernier consomme plus de

ressource qu’une requête SNMP classique.

Avec l’utilisateur shinken, on télécharge le pack snmp : shinken install linux-snmp

Les manipulations suivantes se font sur l’ordinateur que vous souhaitez monitorer.

Il faut installer différents paquets (en utilisateur root): snmpd permet de rendre accessible une

machine A dont on souhaite récupérer les informations de fonctionnement pour les exploiter sur une

autre machine B, ntp est un protocole qui permet de synchroniser via un réseau informatique

l'horloge locale d'ordinateurs sur une référence d'heure et enfin nagios-plugins sont les plugins de

Nagios qui vont permettre la remonter d’information (les plugins sont compatibles avec Shinken)

aptitude install snmpd nagios-plugins ntp

Il faut modifier le fichier de configuration suivant pour autoriser snmp à être écouté à distance nano

/etc/snmp/snmpd.conf: il faut commenter la première ligne enlever le commentaire de la deuxième.

Maintenant, commenter la ligne comme il suit et ajouter la seconde à votre fichier. Redémarrer

ensuite le service snmp avec la commande : service snmpd restart

10

On retourne sur le serveur pour créer le fichier de configuration et executez les commandes ci

dessous

- On télécharge aussi les plugins de Nagios, pour ce faire il suffit de télécharger l’archive à l’adresse

suivante: wget --no-check-certificate https://www.monitoring-plugins.org/download/monitoring-

plugins-2.1.1.tar.gz

- Décompresser l’archive avec la commande tar-xvzfmonitoring-plugins-2.1.1.tar.gz

- Déplacez-vous ensuite dans le dossier décompressé et installer les plugins à l’aide de la commande :

./configure --with-nagios-user=shinken --with-nagios-group=shinken --enable-libtap --enable-extra-

opts --enable-perl-modules --libexecdir=/usr/lib/nagios/plugins

- Terminer l’installation avec la commande : make install

- On redémarre les services shinken pour prendre en compte la nouvelle configuration :

service shinken restart

11

Problème check_netint.pl

- executez les commandes suivantes:

cd /var/lib/shinken/libexec/

wget https://raw.githubusercontent.com/Sysnove/shinken-

plugins/master/check_netint.pl

chmod +x check_netint.pl

chown shinken:shinken check_netint.pl

Problème avec NetworkUsage

- Editez le fichier /etc/shinken/packs/linux-snmp/templates.cfg et à la ligne 24 modifier la ligne en

rajoutant le nom de l’interface que vous souhaitez monitorer. Si votre interface se nomme enp0s8 _NET_IFACES eth\d+|em\d+|enp0s8

Problème avec Log_File_Health

L’utilisateur shinken ne possédant pas de droit d’écriture sur le répertoire /var/log/syslog il ne peut

donc pas écrire de log dans le journal. Pour contourner le problème, il suffit de créer un fichier dans

le répertoire et de rediriger les logs dans celui-ci.

mkdir /var/log/logshinken.log

chmod +x /var/log/logshinken.log

nano /var/lib/shinken/libexec/logFiles_linux.conf et rajouter la ligne suivante

Redémarrer les services shinken : service shinken restart

Cette étape peut s’avérer assez longue surtout si vous rencontrez les problèmes au-dessus, comptes

30-45 minutes.

12

6. Monitorer un routeur

Il faut dans un premier temps récupérer le plugin check_nwc_health qui n’est pas présent de base

avec Shinken.

Télécharger l’archive à cette adresse https://labs.consol.de/nagios/check_nwc_health/#download et

décompressez l’archive tar -zxvf check_nwc_health-5.12.0.5.tar.gz.

Placez-vous dans le dossier extrait et copier le fichier check dans le répertoire

/var/lib/shinken/libexec/.

cp plugins-scripts/check_nwc_health /var/lib/shinken/libexec

Ensuite, on modifie la propriété de check_nwc_health à l’utilisateur shinken :

On télécharge les packs cisco et router qui nous permettront de monitorer notre routeur :

shinken install router et shinken install cisco

Sur le routeur, il faut déclarer la communauté snmp. Pour ce faire, en mode de configuration globale

rentrer la commande snmp-server community public ro 1

Il ne reste plus qu’à créer le fichier de configuration du routeur dans /etc/shinken/hosts/

Vous devriez voir ceci une fois sur l’interface web :

https://labs.consol.de/nagios/check_nwc_health/#download

13

7. Monitorer un switch

Il faut télécharger le pack switch pour pouvoir monitorer notre switch. shinken install switch

Il faut ensuite déclarer la communauté sur le switch en mode de configuration globale

Il ne reste plus qu’à créer un fichier de configuration à l’endroit suivant /etc/shinken/hosts/

Une fois sur l’interface web, on peut voir notre nouvel hôte

14

8.Monitorer serveur ESX

J’ai utilisé le plugin check_esx3_pl.

Il faut au préalable créer un utilisateur VSphere, voir ce tuto http://www.blog-note.com/creer-

utilisateurs-users-vmware-esx-esxi/

Ensuite, placez vous dans /var/lib/shinken/libexec / et executez la commande suivante :

./check_esx3.pl –H (ip de l’ESX) –u shinken –p password –l vmfs

A adapter à votre configuration –u correspond à l’utilisateur ESX et –p au mot de passe associé.

Si vous avez cette erreur, lancez la commande apt-get install libnagios-plugin-perl et relancez la

commande de check

Le résultat attendu

Ce test permet de savoir la place disponible sur le datastore de l’ESX.

Avec tous les plugins, vous pouvez tapez ./le nom du plugin –h pour avoir de l’aide concernant ce

plugin (commandes dispo, syntaxe,etc)

Editez le fichier path.cfg situez dans /etc/shinken/resource.d/ et assurez vous que le chemin de la

variable $PLUGINSDIR$ soit bien le chemin pointant vers vos plugins Shinken.

Rendez vous maintenant dans /etc /shinken/commands pour créer les commandes qui permettront

de monitorer différents paramètres de l’ESX.

Créer un fichier check_esx.cfg

Rentrez les commandes suivantes :

define command {

command_name check_esx_cpu

command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p

$VCENTERPASSWORD$ -l cpu -s usage -w $ARG1$ -c $ARG2$

}

define command {

command_name check_esx_memory


$VCENTERPASSWORD$ -l mem -s usagemb -w $ARG1$ -c $ARG2$

}

15

define command {

command_name check_esx_swap


$VCENTERPASSWORD$ -l mem -s swap -w $ARG1$ -c $ARG2$

}

define command {

command_name check_esx_network


$VCENTERPASSWORD$ -l net -s usage -w $ARG1$ -c $ARG2$

}

define command {

command_name check_esx_disk_io_read


$VCENTERPASSWORD$ -l io -s read -w $ARG1$ -c $ARG2$

}

define command {

command_name check_esx_disk_io_write


$VCENTERPASSWORD$ -l io -s write -w $ARG1$ -c $ARG2$

}

define command {

command_name check_esx_nic


$VCENTERPASSWORD$ -l net -s nic

}

define command {

command_name check_esx_runtime


$VCENTERPASSWORD$ -l runtime -s list

}

Ces commandes permettent de monitorer la charge CPU, les accès disques, le débit utilisé par la

carte réseau, le nombre de VM stockés sur l’ESX ainsi que leurs états (UP ou DOWN)

16

On crée ensuite les services associés à ces commandes dans /etc/shinken/services. Créer un fichier

nommé esx.cfg

define service {

use generic-service

host_name julien-esx

service_description CPU

check_command check_esx_cpu!80!90

}

define service {


use generic-service

service_description Memoire

check_command check_esx_memory!14336!16384

}

define service {


use generic-service

service_description Trafic_Reseau

check_command check_esx_network!5120!102400

}

define service {


use generic-service

service_description Disque_IO_Lecture

check_command check_esx_disk_io_read!50!90

}

define service {


use generic-service

service_description Disque_IO_Ecriture

check_command check_esx_disk_io_write!50!90

}

define service {


use generic-service

service_description Interfaces_Reseaux

check_command check_esx_nic

}

17

define service {


use generic-service

service_description Services

check_command check_esx_service!DCUI,lbtd,ntpd,vmware-vpxa

}

define service {


use generic-service

service_description ESXi Runtime Status

check_command check_esx_runtime

}

Pour finir on va créer l’hôte à monitorer dans /etc/shinken/hosts/

nano julien-esx.cfg

A noter que si vous changez le « host name » du fichier julien-esx.cfg, vous devez le changer pour

chaque service

Redémarrez l’arbiter /etc/init.d/shinken-arbiter restart.

Sur shinken, vous devriez voir ceci :

18

Si jamais vous avez une erreur en redémarrant shinken, exécutez /usr/bin/shinken-arbiter -v -c

/etc/shinken/shinken.cfg pour voir ou le problème est.

19

9. Monitorer un hote Windows

J’ai choisis d’utiliser l’agent NRPE pour monitorer un hôte Windows.

Il faut télécharger un agent nommé NSCLIENT++ sur votre hôte Windows.

http://www.nsclient.org/download/

Lors de l’installation, vous serez invité à saisir le mot de passe de connexion de l’agent ainsi que

l’adresse du serveur Shinken. Gardez bien le mot de passe il sera nécessaire lors de la configuration

du serveur Shinken. Petit conseil : pas de caractères spéciale genre « ! » qui est un caractère

d’échappement pour les fichiers de configurations de Shinken.

Cocher les cases suivantes :

Enable common check plugins : active les plugins de base NRPE

Enable nsclient server (check_nt) : obligatoire pour que les plugins check_nt fonctionne depuis

Shinken

Enable NRPE server (check_nrpe) : active le mode agent. Utilise pour faire des script de supervision

perso.

Enable WMI checks : comme je l’ai dis précédemment, ceci active le mode de supervision à la

Mircrosoft.

20

Une fois installer, vous pouvez lancer le service. Pour cela on se rend dans le gestionnaire de service

(services.msc) afin de vérifier que NSClient++ se trouve bien en état « démarré » et « automatique ».

Le service sera à redémarrer après chaque modification de la configuration de l’agent. Celle ci se

trouve sous C:\Program Files\NSClient++\nsclient.

Un dernier détail afin de terminer la configuration. Pour plus de sécurité Windows désactive les accès

et autorisations de connexion à distance. Pour vérifier, faite clique droit et propriété sur le service.

Dans l’onglet connexion, cocher « Authoriser le service à interagir avec le Bureau ».

21

On se place maintenant dans shinken pour tester la bonne connexion de l’agent en appelant

directement le script check_nt

/usr/lib/nagios/plugins/check_nt -H host.domain.local -p 12489 -v CLIENTVERSION -s password

Explication sur les options :

-H : Nom ou adresse IP de l’hôte à interroger.

-p : port. Par défaut 12489

-s : Le mot de passe. Celui saisi à l’installation du client NSClient++

-v : Variable à interroger

Le résultat doit ressembler à ceci

Il faut maintenant, comme pour monitorer l’ESX crée un fichier dans /etc/shinken/commands en

l’appelant check_nt.cfg

Y copier cette commande :

define command {

command_name check_nt ; Nom de la commande qui sera appelé

command_line $USER1$/check_nt -H $HOSTADDRESS$ -p 12489 -s password -v $ARG1$ $ARG2$ ;

syntaxe 'brute' de la commande

}

La commande n’est que la forme syntaxique de l’appel que on avons effectué précédemment pour

tester le script. La seule différence ce trouve dans l’ajout de l’arguments -v permettant de passer des

paramètres supplémentaires. Chaque plugin requière un paramètre comme par exemple un seuil de

criticité, le nom d’un service particulier ou une lettre de lecteur.

On passe ensuite à la création d’un groupe pour qui fera office de base pour tous les serveurs

Windows.

On créé donc le fichier hostgroups/windows_nrpe.cfg pour y placer les lignes suivantes :

define hostgroup{

hostgroup_name windows_nrpe

alias Serveur Windows Via NSClient++

members serveur_windows

}

On va à présent rattacher des services à ce groupe. Chacun des serveurs Windows dans ce dernier se

verra donc superviser par ces services. Vous pouvez les placer à la suite du fichier hostgroups pour

une meilleur lisibilité ou créer un nouveau fichier de configuration. Dans cette exemple, les services

sont placés à la suite du fichier hostgroups

22

Afficher la version de l’agent NSCLIENT++

define service {

service_description Check version NS Client ; Description de la commande

hostgroup_name windows_nrpe ; Nom du groupe sur lequel la commande sera exécutée

use generic-service ; Utilisation du template générique

check_command check_nt!CLIENTVERSION ; Commande à effectue

}

Uptime de la machine

define service {

service_description Uptime


use generic-service

check_command check_nt!UPTIME

}

Charge CPU

define service {

service_description CPU load


use generic-service

check_command check_nt!CPULOAD!-l 1,90,95,5,90,95,15,90,95 ; Comme linux

}

Charge mémoire

define service {

service_description RAM load


use generic-service

check_command check_nt!MEMUSE!-w 80 -c 90

}

Taux du remplissage du disque dur « C : »

-l c : selection du lecteur à supervisiser

-w : seuil pour déclancher un warning

-c : seuil critique

define service {

service_description Charge disque C


use generic-service

check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90}

23

Les services de base sont configurés. On va pour terminer créer une machine qui appartiendra au

groupe windows_nrpe. Création du fichier /etc/shinken/hosts/serveur_windows.cfg

define host{

use generic-host

host_name serveur_windows

address 10.61.10.41 # à changer

}

Redémarrez l’arbiter pour prendre en compte les changements

/etc/init.d/shinken-arbiter restart

Résultat attendu :

24

10. Monitorer une imprimante :

Pour monitorer une imprimante, il faut utiliser le plugin check_snmp_printer que vous devez

télécharger et placer dans le dossier /var/lib/shinken/libexec/ .

A noter également que le protocole SNMP doit être activé sur votre imprimante et la communauté

en public.

Téléchargez le plugin à cette adresse :

https://exchange.nagios.org/directory/Plugins/Hardware/Printers/SNMP-Printer-Check/details

Testez le plugin en « dur » avec cette commande :

./check_snmp_printer –H 10.61.50.1 –C public –t model

Cette commande devrait vous renvoyer le model et la marque de votre imprimante.

Maintenant il faut créer un fichier dans /etc/shinken/commands/ , appelez le

check_snmp_printer.cfg

Y placer les commandes suivantes :

define command{

command_name check_conso

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "CONSUM ALL"

}

define command{

command_name check_model

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "model"

}

define command{

command_name check_pagecount

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "pagecount"

}

define command{

command_name check_status

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "status"

}

define command{

command_name check_messages

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "messages"

}

define command{

command_name check_devices

command_line $PLUGINSDIR$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -t "devices"

}

define command{

command_name check_ping

command_line $PLUGINSDIR$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5}

25

Ces commandes permettent de monitorer le nombres de pages imprimées par l’imprimante, l’état

du tambour, les messages renvoyés par l’imprimante et le modèle.

Placez vous maintenant dans le dossier /etc/shinken/services et crée un fichier printer.cfg

Y placez les commandes suivantes :

define service {

use generic-service

host_name printer

service_description Printer Consum

check_command check_conso!public!"CONSUM ALL"

}

define service {

use generic-service

host_name printer

service_description Pages imprimées

check_command check_pagecount!public!"pagecount"

}

define service {

use generic-service

host_name printer

service_description Status

check_command check_status!public!"status"

}

define service {

use generic-service

host_name printer

service_description Modèle

check_command check_model!public!"model"

}

define service {

use generic-service

host_name printer

service_description Messages

check_command check_messages!public!"messages"

}

define service {

use generic-service

host_name printer

service_description Devices

check_command check_devices!public!"devices"

}

26

define service {

use generic-service

host_name printer

service_description Ping

check_command check_ping!100.0,20%!500.0,60%

}

Créez maintenant l’hôte dans /etc/shinken/hosts un fichier printer.cfg et y placer les commandes

suivantes :

define host{

use generic-service

host_name printer

address 10.61.50.1

}

A noter que comme pour l’ESX, si vous décidez de changer le host_name du fichier host, vous devez

le changer pour toutes les commandes services. L’ip doit bien sur être changé par celle de votre

imprimante

Résultat attendu une fois l’arbiter redémarré :

27

11. Conclusion :

J’ai beaucoup appris de ce projet. En effet, je n’avais aucune connaissance en matière de supervision.

Shinken m’a permis de comprendre comment monitorer des équipements, avec quels protocoles et

quel plugin.

Shinken est je trouve assez simple à mettre en place et monitorer des hôtes avec n’est pas

compliqué.

Je recommande donc l'utilisation de ce serveur de supervision qui permet de simplifier la

reconnaissance de problèmes divers sur l'ensemble d'un parc administré de par son interface

graphique intuitive.

Ainsi il est plus simple à un administrateur réseau de gérer ses matériels, de plus nous avons constaté

qu'il existe de nombreux moyens de les sonder, libre alors à l'utilisateur de faire son choix.

28

12. Bibliographie : http://docplayer.fr/5300270-Tutoriel-d-installation-shinken.html https://shinken4all.wordpress.com/ https://mespotesgeek.fr/fr/supervision-windows-avec-shinken-2/ http://www.sugarbug.web4me.fr/atelier/techniques/monitoring_system/page_esx/SDK_Perl_ESX_Centreon/ http://unix.stackexchange.com/questions/199155/cannot-install-nagiosplugin-dont-know-what-it-is http://www.levasseur.im/wiki/doku.php?id=articles:2010:monitorer_votre_esxi_avec_shinken http://www.be-root.com/2011/01/28/supervision-vmware-esx/ https://tech.feub.net/2011/01/surveillance-vmware-esxi-et-vsphere-avec-nagios/ https://ittutorials.net/linux/nagios/check-the-status-of-printers-cartridges-using-snmp-with-nagios/

julien michaud · 2018. 9. 5. · le tutoriel suivant explique comment installer la version 2.4 du...

Documents