Installer Shinken 3.0 sur CentOS 7 en 10 étapes

I. Présentation

La supervision est désormais ancrée dans les habitudes des entreprises. Cela permet de garder un œil sur les systèmes, les applications et d’anticiper éventuellement les incidents. Parmi les outils permettant de faire de la supervision, on a tous en tête le célèbre Nagios.

Depuis maintenant quelques années un nouveau venu est apparu dans le paysage des outils de supervision : Shinken. Issu d’une maquette (ou Proof Of Concept appelé aussi POC), Shinken a été complètement repensé en fonction des fonctionnalités de Nagios pour permettre une évolution plus complète. L’auteur de Shinken : Jean Gabes, a souhaité réécrire complètement l’application en utilisant Python (pour une grande souplesse d’utilisation et de programmation).

En fait, chaque fonction possède alors son rôle et, de fait, son service sous-jacent. On distingue ainsi cinq grandes familles de services :

- Arbiter : le chef d’orchestre qui pilote tout.
- Scheduler(s) : le(s) planificateur(s) permettant d’ordonnancer les traitements.
- Reactionner(s) : interrogent les schedulers pour connaître la liste des tâches à exécuter.
- Poller(s): interrogent aussi les schedulers pour connaître les contrôles à réaliser.
- Broker(s) : en charge du stockage des données envoyées.

Outre ses services, Shinken s’appuie sur de nombreux modules (aussi appelés plugins) permettant de compléter les fonctionnalités de l’outil et peut être découpé en royaume (répartis généralement selon un découpage réseau logique : DMZ, LAN, Réseaux privés). Cela permet de superviser tous les équipement et applications d’une infrastructure, du plus petit poste de travail jusqu’à la suite logicielle la plus complexe.

La découverte des équipements de l’entreprise se programment et se font approximativement de la même façon qu’avec Nagios. Cela étant, comme l’outil est développé en Python, l’installation n’est pas aussi simple que précédemment.

Personnellement, je préfère passer mon temps à autre chose qu’une installation. Aussi, je vous propose de parcourir les dix étapes constituant une installation complète de Shinken 3.0 sur une distribution CentOS7.

II. Création de l’environnement et prérequis

En premier lieu, comme pour toute application, il faut isoler l’environnement dans lequel on va installer et configurer le logiciel. Pour se faire, on va donc créer un utilisateur Shinken et lui associer un mot de passe :

# useradd shinken
 # passwd shinken
 Password :********
 Re-type Password :*******

Ensuite, Shinken nécessite de nombreuses couches logicielles dont l’environnement Python. Mais, pour y parvenir, il faut aussi installer le package du dépôt officiel EPEL :

# yum install –y epel-release

 

III. Installation d’outil supplémentaires

Maintenant, on peut installer les différents packages nécessaires à l’initialisation de Shinken, soient les packages suivants :

- python-pycurl
- python-setuptools
- python-pymongo
- mongodb
- git

# yum install –y python-pycurl python-setuptools python-pymongo mongodb git

Pour installer Shinken, il existe trois méthodes principales :

- via l’utilitaire pip : permettant d’ajouter à l’environnement Python les modules nécessaires et téléchargeable depuis le package EPEL. Cette méthode est, de loin la plus simple et on peut aussi utiliser le programme easy_install afin d’activer l’utilitaire pyro qui permet de dialoguer directement avec Python.

- via l’installation du package : à ce jour, il existe bien un package shinken. Mais, il ne contient que les outils pour administrer les modules de l’outil. D’après le site officiel, le package devrait rapidement être disponible pour les distributions Debian/Ubuntu, Fedora/RedHat/CentOS. Mais, en attendant, cette solution n’est pas envisageable.

- via les sources Shinken : si l’on souhaite disposer d’un serveur gérer par le gestionnaire de package, effectuer une compilation de sources n’est pas forcément la meilleure solution.

Vous l’aurez compris, il est préférable de favoriser la première méthode. Mais, il faut alors installer pyro :

# easy_install pyro

 

IV. Clonage de la branche Git du projet Shinken

Maintenant, on est prêt à récupérer le contenu à jour de Shinken. On va donc cloner via github la branche active du projet. Il vaut mieux le faire dès maintenant sous le futur compte propriétaire :

# su - shinken
 $ git clone https://github.com/naparuba/shinken.git

