Schaub RPA 1

HES-SO // MASTER

L

Projet dapprofondissement, orientation Technologies de linformation et de la communication (TIC)

PLUGIN POUR SHINKEN

rdig par

LIONEL SCHAUB

Sous la direction de

Prof. Grald Litzistorf

de la MRU TIC de hepia

8 Juin 2012

HES-SO//MASTER Projet d'approfondissement 8 Juin 2012

Schaub Lionel ~ 2 / 57 ~ HEPIA



Printemps 2012

Projet d'Approfondissement

Rsum: Plugin pour Shinken

Le but de ce travail est, dans un premier

temps, d'effectuer une tude des outils de

supervision de systmes informatiques et

plus particulirement de l'outil Shinken.

Puis dans un second temps, de dvelopper

un plugin pour Shinken.

Ce travail s'est droul sur quatorze

semaines et a t ralis en quatre tapes:

Choisir une distribution Linux, installer Shinken et dfinir un scnario simple.

Mettre en pratique ce scnario et effectuer un rapport technique sur l'architecture et le fonctionnement de Shinken.

Effectuer un tat de l'art des solutions de monitoring.

Dvelopper un plugin pour Shinken.

L'analyse des outils de supervision commence par une recherche des besoins en mesure de

disponibilit.

L'tude de Shinken comprend une analyse des processus et des connexions rseau utilises

par les diffrents daemons. Cette tude comprend galement une analyse des possibilits

de configuration de Shinken.

Durant les premires semaines, un scnario simple a t conu dans le but de tester

l'architecture et le bon fonctionnement de Shinken. Une attention particulire a t apporte

l'analyse des diffrents dlais prsents dans l'ordonnancement et l'excution des tests.

Le plugin dvelopp doit tre capable de dtecter si un site web a t victime d'un web

defacing. Ce plugin doit, par consquent, proposer une mthode efficace de comparaison de

pages web. Il doit galement tre capable de dtecter une modification malveillante qui

modifie radicalement l'apparence de la page web tout en modifiant trs peu le code source.

tudiant: Schaub Lionel



Table des matires

1. Avant-Propos ................................................................................................................................................... 7

1.1. Rgles typographiques .......................................................................................................................... 7

1.2. Lexique................................................................................................................................................... 7

1.3. Remerciements ...................................................................................................................................... 7

2. Prsentation .................................................................................................................................................... 8

3. Cahier des charges .......................................................................................................................................... 8

4. Besoins oprationnels de mesure de disponibilit ......................................................................................... 8

4.1. Affichages personnaliss ....................................................................................................................... 8

4.2. Ordonnancement des tests ................................................................................................................... 9

4.3. Seuils ...................................................................................................................................................... 9

4.4. Facteur business .................................................................................................................................... 9

4.5. Notifications .......................................................................................................................................... 9

4.6. Affichage en temps rel ....................................................................................................................... 10

4.7. Dmarche proactive ............................................................................................................................ 10

4.8. SLA Service Level Agreement ............................................................................................................ 10

4.9. Besoins annexes .................................................................................................................................. 10

5. tat de l'art .................................................................................................................................................... 11

5.1. Solutions de supervision ...................................................................................................................... 11

5.1.1. Nagios .............................................................................................................................................. 11

5.1.2. Shinken ............................................................................................................................................ 12

5.1.3. Centreon .......................................................................................................................................... 13

5.1.4. MRTG ............................................................................................................................................... 13

5.1.5. Cacti ................................................................................................................................................. 14

5.1.6. Zabbix .............................................................................................................................................. 14

5.1.7. Icinga ............................................................................................................................................... 15

5.1.8. EyesOfNetwork................................................................................................................................ 15

5.1.9. BoardVisor ....................................................................................................................................... 16

5.1.10. NetCrunch ................................................................................................................................... 17

5.1.11. Traverse ...................................................................................................................................... 17

5.1.12. Tivoli Monitoring ......................................................................................................................... 18

5.1.13. OpenView ................................................................................................................................... 18

5.2. Comparatif ........................................................................................................................................... 19

5.3. Comparaison de Nagios et de Shinken ................................................................................................ 19

6. Scnarios de test ........................................................................................................................................... 21



6.1. Test ICMP (Ping) d'une machine .......................................................................................................... 21

6.1.1. Notions temporelles ........................................................................................................................ 22

7. Choix de larchitecture matrielle et du systme d'exploitation .................................................................. 24

8. Architecture de Shinken ................................................................................................................................ 25

8.1. Daemons (Services) ............................................................................................................................. 25

8.1.1. Arbiter ............................................................................................................................................. 25

8.1.2. Scheduler ......................................................................................................................................... 25

8.1.3. Poller ............................................................................................................................................... 25

8.1.4. Broker .............................................................................................................................................. 26

8.1.5. Reactionner ..................................................................................................................................... 26

8.1.6. Receiver ........................................................................................................................................... 26

8.2. Modules ............................................................................................................................................... 26

8.3. Plugins et agents .................................................................................................................................. 27

8.3.1. Langages de programmation ........................................................................................................... 27

8.3.2. Spcifications .................................................................................................................................. 27

8.3.3. Agents.............................................................................................................................................. 27

9. Documentation de Shinken ........................................................................................................................... 27

10. Analyse du fonctionnement de Shinken .................................................................................................. 28

10.1. Processus ouverts ................................................................................................................................ 28

10.2. Ports ouverts ....................................................................................................................................... 29

10.3. Communications rseau ...................................................................................................................... 30

11. Fichiers de configuration.......................................................................................................................... 31

11.1. Spcifiques Shinken .......................................................................................................................... 31

11.2. Semblables Nagios ............................................................................................................................ 31

11.3. Vrification des fichiers de configuration ............................................................................................ 33

12. Mise en pratique du scnario .................................................................................................................. 33

12.1. Ajout d'un contact ............................................................................................................................... 33

12.2. Ajout d'un groupe de contact .............................................................................................................. 33

12.3. Ajout d'une machine (host) ................................................................................................................. 34

12.4. Recherche et configuration d'une commande .................................................................................... 34

12.5. Ajout d'un service une machine ....................................................................................................... 34

12.6. Ajout d'un groupe de machines .......................................................................................................... 35

12.7. Redmarrage de Shinken ..................................................................................................................... 35

13. Dveloppement des Plugins ..................................................................................................................... 36

13.1. Vrification de l'espace disque ............................................................................................................ 36



13.1.1. Mise en application ..................................................................................................................... 36

13.1.2. Tests effectus ............................................................................................................................ 38

13.2. Web Defacing ...................................................................................................................................... 39

13.2.1. Dfinition .................................................................................................................................... 39

13.2.2. Exemple ...................................................................................................................................... 39

13.2.3. Choix du plugin ........................................................................................................................... 40

13.2.4. Choix du langage de programmation .......................................................................................... 40

13.2.5. Comparaison de deux pages web ............................................................................................... 40

13.2.6. Structure du plugin ..................................................................................................................... 43

13.2.7. Configuration du plugin dans Shinken ........................................................................................ 44

13.2.8. Tests effectus ............................................................................................................................ 45

13.2.9. Amliorations possibles .............................................................................................................. 45

14. Difficults rencontres ............................................................................................................................. 46

14.1. Proprits de configuration non documentes ................................................................................... 46

14.2. Plugins non inclus par dfaut .............................................................................................................. 46

14.3. Comprhension de la logique et du fonctionnement des fichiers de configuration ........................... 46

14.4. Recherche d'informations dans les sources ........................................................................................ 46

14.5. Problme d'ordonnancement des tests des htes .............................................................................. 46

14.6. Utilisation de check_by_ssh ................................................................................................................ 46

14.7. Comparaison de deux listes en Python................................................................................................ 47

15. Rpartition du temps ............................................................................................................................... 47

16. Conclusion ................................................................................................................................................ 48

17. Liens utiles & rfrences .......................................................................................................................... 49

A. Annexes ......................................................................................................................................................... 50

A.1. Installation de CentOS 6.2 ................................................................................................................... 50

A.2. Configuration rseau (sur CentOS) ...................................................................................................... 50

A.3. Installation de Shinken 1.0 .................................................................................................................. 51

A.4. Installer des plugins ............................................................................................................................. 51

A.5. Installation et configuration du systme d'envoi d'emails .................................................................. 52

A.6. Installer un serveur SSH sur Ubuntu .................................................................................................... 52

A.7. Gnrer une paire de clefs pour SSH ................................................................................................... 53

A.8. Plugin check_ordonnanceur ................................................................................................................ 53

A.9. Installer Beautiful Soup ....................................................................................................................... 55

B. Tables des illustrations .................................................................................................................................. 56



1. Avant-Propos

1.1. Rgles typographiques

Ce document a t rdig avec la police d'criture Calibri 10pt, en suivant les rgles typographiques suivantes:

Les liens vers des pages web sont en bleu soulign (http://example.com).

Les liens vers des emplacements dans ce document sont souligns (Rgles typographiques).

Les lgendes sont en police Calibri 9pt gras et de couleur bordeaux (Lgende).

Les notes de bas de page sont en police Calibri 10pt.

Certains mots importants sont en gras (important).

Le contenu des fichiers texte est en police Courier New 9pt sur fond gris clair (Fichier texte).

Les commandes sont en police Courier New 10pt (Commande).

Les chemins pointant vers de fichiers ou des dossiers sont en italique (/tmp/mon-fichier).

Les couleurs des captures d'cran de la console ont t inverss pour obtenir du noir sur blanc et ainsi

amliorer la lisibilit et viter un gaspillage inutile d'encre/tonner.

1.2. Lexique

Ce lexique dfinit certains termes utiliss dans ce document:

Supervision: En informatique la supervision est la surveillance du bon fonctionnement dun systme,

d'un service ou dune activit.

Outil de supervision: Un outil de supervision est un programme permettant d'accomplir une ou

plusieurs tches utiles dans le cadre d'une supervision informatique.

Solution de supervision: Une solution de supervision regroupe un ou plusieurs outils de supervision

dans le but de former un ensemble rpondant aux attentes en matire de supervision.

Machine: Dans ce document, le terme machine correspond tout priphrique informatique

connect au rseau (routeurs, serveurs, ordinateurs de bureau, machines virtuelles, ).

Test: Dans le contexte de Shinken ou de Nagios, un test correspond l'excution d'un plugin.

1.3. Remerciements

Je tiens remercier M. Grald Litzistorf pour m'avoir suivi dans ce travail. Je tiens tout particulirement le

remercier pour l'aide qu'il m'a apport dans la rdaction de ce document.

Je remercie aussi M. Sbastien Pasche pour avoir donn l'ide d'effectuer ce PA (Projet d'Approfondissement)

sur Shinken.

Je remercie galement M. Jean Gabes (crateur de Shinken) pour avoir pris le temps de rpondre mes

questions concernant les sources de Shinken.

Je tiens aussi remercier toutes les personnes qui ont particip la relecture de ce document.



2. Prsentation

Le but de ce travail est, dans un premier temps, d'installer et d'tudier le systme de monitoring open source

Shinken 1 puis de le comparer Nagios

2 et aux autres systmes de monitoring.

La seconde partie consiste dvelopper un plugin pour Shinken utilisant peu de ressources et pouvant profiter

de l'volutivit de l'architecture de Shinken.

L'nonc est galement disponible sur le site web du laboratoire de transmission de donnes l'adresse

suivante : http://www.tdeig.ch/shinken/Plugin_pour_Shinken.pdf

3. Cahier des charges

Le cahier des charges effectif (ci-dessous) diffre du cahier des charges original prsent dans l'nonc. Ces

changements rsultent d'adaptations effectues au dbut du projet avec mon professeur responsable.

Le cahier des charges effectif est le suivant:

Choisir une distribution Linux, installer Shinken (avec une configuration minimale) et dfinir un

scnario simple.

Mettre en pratique ce scnario et effectuer un rapport technique sur l'architecture et le

fonctionnement de Shinken.

Effectuer un tat de l'art des solutions de monitoring.

Dvelopper un plugin pour Shinken.

Certaines parties importantes de Shinken telles que la haute disponibilit et la rpartition de charge ne sont

pas traites dans cette tude.

4. Besoins oprationnels de mesure de disponibilit

Les besoins oprationnels dans le domaine de la mesure de disponibilit varient beaucoup en fonction du corps

de mtier. En effet, un administrateur des systmes IT verra le taux de disponibilit comme une qualit de

service, tandis que le directeur financier verra le taux d'indisponibilit comme une perte de gain.

4.1. Affichages personnaliss

Il est courant de dire que l'administrateur systme veut voir uniquement les machines qui ont un problme,

tandis que le directeur veut voir que toutes les machines fonctionnent. On remarque que la manire dont les

produits prsentent l'information doit tre dpendante du type d'utilisateur.

1 Site web officiel de Shinken : http://www.shinken-monitoring.org/

2 Site web officiel de Nagios : http://www.nagios.org/



4.2. Ordonnancement des tests

Un autre aspect des besoins oprationnels rside dans la configuration de l'ordonnancement des tests.

Le premier paramtre de configuration des tests qui vient l'esprit est l'intervalle entre deux vrifications.

Un autre paramtre important est le nombre de tests conscutifs retournant une erreur effectuer avant de

considrer la machine comme tant dans un tat critique. On peut prendre l'exemple simple d'une machine qui

ne rpond pas une requte ICMP Request. Faut-il immdiatement la considrer comme prsentant un

problme ou effectuer un second test de vrification ? La quasi-totalit des solutions de supervision sur le

march permettent de configurer ces paramtres.

Un autre paramtre important est la possibilit de dfinir des plages horaires o la machine peut subir un

incident sans tre considre comme ayant un problme. Ceci permet, par exemple, d'viter de rveiller trois

heures du matin le technicien de piquet pour aller redmarrer un service qui est utilis uniquement la journe

en interne.

Il est galement important de pouvoir dfinir une priode de maintenance. Durant cette priode la machine ne

sera pas considre comme ayant un problme.

4.3. Seuils

Il peut tre intressant de dfinir des seuils. Shinken utilise (comme Nagios) le code de retour des plugins pour

dterminer le statut d'une machine ou d'un service.

Il y a quatre codes possibles :

0: Ok

1: Warning

2: Critical

3: Unknown.

On peut, par exemple, configurer le plugin check_ping pour effectuer trois requtes ping la suite et si le

temps de rponse est suprieur 3 secondes ou si un ping est rest sans rponse il retourne Warning. En

revanche, si plus de 1 ping est rest sans rponse ou si le temps d'attente dpasse 5 secondes check_ping

retournera Critical. La ligne de commande pour le scnario ci-dessus est la suivante:

check_ping -H $HOSTADDRESS$ -w 1,50 c 2,70% -p 3.

Le chapitre 6.1.1. fournit plus de dtails sur les seuils et les notions temporelles. Le chapitre 12. fournit plus

d'informations sur la configuration de check_ping.

4.4. Facteur business

Un nouveau facteur commence s'imposer dans le monde de la supervision. Il s'agit de l'importance (appele

parfois criticit) d'une machine pour le business. Prenons l'exemple d'une entreprise de vente en ligne o l'un

de leurs quatre serveurs DNS cesse de fonctionner. Cet incident n'a pas d'effet sur le business de l'entreprise.

Si, par contre, leur unique serveur web ne fonctionne plus, c'est presque toute l'activit commerciale qui

s'arrte. De cet indicent peut rsulter une perte financire non ngligeable ainsi qu'une insatisfaction des

clients.

4.5. Notifications

Il existe galement un besoin d'tre notifi. Lorsqu'un service ne fonctionne plus, il n'est pas ncessaire de

prvenir toute l'quipe IT, seules les personnes concernes doivent tre averties par email ou par SMS. Le



moment de l'envoi de la notification est galement important. On peut imaginer qu'un technicien doit tre

inform le plus rapidement possible, tandis que le responsable IT aimerai peut tre recevoir la fin de la

journe un rapport journalier des diffrents incidents qui se sont produits pendant la journe.

Il est aussi important de grer les notifications en fonction de la dure du problme. Si un technicien reoit une

alerte importante et qu'une heure plus tard le problme est toujours prsent, il est intressant de pouvoir

envoyer l'alerte son suprieur ou un technicien de niveau suprieur.

4.6. Affichage en temps rel

Un technicien charg de la surveillance d'un rseau IT aura besoin d'un affichage en temps rel de l'tat du

rseau pour lui permettre de visualiser certaines informations telle que l'volution de la charge des serveurs ou

des liens formant le rseau IP.

4.7. Dmarche proactive

L'historique est un outil souvent ncessaire pour trouver la cause d'un incident ou tout simplement pour faire

des statistiques et prvoir les investissements futurs pour le maintien de la stabilit du rseau. On peut donc

faire du Risk Management et de la statistique pour dterminer la probabilit qu'un problme survienne,

l'impact que ce problme peut avoir sur l'infrastructure IT et sur le business.

4.8. SLA Service Level Agreement

L'historique est galement ncessaire pour prouver et mesurer le taux de disponibilit d'un serveur. Dans des

contrats de SLA un taux de disponibilit infrieur un taux souvent trs lev (par exemple 99.999%) se traduit

par une compensation financire au bnfice du client. L'historique permet, dans ce cas, d'viter qu'un client

tente d'abuser le prestataire de service en lui faisant croire que son serveur tait indisponible alors que ce

n'tait pas le cas. L'historique permet galement de calculer correctement la part financire qui doit tre

redistribue au client en cas d'indisponibilit.

4.9. Besoins annexes

La mesure de disponibilit est une activit importante dans la gestion d'un parc informatique, nanmoins elle

ne peut pas tre utilise seule. D'autres outils doivent tre utiliss en association un systme de mesure de

disponibilit. Voici une liste non exhaustive de systmes annexes:

Systme de gestion de base de donnes (SGBD) pour la sauvegarde des donnes de supervision

(incident, SLA, ).

Systme d'inventaire du matriel et/ou du logiciel.

Systme de suivi de problmes3.

Systme de gnration de rapports.

Systme de mesure de charge4 et de performances.

3 Wikipedia : http://fr.wikipedia.org/wiki/Systme_de_suivi_de_problmes

4 Des dtails sur la mesure de charge sont disponibles dans mon travail de Bachelor :

http://www.tdeig.ch/kvm/schaub_M.pdf



5. tat de l'art

5.1. Solutions de supervision

La supervision est un sujet qui est devenu une source de proccupation lorsque les entreprises ont commenc

avoir plusieurs serveurs avec chacun plusieurs services.

Les solutions de supervision sont apparues suite un besoin d'automatiser les vrifications du bon

fonctionnement des diffrents services informatiques (serveur web, connexion la base de donnes, etc.).

La plupart des logiciels de supervision open source que l'on trouve actuellement sont bass sur le trs clbre

Nagios. Comme le cur de Nagios est principalement maintenu par une seule personne (Ethan Galstad), les

propositions de modification de code sont rarement traites. C'est une des raisons au nombre important de

logiciels bass sur Nagios.

Cet tat de l'art prsente treize produits dont huit open sources et cinq propritaires.

Pour la majorit des outils gratuits prsents ci-dessous, il existe une version avec un abonnement de support

et/ou de services.

5.1.1. Nagios

Nagios est une application permettant de surveiller l'tat des htes d'un rseau et des diffrents services

prsents sur ces derniers. Il est cod

en C sous licence GPL et est

disponible sur les systmes Linux et

*nix.

Nagios est aujourd'hui le systme le

plus utilis en entreprise. Malgr sa

grande popularit, beaucoup

d'utilisateurs n'en sont pas

pleinement satisfaits. Certains

dveloppeurs ont tent de proposer

des modifications du code source

Ethan Galstad. Ce dernier tant peu

ractif et acceptant rarement les

propositions d'amliorations, des

dveloppeurs ont commenc crer des forks5 de Nagios. C'est de l que sont ns la plupart des nombreux

fork de Nagios.

Nagios est divis en trois parties :

Moteur : Ordonnance les tches de supervision (test du fonctionnement du serveur web, etc.).

Interface web : Affiche l'tat du rseau et les anomalies.

Les plugins : Chaque plugin est un logiciel indpendant charg de faire une vrification puis de

transmettre le rsultat Nagios.

Site officiel : http://www.nagios.org

5 Fork sur Wikipdia : http://fr.wikipedia.org/wiki/Fork_(dveloppement_logiciel)

Figure 1 - Capture d'cran de Nagios

(source: http://www.nagios.com/products/nagioscore/screenshots)



5.1.2. Shinken

Shinken est une application rcente, gratuite et dont le dveloppement est trs actif. Elle a vu le jour en 2009.

Son code est sous licence AGPL. Shinken peut fonctionner sur toutes les plateformes supportant le logiciel

Python.

C'est une rimplmentation de

Nagios en langage Python qui ajoute

de nouvelles fonctionnalits

orientes performance. Parmi ces

fonctionnalits on peut noter la

haute disponibilit et la possibilit

d'tre distribu. Pour raliser ces

amliorations le systme a t

dcoup en plusieurs parties

(appeles daemon dans le reste de

ce document).

Ces diffrents daemons peuvent

tre rpartis sur plusieurs machines.

Le passage de Nagios Shinken se fait

de manire aise car Shinken utilise le

mme format de fichiers de configuration que Nagios. Il est uniquement ncessaire d'adapter les fichiers de

configuration spcifiques Shinken si l'on ne souhaite pas garder les paramtres par dfaut.

Shinken intgre le facteur business (business impact sur la figure ci-dessus). Le dclenchement des alertes et

les notifications sont paramtrables de manire prcise. Il dispose d'un systme de dtection de flapping6

permettant d'viter des temptes d'alertes.

Plus d'informations sur le projet Shinken sont disponibles cette adresse :

http://www.shinken-monitoring.org/project/

Site officiel : http://www.shinken-monitoring.org/

6 Une machine est en tat de flapping lorsque son tat change constamment.

Figure 2 - Capture d'cran de Shinken

(source: http://www.shinken-monitoring.org/screenshots/)



5.1.3. Centreon

Centreon est un logiciel de supervision driv de Nagios. Il est sous licence GPLv2.

On peut le voir comme une interface web pour

Nagios, plus volue que l'interface de base de

Nagios. L'interface web contient tout ce que

contient l'interface de base de Nagios tout en

tant plus conviviale. Elle ajoute galement de

nombreux graphiques gnrs l'aide de l'outil

RRDTool.

Il permet de gnrer des rapports sur les

incidents. Les donnes sont stockes dans une

base de donnes MySQL. L'interface web est

multiutilisateur et gre des listes de contrle

d'accs pouvant tre paramtres de manire

trs prcise.

Centreon permet de crer une architecture distribue

pour rpartir la charge et/ou effectuer une rpartition sur diffrents sites gographiques.

Bien qu'il fonctionne par dfaut avec Nagios, il est possible d'utiliser Centreon avec Shinken.

Site officiel : http://www.centreon.com/

5.1.4. MRTG

MRTG (qui signifie Multi Router Traffic Grapher) est un logiciel sous licence

GPL qui utilise le protocole SNMP pour communiquer avec les quipements

compatibles. Il cre des graphiques avec les informations obtenues via SNMP.

Il est compatible avec tous les systmes supportant Perl.

L'auteur de MRTG a galement conu RRDTool. RRDTool (Round-Robin

Database Tool) est un logiciel qui implmente les fonctionnalits de

gnration de graphique de MRTG ainsi qu'une base de donnes cyclique.

RRDTool est utilis dans d'autres outils de supervision telle que Cacti.

Site officiel : http://oss.oetiker.ch/mrtg/

Figure 3 - Capture d'cran de Centreon

(source: http://www.centreon.com/)

Figure 4 - Capture d'cran de

MRTG



5.1.5. Cacti

Cacti est un logiciel open source (sous licence GPL) de supervision de rseau. Il est bas sur le systme de base

de donnes RRDTool. Son interface est principalement peuple de graphiques indiquant l'tat du rseau.

Il gre nativement le SNMP et peut facilement tre intgr d'autres

sources de donnes telles que Nagios ou Shinken.

Cacti est souvent considr comme le successeur de MRTG (lui aussi

bas sur RRDTool).

Cacti dispose d'un poller qui se charge de tester le bon

fonctionnement de services des intervalles prdtermins. Ce

poller existe en deux versions, l'une code en PHP pour les petites

architectures et une autre code en C pour les architectures plus

grandes.

Site officiel : http://www.cacti.net/

5.1.6. Zabbix

Zabbix est une solution de supervision gratuite facile mettre en place. Il est sous licence GPLv2. Une licence

commerciale est galement disponible pour les entreprises dsirant intgrer Zabbix leur produit propritaire.

Actuellement cette solution ne contient pas

de mcanisme performant pour viter des

temptes d'alertes. Zabbix contient un

systme d'affichage en temps rel de l'tat

des machines surveilles. Il contient

galement de nombreux graphiques

permettant de visualiser l'volution au cours

du temps de l'infrastructure surveille. Il

dispose d'un systme de gestion de SLA. Il

fournit une gestion fine des droits d'accs

des utilisateurs.

L'architecture de Zabbix peut tre dcompose

en trois parties:

Le serveur de stockage de donnes (MySQL, PostgreSQL ou Oracle)

L'interface web de gestion

Le serveur de traitement

Zabbix dispose d'un systme de rpartition de charge et de haute disponibilit. Les trois parties de Zabbix

peuvent tre sur des machines diffrentes. Le serveur de traitement peut galement avoir des "proxy Zabbix".

Un proxy Zabbix est une machine supplmentaire qui peut tre utilise pour traiter une partie des donnes

lorsque la charge de la machine principale devient trop leve.

Site officiel : http://www.zabbix.com

Figure 5 - Capture d'cran de Cacti

Figure 6 - Capture d'cran de Zabbix

(source: http://www.zabbix.com/screenshots.php)



5.1.7. Icinga

Icinga est un fork de Nagios. Il a t cr par des dveloppeurs qui taient actifs sur le projet Nagios et qui

n'apprciaient pas le manque de ractivit du dveloppeur principal de Nagios ainsi que sa volont de ne pas

rendre tous les plugins libres.

Icinga est, comme Nagios,

disponible uniquement sur les

plateformes Linux et *nix. Il

est crit en C et sous licence

GPL. Il est rtro-compatible

avec la configuration et les

plugins Nagios.

Icinga dispose d'un systme

de gnration de rapports et

de dtection des oscillations

d'tat (flapping).

Il est disponible en deux

versions7:

Icinga Classic

Icinga New Web

La version Icinga New Web dispose d'un systme de gestion de SLA.

Site officiel : http://www.icinga.org/

5.1.8. EyesOfNetwork

EyesOfNetwork est un pack comprenant plusieurs logiciels lis la supervision. Il est sous licence GPLv2 et est

distribu sous forme d'une version minimaliste et personnalise de CentOS.

Il dispose d'une interface web unifie

qui permet aux diffrents acteurs

(administrateurs, techniciens, ) d'un

systme d'information d'accder une

version de l'interface personnalise

leur corps de mtier.

Il comprend notamment:

Nagios

Cacti

EONWEB : Interface Web

unifie du produit

Get-Info: Systme de gnration

de documents

7 Comparaison des deux versions de Icinga avec Nagios : https://www.icinga.org/nagios/feature-comparison/

Figure 8 - Capture d'cran de EyesOfNetwork

Figure 7 - Capture d'cran de Icinga

(source: https://www.icinga.org/screenshots/)



Toutes les informations rcoltes sont stockes dans une base de donnes MySQL ou BERKELEY.

Dans la dernire version d'EyesOfNetwork (v3.0), Shinken (v0.6.5) a t intgr en Beta.

Site officiel : http://www.eyesofnetwork.com/

5.1.9. BoardVisor

BoardVisor est une solution propritaire dite par la socit IDCWARE. BoardVisor se veut simple d'utilisation,

par consquent il n'y a aucun fichier de configuration diter, tout se fait via une interface web.

La solution est ralise sur mesure, seuls les

modules ncessaires au client sont intgrs.

Elle est livre clefs en main, l'installation est

effectue par IDCWARE et doit tre

totalement fonctionnelle lors de sa livraison.

BoardVisor est divis en trois parties:

Les Gatherers : Ce sont des sondes-

agents qui sont charges de

collecter les donnes.

Le Harvester : Il traite les

informations reues des Gatherers,

stocke les informations dans une

base de donnes et met jour le

GUI grce un mcanisme push (il

envoie l'information l'interface

web sans qu'elle ne l'ait demande). Les Gatherers peuvent tre distribus sur plusieurs machines.

Le GUI8 : C'est l'interface web de gestion. Il affiche de manire intuitive les informations en

provenance du Harvester.

BoardVisor contient une fonction de gnration de rapports. Il gre galement l'inventaire du matriel et des

logiciels.

Site officiel : http://www.idcware.com/la-solution/

8 GUI - Graphical User Interface

Figure 9 - Capture d'cran de BoardVisor



5.1.10. NetCrunch

NetCrunch est un logiciel propritaire dit par la socit AdRem Software. Son prix est de 1'500 $ pour 50

priphriques surveills.

Il fonctionne selon l'architecture

client-serveur. Il y a le serveur

NetCrunch et le client (console

d'administration) qui est un

logiciel avec une interface

graphique se connectant au

serveur pour afficher les

donnes. Un client web est

galement disponible.

Il fonctionne sans agent et peut

utiliser des sources

d'informations telles que SNMP,

les journaux d'vnement de

Windows et les serveurs Syslog sous

Linux. Il contient un systme de module permettant d'tendre le systme. NetCrunch 6 contient plus de 2'000

modules prinstalls.

NetCrunch intgre des fonctionnalits de gestion de la disponibilit, de gestion de la performance des serveurs

et de gnration de rapports. Il dispose galement d'un systme de dcouverte automatique de la topologie du

rseau.

Il peut aussi tre utilis pour faire un inventaire du matriel et des logiciels.

Site officiel : http://www.adremsoft.fr/netcrunch/

5.1.11. Traverse

Traverse est une solution propritaire dite par Zyrion. Une dition

gratuite de dmonstration est disponible. Le prix de l'dition

standard varie avec la taille du rseau surveill et commence

50'000 $.

Traverse intgre des fonctionnalits de gestion de SLA, de

performance du rseau et de gestion de parcs de machines

virtuelles et de Clouds. Il gre les environnements virtualiss

VMware, XenServer, KVM et Hyper-V.

Il propose des vues reprsentant la topologie physique du rseau et

des vues business permettant de voir en temps rel la performance

du service informatique.

Site officiel : http://www.zyrion.com/products/

Figure 11 - Capture d'cran de Traverse

(source: www.zyrion.com/products/)

Figure 10 - Capture d'cran de NetCrunch

(source: http://fr.wikipedia.org/wiki/NetCrunch)



5.1.12. Tivoli Monitoring

Tivoli Monitoring est une solution propritaire dveloppe par la socit IBM.

Il fait partie de la suite de logiciel Tivoli. Depuis la version 6.1 il ne repose plus sur le framework Tivoli, il utilise

le moteur d'une solution concurrente (rachete par IBM) nomme Omegamon (dite l'origine par Candle

Corp).

Il est compos des lments suivants :

Tivoli Data Warehouse (TDW) :

Sauvegarde les donnes de supervision dans

une base de donnes SQL.

Tivoli Entreprise Monitoring Server (TEMS) :

Il lance les tests sans agent et communique

avec les agents puis il envoie les donnes

sauvegarder au TDW.

Tivoli Entreprise Portal Server (TEPS) :

Permet d'accder distance au TDW grce

une interface web.

Tivoli Common Reporting (TCR) :

Fournit des rapports en fonction des donnes prsentes dans le TDW.

Tivoli Monitoring fournit des agents permettant de rcuprer des informations sur l'tat des machines. Ces

agents sont prvus pour continuer fonctionner lorsque le rseau est interrompu ou dans le cas o le serveur

de supervision ne fonctionne plus. Si un tel cas se produit les agents distribus sur les machines vont

sauvegarder les informations et les transmettre au serveur de supervision ds que ce dernier est nouveau

joignable. Tivoli Monitoring est aussi utilisable sans agent (agentless).

Site officiel: http://www-142.ibm.com/software/products/fr/fr/tivomoni

5.1.13. OpenView

OpenView est un logiciel propritaire dvelopp par la socit HP. En 2007, il a t renomm HP Network

Management Center.

La suite HP OpenView contient une multitude de

logiciels. Parmi ces logiciels, on trouve notamment:

HP OpenView Network Node Manager (OV

NNM) : Charg de surveiller le rseau et les

services rseau l'aide du protocole SNMP.

HP Operations Manager (OM) : Surveille les

systmes qui utilisent des agents. Il existe un

agent pour les systmes Windows (OMW) et

un agent pour les systmes Unix (OMU).

HP OpenView Performance (OVP*) : Logiciels

permettant de surveiller les performances de

diffrents quipements.

HP OpenView Storage : Permettant de grer le

stockage des informations de supervision.

Figure 12 - Schma de la solution Tivoli Monitoring

(source: www.ibm.com)

Figure 13 - Capture d'cran de HP OpenView Internet

Services



HP OpenView Smart Plug-ins (SPI) : Plugins permettant de superviser une base de donnes, un

systme VMware, un systme SAP, etc.

HP Software Business Availability Center (BAC) : Fournit des services de gestion de SLA, de gestion

d'utilisateurs, etc.

Site officiel: http://www8.hp.com/us/en/software/enterprise-software.html

5.2. Comparatif

Nom Licence Langage Systme d'exploitation Commentaires Prix

Shinken AGPL Python Linux, Windows, Compatible Nagios Gratuit Nagios GPL C Linux, Unix Gratuit Centreon GPLv2 PHP/Perl/C Linux, Unix Utilise Nagios, RRDTool Gratuit Cacti GPL PHP/Shell/C Linux, Unix Bas sur RRDTool Gratuit Zabbix GPLv2 PHP/C Linux, Mac, Unix Gratuit Icinga GPL PHP/C Linux Fork de Nagios Gratuit EyesOfNetwork GPLv2 Multi OS ddi (CentOS) Package contenant Nagios Gratuit MRTG GPL Perl Linux, Windows, Gratuit NetCrunch Propritaire N/A Windows > 1'500 $ BoardVisor Propritaire N/A OS ddi Payant Traverse Propritaire N/A Linux, Windows > 50'000 $ Tivoli Propritaire N/A Linux, Windows > 750 $ Open View Propritaire N/A Windows, HP-UX Payant

Tableau 1 - Comparaison des solutions de supervision

5.3. Comparaison de Nagios et de Shinken

Shinken tant une rimplmentation de Nagios, il est intressant de comparer leur tat de dveloppement.

Est-ce que Shinken a rimplment toutes les fonctionnalits de Nagios ? Quelles sont les fonctionnalits

phares de Shinken ?

Parmi les fonctionnalits phares de Shinken on peut relever:

Scalabilit et haute disponibilit.

Utilisable sur toutes les plateformes supportes par Python.

Notion d'importance pour le business.

Possibilit de mettre un Poller dans la DMZ et un Poller dans le LAN pour viter une configuration

complexe et risque du pare-feu.

Nagios possde nanmoins certaines fonctionnalits qui ne sont pas disponibles dans Shinken:

Pearl embarqu.

Modules binaires.

Replanification automatique des tests.

Il est intressant de comparer l'volution du nombre de lignes de code au cours du temps.



Figure 14 - Shinken - Nombre de lignes de code

Figure 15 - Nagios - Nombre de lignes de code

On remarque sur les schmas ci-dessus (fournis par www.ohloh.net) que Shinken est nettement plus jeune que

Nagios. On remarque aussi les mthodes de dveloppement des deux logiciels. En effet Nagios se dveloppe

peu et s'est dvelopp par -coups. Shinken, quant lui, se dveloppe rapidement (200'000 lignes de codes en

3 ans). Son code est parfois refactor et des lments inutiles sont supprims. La baisse brutale du nombre de

lignes de code en septembre 2010 correspond la suppression des fichiers XML contenant l'aide au profit du

Wiki (http://www.shinken-monitoring.org/wiki).



6. Scnarios de test

6.1. Test ICMP (Ping) d'une machine

Ce scnario trs simple consiste tester le fonctionnement du systme en configurant un test ICMP (ping) sur

un hte du rseau. Ce test doit s'effectuer priodiquement un intervalle d'une minute.

Pour mettre en pratique ce scnario il faut disposer d'un ordinateur (ou d'une machine virtuelle) allum. En

dbranchant le cble rseau, on peut tester le passage de l'tat UP l'tat DOWN. A ce moment le serveur

Shinken doit envoyer un email de notification.

Quelques instants plus tard on rebranche le cble et la machine doit repasser l'tat UP puis envoyer un

second email de notification.

Les changements d'tats peuvent galement tre observs sur l'interface web de Shinken (WeUI).

Grce ce scnario, on teste le bon fonctionnement de toute l'architecture de Shinken.

La configuration et le test de ce scnario sont dtaills dans le chapitre Mise en pratique du scnario.

Figure 16 - WebUI - MachineA - Ping Ok



6.1.1. Notions temporelles

Lorsque l'on utilise des outils de monitoring il est important de garder l'esprit les notions temporelles du

systme. En effet, si l'on configure un test ICMP pour qu'il s'effectue toutes les minutes, il faut garder l'esprit

qu'il peut se produire plus d'une minute avant qu'une machine indisponible soit dtecte comme telle.

Si on prend le pire des cas, il faudra attendre une minute plus le temps d'attente maximal (5 sec.) pour que

Shinken dtecte le problme. Dans le meilleur des cas il faut le temps d'attente maximal (5 sec.) pour qu'un

problme soit dtect par Shinken. Nous avons donc un temps de dtection qui se situe entre 5 secondes et 65

secondes.

A cela vient s'ajouter le temps d'envoi d'un email et l'intervalle de vrification des emails configure sur le

client de messagerie du technicien. Cet intervalle ne s'applique pas si la messagerie fonctionne en mode Push.

Le diagramme en flche ci-dessous prsente les dlais, le meilleur des cas et le pire des cas pour le scnario

dcrit ci-dessus. Pour simplifier la figure, elle ne montre pas l'intervalle de vrification des emails. On considre

donc tre dans le cas d'une messagerie configure en mode Push.

Figure 17 - Diagramme de squence d'un test ICMP simple

Dans le diagramme ci-dessus on remarque que le dcompte de temps commence ds que le test est effectu.

Pour dterminer si Shinken commenait le dcompte de temps aprs avoir lanc le test ou aprs que le test se

soit termin, un plugin a t dvelopp. Voir l'annexe Plugin check_ordonnanceur.

Il faut aussi garder l'esprit que si la machine ou le rseau subit des mini coupures d'une ou deux secondes il y

a peu de chances que ces coupures soient dtectes. Le diagramme ci-dessous dcrit ce problme.

Machine A Shinken Technicien

ICMP Request

ICMP Reply

ICMP Request

Envoi d'un email (critical)

Temps de rponse (< 100ms)

Dlai dpass (5sec)

Intervalle de test (1min)


ICMP Request

Temps de rponse (< 100 ms)

Envoi d'un email (ok)

Pire des cas

(~1min 5 sec)

Meilleur des cas

(5 sec)

Machine A Down

Machine A Down

Machine A Up

ICMP Reply



Figure 18 - Diagramme de squence d'un test ICMP simple avec microcoupures

Machine A Shinken Technicien

ICMP Request

ICMP Reply

ICMP Request

Temps de rponse (< 100ms)



ICMP Request

Temps de rponse (< 100 ms)

Machine A Up

Machine A Down

Machine A Up

Machine A Down

Machine A Up

Machine A Down

Machine A Up

Machine A Down

Machine A Up

Machine A Down

Machine A Up

Machine A Down

ICMP Reply Temps de rponse (< 100ms)

MicroCoupure (~1sec)





ICMP Reply



7. Choix de larchitecture matrielle et du systme d'exploitation

Pour des raisons de simplicit j'ai choisi d'installer Shinken et une machine Linux (Ubuntu) dans des machines

virtuelles.

Le logiciel de virtualisation utilis est VMware Player 3.1.3.

La version de Shinken utilise est la 1.0, sortie une semaine aprs le dbut du projet.

La machine Linux est un Ubuntu 10.04.3 LTS 64-bits.

Shinken est install sur une distribution CentOS 6.2 car c'est la distribution la plus utilise en entreprise. Elle est

galement utilise par les dveloppeurs de Shinken sur les machines de test et les machines en production.

Une machine virtuelle utilisable sous VMware Player avec Shinken 1.0 prinstall sous CentOS 6.2 est fournie

en annexe. Les procdures pour installer et configurer CentOS 6.2 et Shinken 1.0 sont disponibles en annexes.

Figure 19 - Schma bloc de l'architecture

VMware Player

CentOS (Shinken)

192.168.230.15

Ubuntu

192.168.230.30 Rseau virtuel NAT 192.168.230.0/24



8. Architecture de Shinken

Shinken est un outil de supervision dcoup en plusieurs parties. Le cur du systme correspond aux six

daemons. Il y a galement les modules qui permettent d'ajouter des fonctionnalits au cur de Shinken et des

plugins qui permettent d'effectuer les tests.

8.1. Daemons (Services)

Chaque daemon (except l'Arbiter) peut avoir plusieurs instances rparties sur plusieurs machines pour

permettre Shinken de supporter une plus grande charge et galement fournir de la haute disponibilit.

8.1.1. Arbiter

L'Arbiter est le seul daemon qui doit tre unique. Il est charg de grer tous les autres. Il lit les fichiers de

configuration puis envoie les parties utiles aux autres daemons. Il est galement charg de s'occuper de la

haute disponibilit, si un deamon devient indisponible, il doit transfrer la configuration de ce dernier un

daemon disponible. L'Arbiter est excut avec l'utilisateur root.

Il peut tre tendu grce des modules. Il existe, par exemple, un module pour recevoir les rsultats de tests

passifs NSCA.

8.1.2. Scheduler

Le Scheduler doit ordonnancer les tests. Il dtermine quel moment les tests doivent s'effectuer mais il ne

lance pas le check (rle du Poller). Il rcupre ensuite les rsultats des tests (check) et les transmets au

Reactionner et au Broker si ncessaire.

Il peut tre tendu grce des modules. Il y a peu d'intrt crer des modules pour le Scheduler, les seuls

modules prsents sont des modules pour implmenter la rtention de statut. Nanmoins la rtention de statut

est une fonctionnalit qui n'est pas utile avec l'architecture de Shinken.

8.1.3. Poller

Le Poller doit lancer les plugins tels que check_ping en fonction des instructions du Scheduler. Lorsque le plugin

se termine il renvoie le rsultat au Scheduler.

Il est possible de configurer un Poller dans la DMZ et un Poller dans le LAN pour viter une configuration

complique et dangereuse du firewall.

En effet, si on installe une machine Shinken dans la DMZ et que l'on souhaite superviser des machines dans le

LAN, il faudra crer dans le pare-feu une rgle pour chaque test que l'on souhaite effectuer dans le LAN.

Si l'on place un Poller sur une machine dans le LAN, il est possible de lui faire excuter les tests des machines

qui sont dans le LAN. Avec cette configuration il faut seulement ouvrir les ports ncessaires la communication

entre la machine Poller du LAN et la machine Shinken de la DMZ.

Cette configuration s'effectue grce au paramtre poller_tags9.

Il peut tre tendu grce des modules.

9 Page du wiki officiel expliquant comment effectuer cette configuration :

http://www.shinken-monitoring.org/wiki/setup_dmz_monitoring



8.1.4. Broker

Le rle du Broker est d'exporter les donnes en provenance du Scheduler. Il a besoin de modules pour exporter

les donnes dans diffrents emplacements.

Il y a, par exemple, un module pour exporter les donnes dans une base de donnes MySQL.

L'interface web de Shinken correspond au module WebUI du Broker.

8.1.5. Reactionner

Le Reactionner se charge des notifications selon les instructions du Scheduler. Il envoie, par exemple, les emails

d'alerte.

Il peut tre tendu grce des modules. Il existe un module nomm AndroidSMS qui permet d'envoyer des

SMS de notification lorsqu'il s'excute sur un tlphone mobile sous Android.

8.1.6. Receiver

Le Receiver est le seul daemon qui est facultatif. Son rle est de rceptionner les tests passifs et de les stocker

temporairement dans un tampon. C'est l'Arbiter qui se charge de rcuprer les rsultats. Il a besoin de modules

pour communiquer avec les diffrents protocoles. Par dfaut, il y a un module Nagios NSCA qui gre le systme

de plugin passif NSCA de Nagios. Un test passif est un test qui n'est pas ordonnanc par Shinken. Dans le cas

d'un systme NSCA les donnes sont envoyes par l'agent send_nsca.

8.2. Modules

Les modules sont des extensions des daemons. Certains daemons tels que le Broker et le Receiver fonctionnent

uniquement avec des modules.

Les modules sont prsents dans le dossier /usr/local/shinken/shinken/modules/.

Ces derniers hrite de la classe BaseModule.

Figure 20 - Module AndroidSMS - hritage BaseModule

Chaque module doit galement dfinir des proprits.

Figure 21 - Modules AndroidSMS - dfinition des proprits

Dans les proprits ci-dessus on remarque le daemon auquel il est associ et le nom du module. Ce module se

nomme donc android_sms et est un module pour le Reactionner.



8.3. Plugins et agents

Les plugins sont des logiciels excutables. Ils sont chargs d'effectuer un test sur une machine et renvoyer un

rsultat. Elles sont excutes par le Poller. Comme Shinken utilise les mmes spcifications que Nagios pour les

plugins, les plugins Nagios sont compatibles avec Shinken et inversement.

Les plugins sont prsentes dans le rpertoire /usr/local/shinken/etc/libexec/.

8.3.1. Langages de programmation

Ces commandes peuvent tre programmes dans n'importe quel langage de programmation. Dans le cas d'un

langage compil il faut que l'excutable soit compatible pour la plateforme sur laquelle il va tre excut. Dans

le cas d'un langage interprt il faut que l'interprteur soit install sur la machine et que le Shebang10

soit

prsent au dbut du script. Dans le cas de Shinken il est pratique d'utiliser le langage (interprt) Python car

Shinken tant cod en Python il est certain que Python est prsent sur le systme. Actuellement, la plupart des

plugins de Shinken viennent de Nagios et sont cods en C.

8.3.2. Spcifications

La seule contrainte est l'obligation pour ces commandes de dfinir leur code de retour par une valeur

spcifique au rsultat de la commande. Les commandes, dans la plupart des cas, prennent en argument le nom

d'hte ou l'adresse IP de la machine tester. Les codes de retour possibles sont les suivants :

0 : Ok

1 : Warning

2 : Critical

3 : Unknown

Le statut Unknown (inconnu) est souvent utilis lorsque les arguments de la commande sont errons. Un texte

peut galement tre crit sur la sortie standard pour fournir une information supplmentaire. Nanmoins seul

le code de retour sera trait dans la logique de Shinken.

Les spcifications compltes des plugins sont disponibles ici :

http://www.shinken-monitoring.org/wiki/official/development-pluginapi

8.3.3. Agents

Un agent est un logiciel qui s'excute sur les machines que l'on souhaite tester. Il permet de rcuprer de

l'information directement sur la machine puis la transmettre un plugin de Shinken lorsqu'elle en fait la

demande. Les agents doivent tres compils pour les architectures (type de processeur et systme

d'exploitation) des machines qui doivent tre testes. Ceci peut tre gnant dans le cas o le parc de machines

est trs htrogne.

9. Documentation de Shinken

La documentation de Shinken est disponible l'adresse http://www.shinken-monitoring.org/wiki .

Elle est, dans l'ensemble, bien faite. Il arrive cependant que certaines informations soient errones.

Depuis la version 1.0 la documentation s'est grandement amliore.

On peut librement effectuer des corrections en crant un compte.

10

Page Wikipdia concernant le Shebang: http://fr.wikipedia.org/wiki/Shebang



10. Analyse du fonctionnement de Shinken

10.1. Processus ouverts

Dans la capture ci-dessous on voit les processus Shinken ainsi que l'utilisateur sous lequel ils s'excutent. On

voit aussi le fichier de configuration associ au deamon.

Figure 22 - Processus Shinken et fichier de configuration associ

Shinken est crit en Python. Comme Python est un langage interprt, tous les processus sont des processus

Python. En observant la ligne de commande qui a t utilise pour lancer le processus, on peut voir le

programme python qui a t lanc.

Avec la configuration par dfaut il y a (processus) :

2 Schedulers

3 Pollers

3 Reactionners

4 Brokers

2 Recievers

3 Arbiters

La raison pour laquelle il y a plusieurs processus par daemon provient des modules des diffrents daemons. Les

processus supplmentaires sont en ralit des processus fils. Avec la configuration dfaut (minimale) il y a un

processus pre par daemon.

Tous les processus sont excuts sous l'utilisateur shinken except les processus de l'Arbiter qui sont excuts

en tant que root.



Dans la capture ci-dessous j'ai ajout le paramtre -H qui permet d'afficher la hirarchie des processus.

Cette hierarchie peut aussi tre obtenue en regardant les colonnes PID et PID du pre.

Figure 23 Hirarchie des processus Shinken

10.2. Ports ouverts

En utilisant l'outil netstat on peut voir quel logiciel coute sur quel port.

Figure 24 - Liste des ports en coute par Shinken

La capture ci-dessus n'affiche pas suffisamment de dtails, on ne peut pas savoir quel daemon de Shinken est

associ quel port. On ne sait pas non plus si les processus Python sont des processus Shinken.

En se rfrant la liste des processus, on peut dterminer le daemon concern en comparant les PIDs.

Daemon Port

Broker 50000 Broker (module WebUI) 7767 Scheduler 7768 Reactionner 7769 Arbiter 7770 Poller 7771 Broker 7772 Receiver 7773

Tableau 2 - Ports et Deamons

J'ai effectu une recherche avec grep pour savoir dans quels fichiers et quel endroit se trouve la

configuration de ces ports.



Figure 25 - Recherche des ports dans les fichiers de configuration

Nom du fichier Ligne Port

brokerd.ini 15 7772 pollerd.ini 15 7771 reactionnerd.ini 7 7769 receiverd.ini 7 7773 schedulerd.ini 5 7768 shinken-specific.cfg 27 7767 shinken-specific.cfg 127 50000 shinken-specific.cfg 316 7771 shinken-specific.cfg 345 7769 shinken-specific.cfg 353 7772 shinken-specific.cfg 367 7770 shinken-specific.cfg 382 7768 shinken-specific.cfg 388 7773

Tableau 3 - Configuration des ports de communication

10.3. Communications rseau

Shinken utilise la bibliothque Pyro (PYthon Remote Objects)11

pour permettre aux deamons de communiquer

entre eux. Les connexions rseaux ne sont donc pas gres directement par Shinken.

Pour analyser les connexions rseau entre les deamons, les commandes netstat12

et ps13

ont t utilises pour rcuprer des informations sur les processus de Shinken et leurs connexions tablies ou en coute. En corrlant ces donnes il a t possible de crer le graphique ci-dessous.

Figure 26 - Schma ralis partir de l'analyse des connexions rseaux entre les daemons

11

Site officiel de Pyro : http://packages.python.org/Pyro4/ 12

Man page de netstat : http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man8/netstat.8.html 13

Man page de ps : http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man1/ps.1.html

Arbiter Reciver

Poller

Scheduler

Brocker

Reactionner



11. Fichiers de configuration

Les fichiers de configurations de Shinken se trouvent dans le rpertoire /usr/local/shinken/etc/ .

On peut distinguer deux types de fichiers de configuration. Il y a les fichiers de configuration qui sont

quasiment identiques ceux de Nagios et ceux qui sont spcifiques Shinken.

11.1. Spcifiques Shinken

Les fichiers de configuration spcifiques Shinken sont au format INI et portent l'extension du mme nom. La

seule exception est le fichier shinken-specific.cfg qui est un fichier CFG. Ce dernier est lu par l'Arbiter et

contient la configuration des daemons et la dfinition des modules. Il y a un fichier de configuration au format

INI par daemon. Ces fichiers sont utiliss pour configurer les paramtres d'excution et de configuration rseau

des deamons.

On y trouve:

L'utilisateur avec lequel le processus va tre lanc (shinken par dfaut).

Le rpertoire de travail.

Le numro de port et l'adresse IP de l'interface qu'il doit couter.

Des paramtres de certificats pour permettre la communication dans un canal SSL.

L'activation des logs.

Ces paramtres correspondent aux paramtres minimaux pour que l'Arbiter puisse se connecter aux autres

daemons et leur transmettre leur configuration dfinie dans shinken-specific.cfg.

Figure 27 - Fichiers de configuration des daemons Shinken

Dans le cas o Shinken est excut sous Windows, le nom de ces fichiers de configuration est suffix par "-

windows".

11.2. Semblables Nagios

Les autres fichiers de configuration sont des fichiers de configuration au format CFG.

Ces fichiers sont quasiment identiques ceux que l'on trouve dans Nagios dans le but de pouvoir effectuer une

transition de Nagios vers Shinken (et inversement) sans devoir rcrire la configuration.

C'est dans ces fichiers qu'est contenue la configuration des htes, des tests, des contacts, etc.

Ces fichiers sont tous inclus dans le fichier nagios.cfg qui est lu par l'Arbiter. L'Arbiter se charge ensuite de

rpartir la configuration vers les diffrents daemons.

Service

Fichier de

configuration



Figure 28 - Fichiers de configuration de l'infrastructure

Le tableau ci-dessous liste les diffrents fichiers de configuration et dcrit leur utilit. Il est nanmoins possible

d'crire la configuration dans n'importe quel fichier tant qu'il est inclus par le fichier nagios.cfg. Il est galement

possible de mettre toute la configuration dans le fichier nagios.cfg. La structure de ces fichiers est hrite de

Nagios et permet de mieux rpartir la configuration et de la rendre plus claire.

Les dfinitions de service dans les fichiers de configuration correspondent aux dfinitions des tests. Le nom

service provient de Nagios.

Nom du fichier Description

nagios.cfg Ce fichier inclut tous les autres fichiers de configuration et contient quelques paramtres gnraux.

commands.cfg Il contient la dfinition des commandes. Il fait la liaison entre les excutables du rpertoire libexec et le nom de la commande utilise dans la configuration des tests.

timeperiods.cfg

Ce fichier contient la dfinition des priodes temporelles telles que la semaine de travail ou encore les jours de congs. Ces priodes temporelles peuvent tre utilises pour configurer les priodes o des notifications ne doivent pas tre gnres.

escalations.cfg

Ce fichier est prsent pour des raisons de compatibilit avec Nagios. Cette configuration doit se faire dans le fichier shinken-specific.cfg. La configuration des escalades14 permet de dfinir des niveaux de contact et de contacter le niveau suprieur aprs n notifications ou aprs un temps t. La fonction temporelle est disponible uniquement sur Shinken.

dependencies.cfg Ce fichier permet de dfinir des dpendances entre un hte et un service ou un autre hte. Il est prfrable de dfinir la proprit service_dependencies pour les services.

contacts.cfg Ce fichier contient la dfinition des contacts. contactgroups.cfg Ce fichier contient la dfinition des groupes de contacts.

templates.cfg Ce fichier contient les templates qui permettent de dfinir les paramtres par dfaut pour les contacts, les htes et les services.

14

Escalades temporelles dans Shinken : http://www.shinken-monitoring.org/news/escalation-based-on-time-for-sla/

Service

Fichier de

configuration



servicesgroups.cfg Ce fichier contient la dfinition des groupes de services. hostgroups.cfg Ce fichier contient la dfinition des groupes d'htes. hosts Ce rpertoire est prvu pour contenir des fichiers CFG dfinissant les htes.

Tableau 4 - Description des fichiers de configuuration

11.3. Vrification des fichiers de configuration

Shinken vrifie les fichiers de configuration lorsqu'on le redmarre. Nanmoins il affiche uniquement les

erreurs de syntaxe.

La vrification enregistre des donnes plus dtailles dans le fichier /tmp/shinken_checkconfig_result. Ce

fichier donne des informations telles que les fichiers lus, les paramtres non reconnus qui sont prsents dans

les fichiers de configuration.

12. Mise en pratique du scnario

Pour configurer le scnario, trois fichiers ont t modifis et un fichier a t cr. La configuration par dfaut

des daemons n'a pas t modifie car elle correspond dj une configuration minimale.

12.1. Ajout d'un contact

Les contacts sont normalement ajouts dans le fichier etc/contacts.cfg. Le contact cr se nomme admin.

Il faut configurer l'adresse email pour recevoir les emails de notifications. Le champ use permet de se baser

sur un template qui contient les valeurs de configurations par dfaut. Pour plus de dtails voir le chapitre

Fichiers de configuration.

Figure 29 - Fichier de configuration des contacts

12.2. Ajout d'un groupe de contact

Le groupe de contacts admins a t cr avec comme seul utilisateur l'utilisateur admin cr prcdemment.

Les groupes sont gnralement ajouts dans le fichier etc/contactgroups.cfg.

Figure 30 - Fichier de configuration des groupes de contacts



12.3. Ajout d'une machine (host)

Un rpertoire nomm etc/hosts/ est prvu pour stocker les fichiers de configuration des machines. Le fichier

machinea.cfg a t cr avec la dfinition de la machine nomme MachineA. On remarque dans ce fichier qu'il

hrite du template generic-host. On remarque que le groupe de contacts associ cette machine est admins.

Figure 31 - Fichier de configuration de la MachineA

12.4. Recherche et configuration d'une commande

Les dfinitions des commandes se trouvent dans le fichier de configuration etc/commands.cfg. On y trouve la

commande check_ping qui appelle le plugin check_ping avec un certain nombre d'arguments. Ces arguments

signifient que le plugin va retourner Critical si la requte n'a pas reu de rponse aprs cinq secondes et

Warning si la requte a obtenu une rponse aprs trois secondes et avant cinq secondes. Elle indique

galement qu'une seule requte ICMP sera effectue.

Figure 32 - Fichier de configuration des plugins

12.5. Ajout d'un service une machine

Le service a t configur dans le mme fichier que la machine. Le paramtre host_name fait la liaison entre le

service et la machine (host). Le paramtre check_command fait la liaison entre le service et la commande

auquel il est associ. Le paramtre normal_check_interval permet de dfinir l'intervalle entre deux tests (en

min.) et le paramtre retry_check_interval permet de dfinir l'intervalle entre deux tests (check) lorsque le

dernier test a retourn Critical. Et pour finir le paramtre initial_state dfinit l'tat initial (avant que le premier

test n'ait t effectu) Unknown.

Timeout [s] Paquets perdus [%]

Nombre de requtes effectues

warning critical



Figure 33 - Fichier de configuration du test de la MachineA

12.6. Ajout d'un groupe de machines

Ces derniers sont gnralement crs dans le fichier etc/hostgroups.cfg. Un groupe nomm postes-clients a t

cr avec comme seule machine la MachineA cre prcdemment.

Figure 34 - Fichier de configuration des groupes de machines

12.7. Redmarrage de Shinken

Pour que la configuration soit prise en compte il faut redmarrer Shinken :

/etc/init.d/shinken restart



13. Dveloppement des Plugins

Dans le cadre de ce projet deux plugins ont t dvelopps. Ce chapitre dcrit les diffrentes tapes du

dveloppement de ces deux plugins. Les informations sur le systme de plugin de Shinken sont disponibles

dans le chapitre Plugins et agents de ce document.

13.1. Vrification de l'espace disque

Le plugin qui devait tre dvelopp devait permettre de vrifier l'espace disque restant d'une machine Linux

distante. Avant de commencer le dveloppement j'ai vrifi si un plugin similaire existait et j'ai trouv le plugin

check_disk parmi les plugins provenant de Nagios.

Ce plugin permet de vrifier l'espace disponible sur un disque dur local ou une partition locale. Comme le but

est de vrifier l'espace disponible d'une machine distante il faut trouver un moyen d'excuter ce script

distance. En me basant sur un travail15

effectu prcdemment au laboratoire de transmission de donnes par

M. Lescourt Adrien, j'ai dcouvert le plugin check_by_ssh qui permet d'excuter une commande distante grce

SSH et qui retourne ensuite le code de retour et le message retourn par la commande distante.

En combinant ces deux plugins il est possible de vrifier l'espace disque restant d'une machine distante. Vu que

la fonctionnalit dsire peut tre obtenue en combinant les plugins check_disk et check_by_ssh, c'est cette

solution qui a t mise en place plutt que de dvelopper un plugin.

Figure 35 - Schma du fonctionnement de la vrification de l'espace disque par Shinken

Pour commencer, le plugin check_ssh a t test localement sur la machine cible (machine distante). Une fois

cette tape termine, un serveur SSH a t install et configur sur la machine cible puis la connexion SSH

depuis la machine contenant Shinken a t teste. Ensuite, le plugin check_by_ssh a t test manuellement

depuis la ligne de commande de la machine contenant Shinken. Finalement, Shinken a t configur pour

excuter ce test sur la machine distante.

13.1.1. Mise en application

Tout d'abord, il faut s'assurer que la machine sur laquelle on veut excuter le test dispose d'un serveur SSH

actif. La procdure pour installer un serveur SSH est disponible dans l'annexe Installer un serveur SSH sur

Ubuntu.

Sur la machine Shinken il faut se connecter sous le compte shinken : su shinken

Sur la machine Shinken il faut gnrer les clefs l'aide de la commande ssh-keygen (accepter les

paramtres par dfaut).

15

Lien vers le travail de M. Lescourt : http://www.tdeig.ch/shinken/Adrien_Lescourt_PluginNagios.pdf

Shinken

check_by_ssh

Machine distante

check_disk 1. Excution de check_disk

2. Retourne le rsultat de l'excution

de check_disk

Connexion SSH



Une fois la paire de clefs cre il faut placer la clef publique sur le serveur SSH. Sur la machine Shinken lancer la

commande ssh-copy-id utilisateur@adresse-ip

Il faut maintenant approuver le serveur SSH. La mthode la plus simple est d'essayer de se connecter au

serveur SSH grce la commande ssh utilisateur@adresse-ip

L'empreinte de la clef du serveur SSH va s'afficher et un message demandera de la confirmer. Il faut vrifier que

l'empreinte correspond celle du serveur SSH et, dans le cas chant, confirmer la clef.

Il faut copier le plugin check_disk dans la machine distante. Une solution simple consiste utiliser SCP16

(copie

de fichier via SSH) :

scp libexec/check_disk utilisateur@adress-ip:/usr/local/shinken/libexec/

Se dconnecter du compte shinken : exit

Configurer une commande dans le fichier etc/commands.cfg :

Figure 36 - Commande check_ssh_disk

La commande dfinie ci-dessus vrifie, via SSH, l'espace disque de la partition monte dans le rpertoire

/media/testVolume. Si l'espace restant est infrieur 5% la commande renverra "Critical" et si l'espace restant

est infrieur 10% et suprieur 5% la commande renverra "Warning".

La dernire tape consiste crer un service associ la machine distante. Le service dfini dans la capture ci-

dessous est configur pour effectuer le test toutes les 10 minutes et toutes les minutes lorsque l'tat vaut

"Critical". Ceci permet de vrifier rapidement que l'tat est revenu Ok lorsque l'on a libr de l'espace disque.

Figure 37 - Service check_ssh_disk

Pour prendre en compte la nouvelle configuration il faut redmarrer Shinken :

/etc/init.d/shinken restart

16

Transfrer des fichiers avec SCP : http://cc.in2p3.fr/docenligne/134/fr



13.1.2. Tests effectus

Pour tester le bon fonctionnement de la configuration effectue ci-dessus, trois tests ont ts effectus.

13.1.2.1. Test du statut Ok

Des fichiers ont t placs sur la machine supervise de sorte ce que l'espace disque restant soit d'environ

85%. Au prochain test, Shinken affichait bien que l'tat de la machine tait "Ok".

Figure 38 - check_ssh_disk Ok

13.1.2.2. Test du statut Warning

Pour ce test un fichier a t ajout sur la machine supervise pour que le taux d'utilisation du disque soit de

91%. Quelques minutes plus tard, Shinken affichait la machine comme tant dans l'tat "Warning".

Figure 39 - check_ssh_disk Warning

13.1.2.3. Test du statut Critical

Pour tester l'tat "Critical" le disque dur de la machine supervise a t rempli 96%. Aprs que le test a t

effectu, Shinken affichait la machine comme tant dans un tat "Critical".



Figure 40 - check_ssh_disk Critical

Dans la capture ci-dessus on voit que le dernier test a t lanc il y a 8 secondes et qu'il s'est termin il y a 1

seconde. On peut donc dterminer que le test s'est excut pendant 7 secondes. On remarque galement que

le prochain test est planifi dans 59 secondes soit une minute aprs la fin du dernier test. Ce test valide donc

aussi la configuration effectue avec la proprit retry_check_interval.

13.2. Web Defacing

13.2.1. Dfinition

Certains hackers cherchent des failles sur des sites web et, lorsqu'ils en trouvent une, exploitent la faille dans le

but de modifier la page d'accueil sans avoir obtenu l'autorisation du propritaire du site. Cet acte est nomm

Web Defacing. La page web modifie contient gnralement un message relativement grand qui indique que le

site web a t "dfac".

13.2.2. Exemple

La capture ci-dessous montre la page d'accueil du site web IBM developerWorks aprs qu'il ait t "dfac".

Figure 41 - Page web du site http://www.ibm.com/developerworks/ en Juillet 2010



13.2.3. Choix du plugin

Le plugin que j'ai choisi de dvelopper doit permettre de dtecter si un site web a t "dfac".

Lors de la recherche d'une ide de plugin, la principale difficult fut d'en trouver un qui n'existait pas encore.

En effet, il existe une grande quantit de plugins dvelopps l'origine pour Nagios et qui fonctionnent donc

sur Shinken.

13.2.4. Choix du langage de programmation

Le langage de programmation que j'ai choisi est Python.

Ce langage ncessite que l'interprteur Python soit install sur la machine. Ceci est une fausse contrainte car si

on utilise Shinken il a lui-mme besoin de l'interprteur Python, donc si le plugin est utilis avec Shinken on est

certain que l'interprteur sera install. De plus, l'interprteur Python est install sur la quasi-totalit des

distributions Linux.

Un programme Python peut tre excut sur toutes les plateformes pour lesquels un interprteur Python est

disponible (Linux, Windows, MacOSX, Android, etc.).

J'ai galement choisi Python pour respecter la philosophie de Shinken ainsi que pour sa bibliothque standard

qui contient beaucoup de fonctions prtes l'emploi.

13.2.5. Comparaison de deux pages web

Une comparaison de deux pages web peut tre vue comme une comparaison de deux fichiers texte. La

comparaison de deux fichiers texte n'est pas une opration triviale.

13.2.5.1. Problmatique

En effet, si on utilise un algorithme naf, il va parcourir tous les caractres du fichier tout en comparant si le

caractre la mme position dans l'autre fichier est identique. Cet algorithme pose problme car, si l'on ajoute

un espace au milieu du fichier, tous les caractres suivants seront dcals et l'algorithme retournera un taux de

modification d'environ 50% alors que seul un caractre a t ajout.

13.2.5.2. Algorithme de recherche de la plus longue sous-squence commune

Pour viter ce problme, il faut crer un algorithme qui, pour chaque diffrence de caractre dtecte, va

tenter de retrouver la suite de la chane plus loin dans les fichiers. Si l'on prend l'exemple prcdent

l'algorithme va dtecter que l'espace ajout dans le deuxime fichier ne correspond pas au caractre du

premier fichier. Il va donc avancer d'un caractre dans le premier fichier et vrifier si le caractre correspond

un espace. Puis il va continuer d'avancer dans le fichier jusqu' arriver la fin du fichier. Ensuite il va revenir au

point o il a dtect la diffrence, puis il va avancer dans le deuxime fichier. A ce moment-l, il va sauter

l'espace qui a t ajout et il va continuer de comparer les fichiers avec un dcalage d'un caractre dans le

deuxime fichier. Ces tapes sont effectues chaque fois qu'une diffrence est trouve.

Cet algorithme s'appelle l'algorithme de recherche de la plus longue sous-squence commune. Son dfaut

majeur rside dans sa complexit algorithmique qui vaut dans le pire des cas O(n2) (n tant le nombre de

caractres) et dans le meilleur des cas (fichiers identiques) O(n). Nanmoins, il a l'avantage d'tre trs facile

implmenter en utilisant la rcursivit.



Figure 42 - Algorithme de recherche de la plus longue sous-squence commune en Python

Cet algorithme a t implment mais il n'est pas utilis dans le plugin car le temps de calcul est trop lev et

augmente exponentiellement en fonction du nombre de caractres.

13.2.5.3. Comparaison des lignes du fichier

Le plugin utilise une classe de la bibliothque Python standard appele difflib.SequenceMatcher. Cette classe

fournit deux mthodes intressantes:

ratio(): Cette fonction calcule le pourcentage de similarit entre deux fichiers texte. Elle implmente

l'algorithme de recherche de la plus longue sous-squence

Documents

Schaub RPA 1