Installation pas à pas d'un serveur de supervision Shinken

Les commandes sont à saisir à partir du compte root ou en les précédant de la commande 'sudo' si celle-ci est installée.

apt-get install curl curl -L http://install.shinken-monitoring.org | /bin/bash

Attendre quelques minutes…

Lors du premier redémarrage, je suis tombé sur l'erreur suivante (/tmp/bad_start_for_arbiter) :

[1351082314] Error : Opening the log file 'arbiterd.log' failed with '[Errno 13] Permission denied: u'/usr/local/shinken/var/arbiterd.log''

Pour résoudre ce problème de droits, j'ai effectué les actions suivantes :

service shinken stop
chown -R shinken:shinken /usr/local/shinken
service shinken start

L'installation se fait dans le répertoire /usr/local/shinken. Pour identifier les éventuels problèmes que vous pouvez rencontrer lors de l'installation, vous pouvez consulter le fichier de log /tmp/shinken.install.log.

I-A. Configuration initiale de Shinken▲

Les fichiers de configuration se trouvent dans le répertoire /usr/local/shinken/etc/.

Avant de commencer à jouer avec cette configuration, il est important d'avoir une connaissance générale de l'architecture de Shinken. Je vous conseille donc la lecture de cette page sur le wiki officiel.

La première chose à faire est de sécuriser l'accès à l'interface WebUI installé par défaut. Pour cela, il faut éditer la section module / WebUI du fichier shinken-specific.cfg en ajoutant le module Mongodb et en changeant le mot de passe auth_secret :

 

Sélectionnez

define module {
  module_name WebUI
  module_type webui
 
  host 0.0.0.0
  port 7767
  auth_secret MOTDEPASSE
 
  modules Apache_passwd,ActiveDir_UI,Cfg_password,PNP_UI,Mongodb
 
  manage_acl 1
  play_sound 0
  allow_html_output 0
  max_output_length 100
}

Puis en éditant le mot de passe du compte admin (par défaut: admin) dans le fichier contacts.cfg :

 

Sélectionnez

define contact{
    use             generic-contact
    contact_name    admin
    email           votre@mail.com ; adresse mail
    pager           0600000000   ; telephone
    password        motdepasseadmin ; mot de passe
    is_admin        1
}

Comme vous pouvez le voir, c'est également dans cette section que vous pouvez changer l'adresse IP (par défaut en écoute sur toutes les adresses IP des interfaces) et le port d'écoute (par défaut TCP/7767) de l'interface WebUI.

On peut ensuite relancer Shinken pour prendre en compte la modification :

 

Sélectionnez

service shinken restart

Il ne reste plus qu'à accéder à l'interface Shinken WebUI en saisissant l'URL suivante dans votre navigateur (en remplaçant @IP par l'adresse IP de votre serveur) : http//@IP:7767/

Lors de mon installation (sur une VM), je ne disposais que de 3 Go de libre sur le montage /var. La configuration par défaut de MongoDB, qui est la base de données utilisée par la WebUI pour stocker les informations utilisateurs, a besoin d'un fichier journal de plus de 3 Go. J'avais donc le message suivant au niveau de l'interface :

Et le log suivant dans le fichier /var/log/mongodb/mongodb.log :

 

Sélectionnez

Wed Oct 24 16:02:26 [initandlisten] ERROR: Insufficient free space for journal files
Wed Oct 24 16:02:26 [initandlisten] Please make at least 3379MB available in /var/lib/mongodb/journal or use --smallfiles
Wed Oct 24 16:02:26 [initandlisten]
Wed Oct 24 16:02:26 [initandlisten] exception in initAndListen: 15926 Insufficient free space for journals, terminating
Wed Oct 24 16:02:26 dbexit:

Pour forcer MongoDB à être moins gourmand, j'ai changé sa configuration dans le fichier /etc/mongodb.conf :

 

Sélectionnez

smallfiles = true

Puis on relance MongoDB :

 

Sélectionnez

service mongodb restart

À ce stade, vous devriez avoir une interface WebUI fonctionnelle mais désespérément vide (mis à part votre serveur de supervision)…

Il est donc temps de passer à la prochaine étape.

