[Debian 9] Découverte et utilisation de Check_MK avec Shinken pour Windows

La supervision permet à l’administrateur système de pouvoir être informer et visualiser aisément les problèmes techniques sur son réseau. Pour l’aider à accomplir cette tâche Check_MK vient nous épauler.

INFORMATION IMPORTANTE ! L'article n'est pas totalement à jour pour une Debian 9, notamment pour superviser un Windows. Vous aurez ici une ébauche d'installation et un exemple d'utilisation qu'il faudra très certainement adapter selon vos besoins. L'article sera re-factorisé...

Shinken (& Nagios) jouissent d’une pléthore de plugins disponibles pour faciliter cette supervision. Ainsi, des fonctionnalités avancées peuvent être ajoutées, d’autres modifiées de façon exponentielle, ou encore quelques unes qui automatisent toute (ou presque) la supervision. Grâce à « Check_MK« , votre serveur de supervision verra sa productivité augmenter de manière importante !


Brève présentation

« Check_MK » est un plugin qui facilitera la vie de TOUS les administrateurs systèmes & réseaux.
En effet, ce dernier se charge seul de collecter les informations relatives aux hôtes sur le réseau. Cette collecte est possible par l’installation d’un plugin sur les clients (check-mk-agent), et d’un paquet sur le serveur (check-mk-server) pour superviser le parc.
Ainsi, il est alors possible d’obtenir des informations relatives au CPU, à la RAM, sur le(s) HDD, les partitions, la quantité de Swap utilisée, le nombre de processus actifs et bien plus encore suivant les matériels supervisés.

Ce plugin est à la base préconfiguré pour une installation sous Nagios3. Toutefois, il est possible de l’adapter pour Shinken et ainsi profiter de sa puissance.

Site web officiel : http://mathias-kettner.com/index.html


I. Installation sur le serveur Shinken

Dans cet article, l’installation se fait via le fichier .deb directement téléchargeable sur le site officiel de Check_MK.

Sur le serveur, il faut installer au préalable « xinetd » – Check MK utilise ce serveur web pour corréler les informations des hôtes supervisés. Il est aussi utilisé pour effectuer les connexions & transmissions entre le serveur de supervision & l’envoi / réception des données clients.

Lorsque « xinetd » est installé, c’est le moment de télécharger Check_MK « serveur ».
Attention, avec les nouvelles éditions, il existe plusieurs versions – Il faut prendre la « RAW » qui correspond à votre distribution (dans mon cas, une Debian 9.3 64 bits). Tous les téléchargements sont à cette adresse.

Une fois le téléchargement effectué, il faut lancer le décompactage et l’installation de Check_MK – Attention, cela peut prendre du temps en fonction de la puissance de votre serveur – :


II. Modification du fichier de configuration « check-mk-server » pour le serveur xinetd.

Quelques modifications sont nécessaires pour le bon fonctionnement du paquet.
Vous devez entrer dans le fichier « check_mk » situé dans le serveur « xinetd » ; des variables doivent être modifiées pour que Check_MK puisse communiquer & être utilisable avec Shinken.

  • Modification de l’utilisateur : changer « root » en« shinken »

Note :
Pour éviter les tentatives de piratage et les problèmes de droits, l’utilisateur qui a les droits pour utiliser Check_MK est le même que Shinken. Dans notre exemple, l’utilisateur en question est « shinken ».

Vous pouvez modifier cet utilisateur, mais il faudra répercuter ce changement partout (fichiers de configuration de Shinken, check_mk et les autres plugins si besoin est).
  • Changer un attribut en fin de fichier : « disable : yes » par « disable : no »

Explications :
Par défaut, l’agent de Check_MK est désactivé.
Il faut donc l’activer pour récupérer les données des clients monitorés et faire fonctionner le paquet.


III. Installation de l’agent « Check-mk » sur les clients du parc informatique

Pour les besoins de nos tests, les machines ont tous des IP fixes.

a) Installation sur le client LINUX (Debian / Ubuntu) à monitorer

Sur tous les clients Linux à monitorer, deux paquets doivent être installés pour permettre la collecte et l’envoi des données au serveur de supervision.

  • On installe « xinetd » aussi sur le client pour permettre la communication & l’envoi de données avec le serveur de supervision. La configuration du serveur « xinetd » sera automatique.
  • « check-mk-agent » est autonome. Il ne nécessite aucune configuration préalable. Tout est gérer de façon transparente pour l’utilisateur et même pour le système.

b) Installation sur le client WINDOWS (XP Professionnel) à monitorer

La supervision d’un client Windows par Check_MK se passe par l’installation d’un service.
Check_MK fournit le logiciel exécutable pour installer et utiliser ce service de façon totalement transparente.

i. Installation du service (check_mk)

Depuis les récentes versions de Check_MK, il suffit de télécharger sur le site officiel le fichier exécutable pour Windows et le lancer, comme un programme à installer.

Lien de téléchargement : http://mathias-kettner.com/download/check-mk-agent-1.2.5i4p2.exe[/su_note]

L’installation se fait de manière automatique : un service est alors créé et lancé automatiquement par défaut lors du démarrage de l’ordinateur.

ii. Utilisation

Tout comme pour Linux, il n’y a pas de configuration au préalable à faire.
Le seul critère important pour l’utilisation de Check_MK sur Windows réside dans le fait que le service doit être lancé par un compte « Administrateur » ; les comptes « invité » ou « limités » (c'est à dire sans droits d'administration) de Windows ne pourront pas lancer le service Check_MK et donc, le PC ne pourra pas être monitoré.

A partir de cette étape, vous avez donc un client Linux & un client Windows XP Pro' de prêt à être monitorés.