Cela va alors créer un sous-répertoire shinken dans lequel on trouve l’intégralité du projet. Si l’on est connecté au compte shinken précédemment créé, on doit donc se déplacer dans /home/shinken/shinken.

REMARQUE : l’opération peut durer un certain temps et dépend fortement de la vitesse de votre bande passante sur Internet.

 

V. Installation de l’application Shinken

Il faut alors installer tout l’environnement de la future application Shinken : binaires, scripts, bibliothèques… On va donc se placer sur le compte root de la machine et exécuter la commande suivante :

# cd /home/shinken/shinken
# python setup.py install

 

VI. Mise en place des utilitaires et des droits

A ce stade de la configuration, on peut installer le package shinken, contenant, comme je l’ai mentionné précédemment, uniquement un outil capable d’administrer et d’installer les différents modules, permettant d’étendre les capacités de Shinken.

# yum install –y shinken

Avant d’initialiser l’environnement de l’application, il est conseillé de modifier les droits des répertoires suivants afin qu’ils appartiennent au compte shinken, ainsi qu’à son groupe :

- répertoire /var/lib/shinken
- répertoire /var/log/shinken
- répertoire /var/run/shinken

Il faut donc exécuter les commandes suivantes, en étant connecté sous root :

# chown –R shinken:shinken /var/lib/shinken
# chown –R shinken:shinken /var/log/shinken
# chown –R shinken:shinken /var/run/shinken

Ensuite, il ne faut surtout pas oublier d’activer les différents service Shinken se trouvant dans le répertoire d’initialisation /etc/init.d :

# systemctl enable shinken
# systemctl enable shinken-arbiter
# systemctl enable shinken-broker
# systemctl enable shinken-poller
# systemctl enable shinken-reactionner
# systemctl enable shinken-receiver
# systemctl enable shinken-scheduler

 

VII. Initialisation de Shinken

Afin de générer le fichier de configuration et d’environnement de l’application, il faut maintenant initialiser Shinken. On va donc exécuter la commande ci-dessous, en se connectant sous le compte shinken :

# su – shinken
$ shinken --init

Cette commande va permettre de créer le fichier .ini dans le répertoire d’accueil du compte shinken.

VIII. Installation des modules (plugins)

Maintenant, on devrait pouvoir alors installer nos premiers modules Shinken et permettre alors d’initialiser l’interface graphique par défaut WebUI. Il faut installer les modules suivants :

- webui ou webui2
- auth-cfg-password

On va donc commencer par l’installation du premier :

$ shinken install webui

Ou pour le module webui2 :

$ shinken install webui2

On doit alors modifier le fichier broker-master.cfg se trouvant dans le répertoire /etc/shinken afin d’y ajouter au niveau de la ligne modules le nom de celui que l’on vient d’installer :

...
modules webui

(ou webui2)

De même, on installe le second module de la même façon :

$ shinken install auth-cfg-password

Mais, il faut, cette fois-ci modifier le fichier /etc/shinken/modules/webui.cfg (ou webui2.cfg) pour lui préciser que l’on va utiliser le module auth-cfg-password comme moyen d’authentification. Ce dernier permet de faire correspondre en guise de mot de passe du compte d’administration Shinken : admin, celui qui est précisé dans le fichier admin.cfg du répertoire /etc/shinken/contacts.

REMARQUE : les autres moyens d’authentification existant permettent, si on le souhaite, d’utiliser un fichier .htpasswd (comme sur les applications web), ou encore de se connecter à un annuaire LDAP ou Active Directory. Ces méthodes pourront faire l’objet d’autres tutoriels.

Si l’on a installé le module webui2, il faut se souvenir que celui-ci possède des dépendances qu’il faut installer avant de démarrer les services. Ces dépendances sont :

- bottle==0.12.8
- pymongo>=3.0.3
- requests
- arrow
- passlib

Ces fonctions sont des modules python, que l’on peut installer à l’aide de l’utilitaire easy_install. :

# easy_install bottle
# easy_install pymongo
# easy_install requests
# easy_install arrow
# easy_install passlib

 

IX. Démarrage des services

Si l’on a respecter l’ordre des étapes décrite ci-dessus, on devrait alors être en mesure de démarrer les services Shinken :

# systemctl start shinken