Selon la taille de votre réseau, la tâche qui consiste à entrer les machines à superviser dans la configuration de Shinken peut s'avérer pour le moins lourde. Heureusement, Shinken fournit un outil permettant de découvrir automatiquement les machines présentes sur votre réseau et même sur votre serveur de virtualisation VMWare (via vCenter).

Cet outil se base sur :

• nmappour la découverte sur le réseau ;
• un plugin nommé check_esx pour découvrir les machines sur un serveur VMWare vCenter.

On commence donc par installer ces deux prérequis sur notre serveur de supervision :

apt-get install nmap
/usr/local/shinken/install -p check_esx3

Si vous avez un serveur VMWare vCenter, vous pouvez vérifier le bon fonctionnement du plugin check_esx3 en le lançant en ligne de commande :

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l cpu
CHECK_ESX3.PL OK - cpu usage=376.00 MHz (0.59%) | cpu_usagemhz=376.00Mhz;; cpu_usage=0.59%;;
 
/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l mem
CHECK_ESX3.PL OK - mem usage=30413.32 MB (23.20%), overhead=652.43 MB, swapped=0.00 MB, memctl=0.00 MB | mem_usagemb=30413.32MB;; mem_usage=23.20%;; mem_overhead=652.43MB;; mem_swap=0.00MB;; mem_memctl=0.00MB;;
 
/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l net
CHECK_ESX3.PL OK - net receive=2.00 KBps, send=1.00 KBps, all 2 NICs are connected | net_receive=2.00KBps;; net_send=1.00KBps;; OK_NICs=2;; Bad_NICs=0;;
 
/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l vmfs
CHECK_ESX3.PL OK - Storages : 'datastore1'(free)=279348.00 MB (99.65%), 'datastore2'(free)=548125.00 MB (57.51%) | datastore1=279348.00MB;; datastore2=548125.00MB;;
 
rm /tmp/cwpss_*

Il faut ensuite donner à Shinken les informations sur les réseaux (et serveurs vCenters) où le logiciel de découverte doit être lancé. Pour cela, il faut éditer le fichier /usr/local/shinken/etc/resource.cfg (section Discovery) :

#-- Discovery
# default snmp community
$SNMPCOMMUNITYREAD$=public
# what to discover by default
$NMAPTARGETS$=192.168.1.0/24
# If your scans are too slow, try to increase minrate (number of packet in parallel
# and reduce the number of retries.
$NMAPMINRATE$=1000
$NMAPMAXRETRIES$=0
# VMWare vCenter
$VCENTER$=vcenter.mondomaine.com
$VCENTERLOGIN$=LOGINVCENTER
$VCENTERPASSWORD$=MOTDEPASSEVCENTER

Il est bien sûr possible d'ajouter des réseaux ou des machines à la variable $NMAPTARGETS$ en séparant chaque entrée par un espace.

On peut lancer shinken-discovery qui va effectuer la découverte automatique :

/usr/local/shinken/bin/shinken-discovery -c /usr/local/shinken/etc/discovery.cfg -o /usr/local/shinken/etc/objects/discovery/ -r nmap,vsphere