IV. Liste des hosts à monitorer

Les hosts sont définis dans un fichier « /etc/check_mk/main.mk » qui sera lu par le « check-mk-server ». Il est possible d’y définir les hôtes par nom de machine, ou par IP.

On peut aussi y inclure les « parents » des hôtes, pour créer une hiérarchie et ainsi décomposer correctement le réseau.

a) Emplacements fichiers "Check_MK"

  • Fichier comprenant la définition des hôtes :

/etc/check_mk/main.mk

  • Fichiers / scripts de check utilisés par check_mk :

/usr/share/check_mk/checks

Dans le fichier "main.mk", vous devez entrer cette ligne ci-dessous pour que Check_MK puisse "voir" et communiquer avec les hôtes spécifiés.


V. Modification des droits d’utilisateur (pour Shinken)

Pour le bon fonctionnement du plugin sous Shinken, des modifications sur les droits et les propriétaires des dossiers sont obligatoires.

Si ces changements ne sont pas effectués, le plugin principal (check-mk-server) ne pourra communiquer avec ses agents sur les hôtes, et par conséquent aucunes informations ne seront remontées.

Explications :

  • Les dossiers & fichiers utilisés par Check_MK sont maintenant attribués pour l'utilisateur et le groupe "Shinken" ;
  • Les 2 fichiers de script ("/usr/bin/check_mk" & "/usr/bin/check_mk_server") sont maintenant sous la propriété du serveur Shinken, donc l'utilisateur "shinken" ;
  • Le script "/usr/bin/check_mk" est rendu exécutable pour pouvoir lancer des tests sur le serveur d'une part, mais aussi sur les clients monitorés.


VI. Modification des fichiers de configuration de Check_MK

Check_MK est "à la base" préconfiguré pour être en adéquation avec Nagios. Étant donné que Shinken se fonde sur Nagios, il est donc possible d’adapter Check_MK pour Shinken.
Il faut cependant modifier les chemins et autres liens symboliques qui sont à la base fait pour une configuration avec Nagios.

  • Fichier "/usr/share/check_mk/modules/defaults"
  • Fichier "/usr/share/check_mk/modules/check_mk.py"

Les deux fichiers sont liés. La modification dans l’un doit être faite dans l’autre aussi, pour éviter tout problèmes de concordance et d’utilisation du plugin.


VII. Création de la liste des processus à surveiller sur les hosts

Check_MK se crée une liste des tâches : "Quels services / processus devront être surveillés suivant le type d’hôte et le protocole utilisé ?"

La commande si dessous n’affiche pas de résultats visibles.
Les « checks » sont envoyés et reçus de façon transparente.

Si la connexion est effectuée sans problème, rien ne s'affichera dans le terminal : La commande sera exécutée, la connexion effectuée, et aucuns résultats affichés (ce qui est normal).
L'étape suivante permet d'avoir les résultats...


VIII. Récupération des résultats fournis par le « check-mk-agent » des hosts monitorés

Après avoir effectué les tests, il est tout de fois possible de voir les résultats de ces derniers en CLI.

Les listes peuvent être plus ou moins longues suivant l’OS, le protocole et les services installés sur les hôtes.

Exemple de résultat du plugin Check_MK


IX. Création du fichier de configuration de Check_MK pour Shinken

Check_MK a de nombreux avantages... En plus d’obtenir une multitude d’informations utiles pour la supervision, il est aussi possible de créer les fichiers de configuration nécessaires pour Nagios (et donc Shinken).
Par conséquent, nous évitons l’écriture de centaines voire de milliers de lignes à la main et les erreurs de frappe, de syntaxes et autres.
Shinken est capable de lire les fichiers de configuration principalement étudiés et conçus pour Nagios, ce qui est en notre faveur.

Les fichiers de configuration des hôtes supervisés par Check_MK se situent par défaut dans « /etc/nagios3/conf.d/check_mk/ ». (Il est toutefois possible de modifier ce chemin).

Pour créer ce fichier de configuration, il suffit d’exécuter la commande ci-dessous :

Selon les hôtes paramétrés dans le serveur, la création peut prendre plus ou moins de temps ; En temps normal, il ne suffit qu'à peine une petite minute pour créer se fichier de configuration.


X. Intégration des fichiers créés par Check_MK dans Shinken

Shinken à l’avantage d’être capable de lire les fichiers de Nagios.
Toutefois, il faut effectuer une petite modification dans le fichier « nagios.cfg » (/usr/local/shinken/etc/nagios.cfg) pour lui inclure le chemin où se trouvent les fichiers créés par Check_MK.

Il est préférable d’inclure tout le dossier pour la raison suivante : ce dossier contient non seulement la configuration des hôtes, mais aussi le « template » à utiliser (le modèle à utiliser).


XI. Rechargement de la configuration de Shinken

Une fois la création des fichiers faite, et l’incorporation dans Shinken, il ne reste plus qu’à redémarrer le service ("/etc/init.d/shinken-arbiter restart") pour recharger la configuration de Shinken.

Il est nécessaire d’effectuer le redémarrage de l’arbiter pour que la configuration de Shinken soit « relue » entièrement, et donc y inclure les tests et résultats fournis par Check_MK.

Vous avez maintenant une configuration fiable de Check_MK & ainsi, un serveur de supervision encore plus intelligent & autonome ![/su_note]

Julien H

Passionné depuis toujours par l'informatique, je transforme ma passion en expertise. J'utilise quotidiennement les outils et systèmes Microsoft. Je ne délaisse pas mon côté ouvert, notamment via l'utilisation des OS Debian et Archlinux. L'infosec m'ouvre les yeux sur les enjeux actuels et futurs de l'IT.

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.

Close
Close