Installation de Check_MK 

Présentation du projet

Au cours de ces six mois de stage chez Thales Underwater Systems, sur le site de Sophia Antipolis, j’ai été chargé de mettre en place une solution permettant à l’équipe SAT de superviser, en temps réel, l’ensemble des serveurs atelier. Ces serveurs atelier sont des machines physiques et virtuelles, qui intègrent des outils comme MatLab, Eclipse ou encore Orchestra. Ces machines permettent de mettre à disposition des employés une suite logiciels et de la puissance de calcul.
Pour répondre aux besoins de l’équipe, j’ai tout d’abord commencé par étudier différentes solutions parmi les plus utilisées dans le domaine. Le cahier des charges imposé m’a permis d’en retenir trois. J’ai ensuite présenté à l’équipe les avantages et inconvénients de chacune de ces solutions. A l’issue de cette présentation, nous avons retenu la solution de supervision Check_MK, car elle répondait le mieux aux exigences imposées.
Par la suite, j’ai pu commencer à mettre en place un prototype de la solution en installant Check_MK sur un serveur Linux dédié et en testant le fonctionnement de l’outil. Cette étape m’a permis de me familiariser avec Check_MK. J’ai poursuivi la construction de mon prototype en développant des scripts et en configurant la solution selon le cahier des charges.
Pour finir, j’ai procédé à la validation de chaque exigence du cahier des charges et à la rédaction de la documentation technique de la solution. Enfin, j’ai déployé la solution sur tous les serveurs atelier du site et j’ai formé l’équipe à l’utilisation de Check_MK.

Cahier des charges

Pour définir les besoins de l’équipe en termes de supervision des serveurs, la première étape a été d’étudier le cahier des charges et d’éclaircir chacune des exigences. Le cahier des charges se présente sous la forme suivante :
La colonne « Titre Exigence » définit l’exigence. La colonne « Validation » me permettra d’indiquer les tests que j’effectuerai pour valider l’exigence. La colonne « Validateur » me permettra d’écrire le compte rendu du test effectué pour valider l’exigence.
Le cahier des charges complet comporte 31 exigences. Il a donc été nécessaire, au début du stage, de discuter de chacune des exigences avec les administrateurs. Cette étape a permis de correctement définir chaque exigence et de parfaitement comprendre les besoins des administrateurs.
Durant cette phase, nous avons retiré deux exigences car aucun outil de supervision ne permet d’y répondre.
D’après mes recherches, c’est la solution Check_MK qui semble la plus appropriée. Néanmoins, j’ai préféré tester chacune des trois solutions.
Sur les sites dédiés à chacune des solutions, il est possible d’essayer l’outil grâce à une « live demo ». Ces « live demo » ne permettent pas de tester chacune des fonctionnalités, mais seulement d’avoir un aperçu de l’interface Web. L’interface Web est l’ensemble des pages, accessibles depuis un navigateur, qui vont permettre d’administrer l’outil et de présenter les informations récupérées sur chaque machine.
Comme je l’ai dit dans l’introduction, deux solutions de supervision avaient été mises en place par le passé. Leur complexité d’utilisation n’avait pas permis à l’équipe de maintenir à jour ces deux outils. Il me semblait donc indispensable de choisir l’outil le plus simple d’utilisation.
Après avoir testé chacune des « live demo », c’est Check_MK qui m’a paru la solution la plus appropriée. En effet, son interface Web présente un design beaucoup plus intuitif que Centreon ou Zabbix. Sa maintenance en est donc grandement facilitée.
Lors d’une réunion, j’ai ainsi présenté les avantages et inconvénients de chaque solution. J’ai également pu définir, grâce à mes recherches, de quelle manière chaque solution peut répondre à chaque exigence du cahier des charges. Pour simplifier la maintenance de la future solution, il fallait trouver l’outil permettant de répondre, nativement, au maximum d’exigences. La solution retenue a ainsi été Check_MK. J’ai alors commencé à me documenter sur la procédure d’installation de cet outil.
Durant toute la suite de mon stage, j’ai présenté l’avancement du projet, à l’équipe, lors de différentes réunions mais aussi en rédigeant un planning d’avancement hebdomadaire.

Présentation de Check_MK

