-
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
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l mem -s usagemb -w $ARG1$ -c $ARG2$
}
-
15
define command {
command_name check_esx_swap
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l mem -s swap -w $ARG1$ -c $ARG2$
}
define command {
command_name check_esx_network
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l net -s usage -w $ARG1$ -c $ARG2$
}
define command {
command_name check_esx_disk_io_read
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l io -s read -w $ARG1$ -c $ARG2$
}
define command {
command_name check_esx_disk_io_write
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l io -s write -w $ARG1$ -c $ARG2$
}
define command {
command_name check_esx_nic
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$VCENTERPASSWORD$ -l net -s nic
}
define command {
command_name check_esx_runtime
command_line $PLUGINSDIR$/check_esx3.pl -H $HOSTADDRESS$ -u $VCENTERLOGIN$ -p
$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 {
host_name julien-esx
use generic-service
service_description Memoire
check_command check_esx_memory!14336!16384
}
define service {
host_name julien-esx
use generic-service
service_description Trafic_Reseau
check_command check_esx_network!5120!102400
}
define service {
host_name julien-esx
use generic-service
service_description Disque_IO_Lecture
check_command check_esx_disk_io_read!50!90
}
define service {
host_name julien-esx
use generic-service
service_description Disque_IO_Ecriture
check_command check_esx_disk_io_write!50!90
}
define service {
host_name julien-esx
use generic-service
service_description Interfaces_Reseaux
check_command check_esx_nic
}
-
17
define service {
host_name julien-esx
use generic-service
service_description Services
check_command check_esx_service!DCUI,lbtd,ntpd,vmware-vpxa
}
define service {
host_name julien-esx
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
hostgroup_name windows_nrpe
use generic-service
check_command check_nt!UPTIME
}
Charge CPU
define service {
service_description CPU load
hostgroup_name windows_nrpe
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
hostgroup_name windows_nrpe
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
hostgroup_name windows_nrpe
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/