REMARQUE : le script /etc/init.sh/shinken permet de piloter les autres scripts. Cela permet de conserver une grande souplesse pour des serveurs où il n’est pas forcément utile de démarrer tous les services, comme des serveurs de secours ou des équilibreurs de charge.

En cas d’erreur au démarrage, Shinken inscrit la totalité du processus de démarrage dans un fichier temporaire, dans /tmp sous l’appellation bad_<service>_shinken.log.

X. Connexion à Shinken

Après toutes ces actions, en guise de vérification, on est en mesure d’ouvrir, depuis n’importe quel navigateur, l’url http://<host>:7767 permettant d’afficher la mire de l’application Shinken (où <host> est le nom de votre serveur Shinken) :

ATTENTION: toutefois, toutes les versions de l'agent shinken ne sont pas forcément compatibles avec l'outil de supervision. Certains en ont fait la triste expérience. En effet, avec cette version shinken 3.0, sur certaines plateformes (j'ai pu le constater sur CentOS7), dès que l'on essaie de se connecter en utilisant le module auth-cfg-password ou même htpasswd, l'authentification échoue avec un message d'erreur mentionnant que le compte ou le mot de passe est invalide. Pour corriger ce problème: une seule solution "downgrader" l'agent shinken.

L'opération de "downgrade" consiste simplement à supprimer le package shinken et à le réinstaller dans une version antérieure. Ainsi, il suffit de télécharger la version 2.4.3 depuis le site http://www.shinken-monitoring.org/download.php. Une fois le fichier déposé sur le serveur, il ne reste plus qu'à exécuter les commande suivantes:

# yum remove shinken
# tar zxvf shinken.2.4.3.tar.gz
# su - shinken

Il faut bien sûr mettre les bons droits de propriété sur le contenu de cette archive, une fois décompressée et on peut alors réinstaller la nouvelle version 2.4.3 de l'agent shinken:

$ python setup.py install

On peut alors se reconnecter sous le compte root afin de vérifier que la version est alors bien celle souhaitée:

# systemctl start shinken
# shinken --version

A partir de là, on peut maintenant se consacrer à l’essentiel de la tâche de supervision : mettre en place son infrastructure et déclarer ses équipements, ses applications, ses PKI...

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

Nombre de posts de cet auteur : 69.Voir tous les posts

21 thoughts on “Installer Shinken 3.0 sur CentOS 7 en 10 étapes

  • pourquoi ne pas mettre en place webui2 qui est beaucoup plus pratique ?

    il faudra penser a faire un second billet expliquant comment on le configure et l’utilisé

    en tout cas merci pour ces billet

    Répondre
  • Pour l’avoir testé, il y a aussi Check_MK qui était pas mal comme interface.

    Ceci dit je trouve que Shinken reste une belle usine à gaz….

    +1 pour un deuxième billet également 🙂

    Répondre
  • petite question concernant les modules, je ne sais pas si quelqu’un pourra y répondre

    On fait un shinken install pour installer un module or je n’ai pas vu de shinken uninstall, alors comment supprimer les modules si on ne sent sert plus ?

    Répondre
    • Bonjour,
      pour répondre à votre question, il n’y a effectivement pas d’option uninstall (cela pourrait d’ailleurs être demandé à Jean Gabes). Si l’on souhaite supprimer un module, il suffit de le supprimer du sous-répertoire /etc/shinken/modules (supprimer ou le déplacer si l’on hésite à deleter:-)). Il faut également le retirer du sous-répertoire /var/lib/shinken/modules.

      Répondre
  • Shinken 3.0 n’est pas sorti et on en est très loin vu comment le projet est déserté sur github

    Répondre
    • Bonjour,
      Afin que tous profite de la réponse : non effectivement Shinken 3.0 n’est pas sorti. Mais, je faisais référence au package d’administration shinken (qui lui est en version 3.0).
      Quant à savoir si Shinken est un projet suivi ou pas, je pense que comme beaucoup d’autres il faut que les entreprises l’adoptent pour dire si l’on se trouve en présence d’un projet suivi ou non.
      Il doit y avoir moyen de faire passer le message à nos dirigeants concernant Shinken.
      Personnellement j’ai l’ai mis en place dans mon service et je suis en train de le mettre en production (après six à huit mois d’études, de réglages…: c’est dire les étapes par lesquelles je suis passé :-))

      Répondre
  • Bonjour,

    Un retour sur l’utilisation de la rétention Downtimes/Comments ? J’ai du installer une version 2.4.3 packagée RHEL et pas moyen d’avoir de la rétention Dt/Ct, via l’installation par pip (2.4.3 aussi) j’ai des erreurs de notificationways… Peu de documentation pour aider. Sur le papier il a l’air bien, mais à l’utilisation et la configuration c’est une horreur…

    Répondre
    • Bonsoir,
      Effectivement sur la documentation ça n’a pas l’air mal. Maintenant, pour savoir ce qui coince, plusieurs pistes:
      – en tout premier lieu (mais j’imagine que vous avez déjà fait) regarder les logs
      – passer le service en mode debug (et regarder les logs): attention, très bavard.
      – faire un test “manuel“ avec une commande en direct et des paramètres forcés
      – en dernier recours, rentrer dans le code Python et voir s’il n’y a pas une erreur quelque part. Mais, sans plus d’informations : architecture, comment les hosts ou les services sont déclarés, quels modules sont ou non activés… je vais avoir du mal à vous donner plus d’informations. De mon côté, je suis toujours sur l’ancienne version de Shinken. Je n’ai pas effectué de migration en 2.4.3.
      L’outil Shinken est bien (tant que cela fonctionne). Mais, je reconnais que les traces, les logs …etc. C’est pénible à rechercher lorsqu’il y a un problème.
      Désolé de ne pouvoir vous aider plus.

      Répondre
    • Bonjour,

      Le package RPM de EPEL/RHEL n’a pas le module de rétention. Pour l’installer le module de rétention il faut utiliser la cli shinken. La documentation décrit surtout le fonctionnement des objets de supervision.

      Essaye de venir sur le chan irc pour des conseils et soit patient ;-).

      Répondre
  • Bonjour,

    Déjà merci pour l’article, après plusieurs essais infructueux sur Debian, j’ai enfin réussi à installer et démarrer shinken sur CentOS.

    Par contre, malgré avoir scrupuleusement suivi les étapes, je ne peut pas me connecter à l’interface web (Invalid user or password).

    Note : pour ma part, j’ai du installer redhat-lsb sinon, j’avais des erreurs au démarrage du service.
    Note 2 : bien penser à ouvrir le port 7767 avec firewall-cmd…

    Répondre
    • Bonsoir,
      En ce qui concerne le package redhat-lsb je suis très surpris car personnellement je ne l’ai pas installé et n’ai pas eu d’erreur. J’ai même refait l’installation pour être certain que je n’avais rien oublié

      Pour ce qui est du port 7767: oui vous avez raison. Je ne le mentionne jamais, mais lorsque l’on sécurise un serveur via le pare-feu local (qu’il s’agisse de firewall-cmd ou de iptables), il faut bien évidemment ouvrir le port TCP/7767 d’accès à l’interface web Shinken.

      Répondre
      • Bonsoir,

        Avez-vous une idée de ce qui m’enpêche d’acceder à l’interface (Invalid user or password)? Je viens d’y passer la journée, j’ai essayé avec webui, webui2, auth-cfg, auth-htpasswd, j’ai fait un update/upgrade, vérifié les fichiers de configuration, etc… Je ne peut toujours pas m’identifier!

        Répondre
        • Bonsoir,
          Avez-vous la possibilité de refaire une vm centOS7 complète (avec l’interface Gnome ) et de suivre le tuto?
          Je sais (pour m’être fait avoir deux trois fois) qu’il y a forcément quelque chose qui s’est mal passé.
          – Il faut faire attention car il y a un certain nombre d’éléments à installer sous root et d’autre à installer sous shinken (donc, il y a changement d’identité et de privilèges).
          – l’autre point, c’est qu’une fois que l’on a installé les modules webui ou webui2 et auth-cfg-password, il faut éventuellement changer le mot de passe du compte admin dans le fichier de contacts.cfg
          – il faut surtout redémarrer les services shinken et ne pas avoir d’erreur: consulter les fichiers dans /var/log/shinken et /tmp.
          Dernier point: essayez d’arrêter le pare-feu car il y a peut-être un ou deux ports filtrés (en plus de 7767).
          Ce sont les points qui me viennent à l’esprit.

          Répondre
        • Bonsoir,

          J’ai réussi à reproduire votre problème:
          -vérifier que vous n’avez pas aucun port nécessaire à shinken déjà occupé: # netstat -taupe|grep LISTEN
          Si c’est le cas, il faut arrêter shinken, killer les processus subsistant (kill -9), nettoyer les logs et redémarrer.

          Le problème que vous devez avoir est que certains processus avaient été démarrés avec des droits root alors qu’il faut qu’ils soient “shinken“. Effectivement, le symptôme alors est que l’on ne peut pas se connecter avec le compte admin et son mot de passe dans ce cas de figure.

          Bonne fin de soirée.

          Répondre
        • Bonsoir,
          Après avoir parcouru l’installation complète de Shinken, il semble qu’un certain nombre de choses aient changées depuis la dernière version.
          Notamment, il semble qu’il soit désormais nécessaire d’installer le plugin mongo-logs lorsqu’on utilise webui2. C’est en tout cas ce qui figure dans l’entête du fichier de module. Je continue de creuser…

          Répondre
        • Bonsoir, D’abord désolé pour n’avoir pas répondu plus tôt. Mais, j’ai été très occupé sur d’autrds projets. Je viens de replonger dans les méandres de Shinken.
          J’ai également reproduit le problème de connexion et d’authentification. En fait, la source de ce problème est lié à la version de l’utilitaire shinken. Si votre version affiche shinken 3.0.0 je vous conseille de downgrader l’utilitaire en récupérant la version 2.4.3 sur le site officiel.
          Ensuite, il suffit de ré-installer shinken. Après cela, vous devriez alors voir la nouvelle version en 2.4.3 et l’authentification avec auth-cfg-password fonctionnera à nouveau.
          Conclusion: ce n’est pas forcément une bonne idée de mettre à niveau shinken avec les toutes dernières versions.

          Répondre
  • I am getting below error when trying to start the service anyone please help.

    [shinken@shinken ~]$ sudo service shinken start
    [sudo] password for shinken:
    Starting scheduler:
    [Х ERROR]
    FAILED: [1513754128] ERROR: [Shinken] Bad or missing config file: /etc/shinken/daemons/schedulerd.ini (full output is in /tmp/bad_start_for_scheduler)

    Starting poller:
    [Х ERROR]
    FAILED: [1513754128] ERROR: [Shinken] Bad or missing config file: /etc/shinken/daemons/pollerd.ini (full output is in /tmp/bad_start_for_poller)

    Starting reactionner:
    [Х ERROR]
    FAILED: shinken.daemon.InvalidPidFile: [Errno 13] Permission denied: ‘/var/run/shinken/reactionnerd.pid’ (full output is in /tmp/bad_start_for_reactionner)

    Starting broker:
    [Х ERROR]
    FAILED: [1513754128] ERROR: [Shinken] Bad or missing config file: /etc/shinken/daemons/brokerd.ini (full output is in /tmp/bad_start_for_broker)

    Starting receiver:
    [Х ERROR]
    FAILED: [1513754129] ERROR: [Shinken] Bad or missing config file: /etc/shinken/daemons/receiverd.ini (full output is in /tmp/bad_start_for_receiver)

    Starting arbiter:
    [Х ERROR]
    FAILED: ***> One or more problems was encountered while processing the config files… (full output is in /tmp/bad_start_for_arbiter)

    Répondre
    • Good evening,
      Two things:
      1°) For some research of your problem you should read the different files in /tmp/bad* or search the cause in the /var/log/shinken/*
      2°) If the problem is not solved you could ask a question in the forum http://forum.shinken-monitoring.org/.

      Without your context I couldn’t solve your problem because the root cause of these messages could be multiple .

      Have a good evening

      Répondre
  • Hello pour info il y a plusieurs fautes dans ce tuto : borker au lieu de broker , llog au lieu de log par exemple 🙂

    Répondre
    • Bonsoir, Effectivement. j’ai corrigé les deux erreurs mentionnées. Il m’arrive quelque fois de taper très vite et même en relisant je ne vois pas toujours les fautes de frappe. Maintenant, l’essentiel c’est que le tutoriel reste clair et concis. Merci pour vos remarques.

      Répondre
  • Bonjour à tous , je travaille sur la supervision réseau et système avec avec le logiciel shinken.
    j’ai un soucis pour configurer l’utilisation de la bande passante du réseau .
    toutes vos aides seront les bienvenues. Merci d’avance

    Répondre

Laisser un commentaire

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

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