Check_MK est une solution de supervision open source développée par Mathias KETTNER en 2008. Check_MK est en réalité une extension de Nagios, l’outil de supervision le plus connu et le plus utilisé en supervision système.
Check_MK collecte les informations sur les machines, mais utilise le coeur de Nagios pour les traiter. Cette solution intègre une interface Web beaucoup plus intuitive et des outils, comme PNP4Nagios et RRDTtool, qui permettent de réaliser des graphiques. Contrairement à Nagios, qui se configure à partir de fichiers texte, l’interface de Check_MK permet une configuration entièrement graphique.
Une dernière particularité de Check_MK est que cette solution intègre son propre agent, installé sur chaque machine à superviser, qui récupère toutes les informations d’une machine en une seule requête. La supervision est de ce fait plus performante et nécessite moins de ressources CPU et RAM pour le serveur qui héberge Check_MK. Il est ainsi possible d’utiliser un serveur virtuel plutôt qu’un serveur physique.
Au terme de ce premier mois de stage, j’ai pris connaissance des attentes de l’équipe pour le système de supervision que je devrai déployer.
Après plusieurs réunions, toutes les exigences du cahier des charges étaient correctement définies. J’ai ainsi pu commencer mes recherches afin de sélectionner des outils de supervision répondant aux besoins. Après avoir présenté les avantages et inconvénients de chaque solution, le choix s’est porté sur Check_MK.
Je pouvais ainsi passer à l’étape suivante, l’installation de Check_MK.
Pour tester les fonctionnalités de configuration de Check_MK, j’ai commencé par superviser mon propre serveur de supervision. Pour cela, il suffit de définir la nouvelle machine, en lui attribuant un nom et une adresse IP, puis de lancer la découverte des services. Cette étape va recenser toutes les ressources que Check_MK sait superviser en natif.
Mon serveur de supervision est maintenant supervisé. Je récupère des informations comme l’utilisation des CPU, de la RAM, des espaces disque, etc… On remarque que Check_MK sait déjà, par défaut, récupérer beaucoup d’informations utiles.
Même si Check_MK peut être entièrement configuré en graphique, son interface Web nécessite, du fait de sa richesse, un petit temps d’adaptation. J’ai ainsi passé quelques jours pour découvrir et me familiariser avec toutes les fonctionnalités de cette interface.

Sécurisation des connexions à l’interface web

L’interface Web de Check_MK utilise Apache, le serveur web de Linux. C’est mon serveur de supervision qui joue le rôle de serveur web.
Lorsque l’on souhaite se connecter à l’interface de Check_MK, via un navigateur, le serveur Apache va dialoguer en http avec le poste utilisateur. Malheureusement, en http, le dialogue client/serveur n’est pas chiffré. Toutes les requêtes passent en clair sur le réseau. Après avoir fait une analyse de trames avec Wireshark, je me suis aperçu que chaque requête, initiée par le poste utilisateur, contient les identifiants de connexions à l’interface (omdadmin : omd).

DE VELOPPEMENT VELOPPEMENT VELOPPEMENT VELOPPEMENT VELOPPEMENT ET VALIDATION ET VALIDATION ET VALIDATIONET VALIDATION

Dans cette troisième partie du stage, je pouvais commencer à répondre aux exigences plus techniques du cahier des charges. Pour cela, je devais développer des scripts permettant d’ajouter des fonctionnalités à Check_MK.
Enfin, je devais procéder aux tests et à la validation de chacune des exigences et présenter un prototype fonctionnel de la future solution de supervision.

Scripts locaux