shinken-discovery va générer la configuration des machines découvertes dans le répertoire /usr/local/shinken/etc/objects/discovery/ (configurable dans la commande ci-dessus avec l'option -o).

On relance Shinken pour intégrer les machines ainsi découvertes :

service shinken restart

En allant dans l'interface graphique, vous allez sûrement rencontrer des erreurs de check, car tous les plugins ne sont pas installés par défaut. Par exemple :

... BigProcesses CRITICAL3m 10s /bin/sh: /usr/local/shinken/libexec/check_wmi_plus.pl: not found ...

Il faut donc utiliser le script d'installation pour installer les plugins manquants.

Sur ma configuration j'ai fait ainsi :

/usr/local/shinken/install -p check_mysql_health
/usr/local/shinken/install -p manubulon
/usr/local/shinken/install -p check_snmp_bandwidth
/usr/local/shinken/install -p check_netint
/usr/local/shinken/install -p check_nwc_health
/usr/local/shinken/install -p check_wmi_plus

Il faut procéder ainsi jusqu'à avoir installé tous les plugins manquants nécessaires. Pour avoir une liste exhaustive des plugins dont l'installation est supportée par le script Shinken install, il suffit de saisir la commande suivante :

/usr/local/shinken/install -h
...
    -p | --plugin           Install plugins. Argument should be one of the following:
                               check_esx3
                               nagios-plugins
                               check_oracle_health
                               check_mysql_health
                               capture_plugin
                               check_wmi_plus
                               check_mongodb
                               check_emc_clariion
                               check_nwc_health
                               manubulon (snmp plugins)
                               check_hpasm
                               check_netapp2
                               check_mem (local enhanced memory check plugin)
                               check_snmp_bandwidth (check bandwidth usage with snmp)
                               check_netint (enhanced version of check_snmp_int plugins)
                               check_IBM
                               check_IBM_DS
                               check_rsync
...

La découverte automatique est vraiment un plus mais ce n'est pas le Saint Graal. En effet, pour configurer finement ce que l'on veut superviser, il faudra obligatoirement reprendre la configuration à la main en éditant les fichiers se trouvant dans le répertoire /usr/local/shinken/etc/objects/discovery. De plus, la notion de groupe étant plus une problématique fonctionnelle que technique, il vous faudra configurer ces derniers manuellement à partir du fichier /usr/local/shinken/etc/hostgroups.com.

Un exemple de configuration de groupe :

define hostgroup{
   hostgroup_name VirtualisationServers
   alias Virtualisation Servers
   members vcenter, virt1, virt2, virt3, virt4
}

Attention à bien sauvegarder ce répertoire avant de relancer un shinken-discovery, histoire de ne pas perdre vos modifications.

Reste ensuite la phase la plus longue mais également la plus importante de la configuration de Shinken : ne surveiller que les choses importantes pour votre système d'information.

En effet, le mode de découverte automatique n'est pas assez fin pour déterminer par lui-même ce qu'il faut superviser. La CPU du PC de la secrétaire monte régulièrement au-dessus de 90% d'utilisation ? What else… Par contre, si on constate la même consommation CPU sur le serveur Web de votre entreprise, il faut aller y jeter un coup d'œil…

Le plus simple pour effectuer cette lourde tâche est de manipuler la WebUI (voir le chapitre suivant), puis de parcourir l'ensemble des hosts et des services en supprimant ce que l'on juge peu important.

À ce stade, vous devriez avoir un serveur de supervision qui commence à remonter un certain nombre d'informations dans l'interface WebUI.

Je vous encourage ensuite à vous familiariser avec cette nouvelle interface WebUI qui peut être un peu déroutante pour les personnes habituées à manipuler d'autres solutions de supervision. À ce sujet, il est également possible d'utiliser des interfaces alternatives comme Thruk qui se rapproche plus de l'interface native de Nagios.

Thruk, une alternative à Shinken WebUI

Personnellement, je trouve qu'une fois la première impression passée (c'est quoi ces grosses icônes ? Où sont mes hosts !). La modularité apportée par le Dasboard, les filtres et les bookmarks permet d'adapter cette interface à vos besoins. Si les développeurs de Shinken lisent cet article (et je suis sûr qu'ils vont le faire, coucou @naparuba ), il serait bon de configurer le Dashboard par défaut et quelques filtres bien pensés, histoire que les nouveaux utilisateurs ne se trouvent pas devant des pages blanches.

On peut également se créer des filtres personnels (par exemple toutes les machines appartenant au groupe "serveur" ou tous les services remontant la charge des machines…) et créer des bookmarks dans la page All de la WebUI.

Nous arrivons au terme de ce premier article sur une configuration pas à pas de Shinken. Au prochain épisode, nous allons nous pencher sur la notion d'impacts/dépendances et de business rules qui sont de grosses valeurs ajoutées de Shinken par rapport à Nagios.

L'équipe « Réseaux » de Developpez.com tient à remercier Nicolargo pour la rédaction de cet article. Retrouvez tous les articles de nicolargo sur cette page.

L'équipe de rédaction Developpez.com tient à remercier ced pour la relecture orthographique de cet article.

N'hésitez pas à commenter cet article ! 1 commentaire