Installation pas à pas d’un serveur de supervision Shinken
Nous allons aborder l'installation et la configuration basique initiale d'un serveur de supervision basé sur Shinken. Ce billet est le premier d'une série sur le sujet. Dans la suite j'utiliserai une machine virtuelle sous Debian Squeeze 6.0.6 (version minimale) pour illustrer mes dires...
Installation de Shinken
Les commandes sont à saisir à partir du compte root ou en les précédants 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 re-dé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 la résoudre ce problème de droit, 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.
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 et 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:
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:
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 toute 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:
service shinken restart
Il ne reste plus qu'à acceder à la l'interface Shinken WebUI en saisissant l'URL suivante dans votre navigateur (en remplacant @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ée utilisé par la WebUI pour stocker les informations utilisateurs, à 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:
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 a être moins gourmand, j'ai changer sa configuration dans le fichier /etc/mongodb.conf:
smallfiles = true
Puis on relance MongoDB:
service mongodb restart
A 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.
Superviser votre système d'information avec Shinken
Selon la taille de votre réseau, la tache qui consiste à entrer les machines à superviser dans la configuration de Shinken peut s'averer pour le moins lourde. Heureusement, Shinken fournit un outil permettant de découvrir automatiquement les machines présente sur votre réseau (j'en avais déjà parlé dans ce billet) et même sur votre serveur de virtualisation VMWare (via vCenter).
Cet outil se base sur:
- nmap pour 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 lancant 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) ou 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 sur possible d'ajouter des réseaux ou de 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 manquant.
Sur ma configuration j'ai ainsi fait:
/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/insatll -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é 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 Grall. En effet pour configurer finement ce que l'on veut suppervier, 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'oeil...
Le plus simple pour effectuer cette lourde tache 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.
Prise en main de Shinken WebUI
A ce stade, vous devriez avoir un serveur de supervision qui commence à remonter un certain nombres 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. A 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 gros icônes ? Ou 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 près configurer le Dashboard par défaut et quelques filtres bien pensées 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 tout les services remontant la charge des machines...) et créer des bookmarks dans la page All de la WebUI.
Et après ?
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.
Cet article Installation pas à pas d’un serveur de supervision Shinken est apparu en premier sur Le blog de NicoLargo.