Tout comme Nagios, pour récupérer des informations sur des machines, Check_MK utilise des plugins. Ces plugins sont des scripts, qui doivent se trouver sur chaque machine supervisée et qui sont exécutés en local, à intervalle de temps régulier. Check_MK se connecte ensuite sur la machine et récupère les résultats retournés par chaque plugin.
Par défaut, Check_MK propose près de 400 plugins génériques. Malheureusement, pour des applications particulières, si aucun plugin n’existe, il est nécessaire de développer ses propres plugins, appelés scripts locaux.
Ces scripts locaux, du fait qu’ils sont exécutés par la machine supervisée elle-même, peuvent être écrits dans n’importe quel langage exécutable par cette machine. Cependant, les données issues de ces scripts doivent respecter un certain format de sortie afin d’être compatibles avec Check_MK. Les arguments de sortie du script doivent ainsi se présenter sous la forme :
Enfin, si la charge dépasse les 95%, l’état devient « Critical ». Il faut intervenir tout de suite car le serveur est en surcharge anormale.
C’est donc la variable « Status » qui déclenche les alarmes sur l’interface Check_MK.
La variable « Script_Name » contient le nom du script qui sera affiché sur l’interface web.
La variable « Data » n’est pas obligatoire. Elle contient les données à afficher sur les graphiques. Ainsi, « Perfdata » contient la valeur mesurée à l’instant t par le script, « Warning_seuil » et « Critical_seuil » servent à tracer les seuils limites sur les graphiques.
Pour finir, la variable « Statustxt » contient le texte d’information qui sera affiché, sur l’interface web, en fonction de l’état de la ressource supervisée.

Développement de scripts locaux

Parmi toutes les exigences du cahier des charges, Check_MK ne peut pas, nativement, toutes les satisfaire. Ces exigences sont plus techniques et propres aux applications de Thales. Elles requièrent donc le développement de scripts locaux adaptés. J’ai développé au total une quinzaine de scripts permettant de récupérer des informations comme la vérification des mises à jour des antivirus Windows, l’état des sauvegardes des serveurs, la liste des applications installées sur chaque serveur, le nombre de licences utilisées pour certaines applications, etc…
Le développement des scripts a été une étape assez longue. J’ai en effet dû, pour chaque script, me documenter sur les différentes méthodes qui permettent de récupérer l’information souhaitée. J’ai ensuite testé plusieurs méthodes afin d’aboutir à un script performant, c’est-à-dire le plus léger possible en terme d’exécution et compatible avec toutes les versions de Linux (RedHat et CentOS), Solaris et Windows.
Les scripts que je vais devoir écrire nécessitent l’utilisation de commandes système. J’ai donc choisi de les développer en Shell sous Linux et en Bat sous Windows. De plus, ces langages restent assez simples de compréhension pour les administrateurs système. Il leur sera donc plus facile, dans l’avenir, de les maintenir à jour ou les modifier.

Validation des exigences du cahier des charges

Tout au long de la phase de développement des scripts, je devais également, en parallèle, tester et valider chaque exigence du cahier des charges.
Il fallait ainsi que je valide la compatibilité de la solution de supervision pour chaque système d’exploitation présent dans le parc de serveurs. Dans ce parc, on compte quatre systèmes d’exploitation déclinés en dix-huit versions :
Il était donc indispensable, avant de déployer la solution, de vérifier que l’agent de supervision installé sur les machines était bien compatible. Pour cela, j’ai installé l’agent de supervision sur des machines de test, puis j’ai testé et vérifié une quinzaine de points pour chaque version. Il fallait vérifier, pour ces quinze points, que les informations collectées par l’agent de supervision étaient bien celles que l’on pouvait observer directement sur la machine.
Les informations à vérifier étaient par exemple la quantité de mémoire totale et utilisée, la charge processeur, les espaces disque, les montages réseau, les paramètres de l’interface réseau ou encore les informations remontées par chaque script local, etc…
Je devais ensuite renseigner, dans la colonne « Validateur » du cahier des charges, la procédure que j’avais suivie pour valider l’exigence. Voici, pour exemple, un aperçu de colonne « Validateur » pour les espaces disque :

Déploiement

La solution de supervision doit être déployée sur une cinquantaine de machines Linux, Solaris et Windows. Le parc de serveurs ne contient que quatre serveurs Solaris. Ceux-ci migreront bientôt sous Linux et Solaris sera abandonné. Je n’ai donc pas écrit de script d’installation pour cet OS. Cependant, pour les machines restantes, je vais pouvoir déployer la solution très rapidement.
Après avoir installé l’agent de supervision sur chaque serveur, via les scripts d’installation, il ne reste plus qu’à ajouter les nouvelles machines dans Check_MK. Pour cela, il faut aller sur l’interface web et créer ces nouvelles machines :
La solution de supervision est maintenant déployée sur toutes les machines. Près de 50 serveurs et 750 ressources sont vérifiés toutes les trois minutes. Dès qu’un problème survient sur un serveur, l’équipe est maintenant prévenue dans les trois minutes.
Afin de permettre à l’équipe de maintenir à jour l’outil, c’est-à-dire pouvoir ajouter/supprimer des serveurs, ajouter des ressources à superviser, modifier la configuration de l’interface web, etc…, j’ai, tout au long du stage, rédigé une documentation de soixante pages.
Dans cette documentation, j’ai décrit l’architecture du serveur de supervision, rédigé toutes les procédures d’installation de l’outil ainsi que des tutoriels détaillant la configuration de chaque fonctionnalité disponible dans l’interface web.

