Activité : Architecture de Shinken

Vous allez observer le contenu des différents répertoires de Shinken et exécuter les commandes proposées pour découvrir l'architecture de Shinken.

A ce stade, vous avez installé les modules obligatoires de shinken et les modules optionnels webui et mongodb.

Les répertoires associés à Shinken

root@ctShinken:~# find / -name shinken /usr/bin/shinken /usr/local/lib/python2.7/dist-packages/shinken /home/shinken /etc/shinken /etc/init.d/shinken /etc/default/shinken /run/shinken /var/log/shinken /var/mail/shinken /var/lib/shinken /var/lib/shinken/doc/build/html/_modules/shinken root@ctShinken:~# ls /var/lib/shinken/modules/ auth-cfg-password dummy_arbiter dummy_broker dummy_broker_external dummy_poller dummy_scheduler __init__.py mod-mongodb webui root@ctShinken:~# ls /var/lib/shinken/libexec discovery dump_vmware_hosts.py external_mapping.py link_libvirt_host_vm.py link_vmware_host_vm.py link_xen_host_vm.py notify_by_email.py notify_by_xmpp.ini notify_by_xmpp.py send_nsca.py service_dependency_mapping.py

Répertoire contenant les modules : /var/lib/shinken/modules.

Répertoire contenant les sondes : /var/lib/shinken/libexec.

Fichiers de configuration : /etc/shinken.

Lanceurs : /etc/init.d/shinken.

Démons shinken : /usr/bin.

Fichiers de log : /var/log/shinken.

Les fichiers/répertoires de configuration sont :

root@ctShinken:~# ls /etc/shinken/ arbiters brokers certs commands contactgroups contacts daemons dependencies dev.cfg discovery escalations hostgroups hosts modules notificationways packs pollers reactionners realms receivers resource.d sample sample.cfg schedulers servicegroups services shinken.cfg templates timeperiods

Quand on démarre shinken, on constate qu'en réalité le script démarre plusieurs démons.

Chacun de ces démons dispose d'un fichier de configuration dans /etc/shinken.

root@ctShinken:~# service shinken start Starting scheduler: . Starting poller: . Starting reactionner: . Starting broker: . Starting receiver: . Starting arbiter: .

C'est ici la principale différence entre shinken et son aîné nagios. Son architecture est modulaire, elle repose sur le principe Unix : à une tâche un outil.

Shinken utilise six processus (ou composants) différents qui travaillent ensemble et permettent d'obtenir une flexibilité bien supérieure au nagios originel. Surtout, contrairement à un processus monolithique, cette architecture favorise la montée en charge.

Shinken se décompose ainsi :

L’arbitre (Arbiter) : il est notamment responsable de la validation et du chargement de la configuration, de la découpe en différentes parties, et de l’envoi aux autres éléments.

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éactionneurs »). 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).

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.

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 peut y avoir plusieurs receveurs.

On peut observer les processus en cours d'exécution grâce à la commande suivante :

root@ctShinken:~# ps -AHF | grep shinken root 32592 733 0 3187 2160 0 21:21 tty1 00:00:00 grep shinken shinken 23134 1 1 149945 41444 0 20:53 ? 00:00:20 python2.7 /usr/bin/shinken-scheduler -d -c /etc/shinken/daemons/schedulerd.ini shinken 23138 23134 0 35323 34136 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-scheduler -d -c /etc/shinken/daemons/schedulerd.ini shinken 23153 1 0 131465 41624 0 20:53 ? 00:00:12 python2.7 /usr/bin/shinken-poller -d -c /etc/shinken/daemons/pollerd.ini shinken 23156 23153 0 72517 32716 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-poller -d -c /etc/shinken/daemons/pollerd.ini shinken 23334 23153 0 129333 39016 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-poller -d -c /etc/shinken/daemons/pollerd.ini shinken 23175 1 0 147914 41900 0 20:53 ? 00:00:11 python2.7 /usr/bin/shinken-reactionner -d -c /etc/shinken/daemons/reactionnerd.ini shinken 23178 23175 0 72517 32716 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-reactionner -d -c /etc/shinken/daemons/reactionnerd.ini shinken 23352 23175 0 129335 39212 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-reactionner -d -c /etc/shinken/daemons/reactionnerd.ini shinken 23199 1 0 150088 42228 0 20:53 ? 00:00:16 python2.7 /usr/bin/shinken-broker -d -c /etc/shinken/daemons/brokerd.ini shinken 23202 23199 0 72312 36112 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-broker -d -c /etc/shinken/daemons/brokerd.ini shinken 23292 23199 0 129989 42552 0 20:53 ? 00:00:01 python2.7 /usr/bin/shinken-broker -d -c /etc/shinken/daemons/brokerd.ini shinken 23220 1 0 131343 40252 0 20:53 ? 00:00:10 python2.7 /usr/bin/shinken-receiver -d -c /etc/shinken/daemons/receiverd.ini shinken 23223 23220 0 35318 33856 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-receiver -d -c /etc/shinken/daemons/receiverd.ini root 23237 1 0 111574 42064 0 20:53 ? 00:00:10 python2.7 /usr/bin/shinken-arbiter -d -c /etc/shinken/shinken.cfg root 23238 23237 0 37592 39716 0 20:53 ? 00:00:00 python2.7 /usr/bin/shinken-arbiter -d -c /etc/shinken/shinken.cfg

L'option –A affiche tous les processus.

L'option –H affiche l'arborescence des processus.

L'option –F affiche toutes les informations associées au processus.

On s’aperçoit ici que les processus Shinken sont en fait pris en charge par l’interpréteur Python.

On constate aussi, élément important à noter, que les processus ne sont pas exécutés avec les droits root mais avec les droits d'un utilisateur shinken.

On voit aussi les fichiers de paramètres utilisés par les commandes (.ini).

Tous les programmes Python utilisés par Shinken se trouvent dans /usr/bin et les fichiers de configuration dans /etc/shinken.

On peut repérer les ports TCP écoutés par Shinken en exécutant la commande suivante :

root@ctShinken:~# netstat -tlnp | grep "LISTEN .*python" tcp 0 0 127.0.0.1:39026 0.0.0.0:* LISTEN 30925/python2.7 tcp 0 0 127.0.0.1:47924 0.0.0.0:* LISTEN 31145/python2.7 tcp 0 0 0.0.0.0:7767 0.0.0.0:* LISTEN 31383/python2.7 tcp 0 0 127.0.0.1:45047 0.0.0.0:* LISTEN 31322/python2.7 tcp 0 0 0.0.0.0:7768 0.0.0.0:* LISTEN 30847/python2.7 tcp 0 0 0.0.0.0:7769 0.0.0.0:* LISTEN 30999/python2.7 tcp 0 0 127.0.0.1:7770 0.0.0.0:* LISTEN 31319/python2.7 tcp 0 0 0.0.0.0:7771 0.0.0.0:* LISTEN 30922/python2.7 tcp 0 0 0.0.0.0:7772 0.0.0.0:* LISTEN 31143/python2.7 tcp 0 0 0.0.0.0:7773 0.0.0.0:* LISTEN 31222/python2.7 tcp 0 0 127.0.0.1:33502 0.0.0.0:* LISTEN 31224/python2.7 tcp 0 0 127.0.0.1:50599 0.0.0.0:* LISTEN 31002/python2.7 tcp 0 0 127.0.0.1:55719 0.0.0.0:* LISTEN 30849/python2.7

options de netstat :

t pour tcp,

l pour listenning,

n pour numeric

et p pour program

Les différents ports sont définis dans les fichiers de configuration associés à chaque module. Par exemple pour le module poller, on trouve dans /etc/shinken/pollers/poller-master.cfg une directive port :

#===============================================================================
# POLLER (S1_Poller)
#===============================================================================
# Description: The poller is responsible for:
# - Active data acquisition
# - Local passive data acquisition
# https://shinken.readthedocs.org/en/latest/08_configobjects/poller.html
#===============================================================================
define poller {
poller_name poller-master
address localhost
port 7771

Chaque modification dans les fichiers de configuration nécessite le redémarrage de l'Arbiter.

Le démarrage de l’arbiter se fait :

soit en relançant l’ensemble des démons avec service shinken restart,

soit en lançant la commande suivante pour ne lancer que l'arbiter.

root@ctShinken:~# service shinken-arbiter restart Restarting arbiter Doing config check

Je reviens au menu Shinken

Supervision des services avec Shinken