CONCLUSION

Durant ces six mois de stage, j’ai tout d’abord commencé par étudier le cahier des charges. J’ai ainsi pu sélectionner différentes solutions de supervision répondant le mieux aux exigences imposées. Cette étape m’a permis de retenir trois solutions parmi les plus connues dans le domaine de la supervision. Après avoir présenté chacune des solutions, Check_MK a été retenu.
J’ai ensuite pu débuter la construction d’un prototype de la solution de supervision. Pour cela, j’ai installé Check_MK sur un serveur virtuel dédié et je me suis servi de machines de test Linux, Solaris et Windows sous différentes versions.
Dans un premier temps, j’ai installé l’agent de supervision sur les machines de test afin de vérifier la validité des informations remontées par Check_MK (utilisation CPU, RAM, espace disque, etc…).
Une fois ceci fait pour chaque version de chaque OS, j’ai commencé à travailler sur les fonctionnalités, souhaitées par l’équipe, qui n’étaient pas disponibles en natif. Cette étape a été assez longue et a demandé de nombreuses recherches. J’ai, en effet, développé plusieurs scripts, en Bat et en Shell, permettant de récupérer en temps réel l’utilisation des licences de chaque logiciel, l’utilisation des espaces disques en réseau, le déroulement des sauvegardes, les mises à jour de l’antivirus, etc… La complexité de cette étape a été de développer des scripts Linux entièrement compatibles avec toutes les versions de Linux, de même pour Windows et Solaris. J’ai ainsi dû, pour chaque script, tester différentes méthodes afin d’aboutir à un script fonctionnant pour toutes les versions de chaque système d’exploitation. Ces scripts devaient, de plus, être les plus légers possible afin d’être exécutés rapidement par les machines supervisées, sans altérer les performances.
Enfin, mon prototype terminé, j’ai pu valider chacune des exigences du cahier des charges et déployer la solution de supervision. Pour faciliter l’installation de l’agent de supervision et la supervision de futurs serveurs, j’ai développé des scripts d’installation Linux et Windows. J’ai également rédigé une documentation technique d’une soixantaine de pages détaillant le fonctionnement et la configuration de la solution et des scripts locaux. Cette documentation permettra à l’équipe de maintenir à jour l’outil de supervision.
Au terme de ce stage, les objectifs fixés ont donc été atteints. J’ai en effet su proposer une solution de supervision complète qui répond au cahier des charges imposé.
Comme demandé, cette solution n’altère pas les performances des machines ni la bande passante du réseau.
L’outil de supervision devait être simple à maintenir à jour afin de ne pas être abandonné par l’équipe. Durant la phase de développement et configuration, j’ai toujours gardé cela à l’esprit et je pense avoir livré une solution facile d’utilisation.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

REMERCIEMENTS 
PRESENTATION DE L’ENTREPRISE 
PRESENTATION DU PROJET 
INTRODUCTION 
I. CHOIX DE LA SOLUTION 
1. Cahier des charges
2. Etude des solutions
3. Présentation de Check_MK
II. INSTALLATION DE CHECK_MK
1. Installation de Check_MK
2. Supervision du serveur de supervision
3. Sécurisation des connexions à l’interface web
III. DEVELOPPEMENT ET VALIDATION 
1. Scripts locaux
2. Développement de scripts locaux
3. Validation des exigences du cahier des charges
IV. DEPLOIEMENT DE LA SOLUTION
1. Supervision d’une machine Linux
2. Supervision d’une machine Windows
3. Déploiement
CONCLUSION 
ANNEXE 1 
ANNEXE 2 
1. Script qui récupère l’utilisation des montages NFS
2. Script qui récupère l’utilisation des licences pour une application donnée
TABLE DES ILLUSTRATIONS 

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *