Installation de Shinken 2.0 sur Debian Wheezy

Jusque ici, j’avais toujours utilisé le célèbre couple Nagios / Centreon pour ma supervision. Seulement aujourd’hui les deux projets ne s’entendent plus trop. Les dév de Nagios ne se donnent plus la peine de rendre leur outil compatible avec la surcouche historique Centreon depuis la version 4. Et à l’inverse, l’équipe de Centreon ne cherche plus à ce greffer à Nagios depuis la version stable de leur moteur nommé Centreon Engine. J’ai bien essayé de donner sa chance à ce dernier. Mais après quelques heures dépensées sur des forums Tibétain à la recherche d’une correction pour une erreur SQL, j’ai décidé de repartir de zéro et de me trouver un nouvel outil de supervision.

Installation de Shinken

Shinken à besoin d’un utilisateur pour fonctionner.

On passe à l’installation des dépendances python nécessaire à l’installation

L’installation de Shinken s’effectue via pip

Cette installation nous donne l’arborescence suivante

  • /etc/shinken : toute la configuration du programme
  • /usr/bin/shinken-* : les scripts de lancement des daemons
  • /var/lib/shinken : les modules shinken et les plugins de supervision (on y reviendra)
  • /var/log/shinken : secret défense

On lance l’outils avec son script init

Par défaut, Shinken ne se supervise que lui même. Plus encore cette supervision est très légère. Si vous jetez un oeil du coté de la configuration du host sous /etc/shinken/hosts/localhost.cfg, vous pouvez voir que ce dernier utilise un « template » nommé « generic-host » qui se contente de vérifier que l’hôte est up.

Nous on va y ajouter quelques vérification de base en plus sur notre hôte. Pour cela on va se servir d’un pack spécialisé. Les packs sont des boites à scripts pour superviser tel ou tel périphérique et sont disponible sur cette page.

On passe sous l’utilisateur Shinken pour effectuer l’installation du pack

La CLI de Shinken à besoin d’être initialisée afin de générer le fichier ini contenant les chemins vers les différents répertoires de configuration de l’outil.

A présent on peut chercher notre pack Linux

Ce qui donne le résultat suivant

On va choisir le pack linux-ssh qui est un mode agent. Le script ouvre une connexion ssh pour exécuter une commande sur le serveur distant et récupérer l’information. Il faut savoir que ce mode n’est pas le plus recommandé car il consomme plus de ressource qu’une requête SNMP classique.

Le pack s’installe avec tous ses plugins dans le dossier /var/lib/shinken/libexec/.

Ces plugins ont besoin d’une librairie nommée python-paramiko. On repasse en root pour effectuer cette installation.

Ces plugins lance une connexion ssh sur le serveur distant, en l’occurrence le serveur local dans notre cas. On va donc générer une paire de clé ssh et donner la clé publique à l’utilisateur shinken.

Ne pas saisir de passphrase sinon le script attendrait une intervention humaine pour saisir cette dernière à chaque exécution.

Déploiement de la clé publique

On va tester un plugin pour voir que tout fonctionne parfaitement

Ce qui doit donner

On va donc ajouter le tag linux-ssh à la définition de notre hôte. Pour cela on édite /etc/shinken/hosts/localhost.cfg

Pour plus de détail sur la configuration d’un hôte je vous renvois vers la documentation officiel.

On relance shinken pour prendre en compte

Les alertes sont consultable dans le fichier de log

Bon, une console c’est pas top pour afficher les statuts de nos machines. On va installer l’interface web de Shinken pour rendre cela plus agréable.

Installation de l’interface web

L’interface web est un module du daemon broker qui va lire, interpréter  et afficher les résultats obtenus dans les fichiers de logs.

L’installation s’effectue depuis le prompt de l’utilisateur shinken

La configuration se trouve dans le fichier /etc/shinken/modules/webui.cfg

Il faut ajouter ce module au broker principal dans le fichier /etc/shinken/brokers/broker-master.cfg

On relance shinken

Et on se connecte à la page web via son navigateur à l’adresse de la machine sur le port défini dans le fichier de configuration du module webui.

On se log à l’aide des identifiants admin que l’on retrouve dans le fichier de configuration /etc/shinken/contacts/admin.cfg

Et la ….. fail !

fail_login_shinken

C’est normal je vous rassure. L’authentification est gérée par un module. Il faut l’ajouter. Regardons du coté des modules d’autentifications disponible

Se qui donne :

  • cfg-password : authentification simple basée sur le mot de passe enregistré dans la conf du contact
  • htpassword : basé sur un fichier htaccess apache
  • active-directory : authentification basé sur AD ou LDAP

On installe le premier

Il n’y a rien à déclarer dans le fichier de conf du module (/etc/shinken/modules/auth_cfg_password.cfg) mais il faut quand même déclarer ce dernier comme pour les autres dans le module de webui sous /etc/shinken/modules/webui.cfg

Et le restart qui va avec

Cette fois le login passe. Dans la vue « all » vous devriez voir votre hote ainsi que tous les services du pack linux-ssh.

shinken_localhost

Il est normal d’obtenir une erreur de type

Le plugin de récupération des informations CPU se base sur le programme sysstat. Il faut l’installer sur le système.

Si l’on se rend dans la vue « /dashboard » on a un énorme message d’erreur

shinken_dashboard_error

La aussi c’est normal. Le dashboard est spécifique à chaque utilisateur. Le module WebUI à besoin de sauver les préférence de chaque utilisateur dans un fichier à plat ou une base de données. Ici on va utiliser sqlite.

Installation via l’utilisateur shinken

Et on ajoute le module au module Webui sous /etc/shinken/modules/webui.cfg

Le fameux restart

Vous pouvez à présent ajouter des widgets sur la page /dashboard

widget_shinken

Voila c’est terminé pour l’installation. Dans le prochain article je parlerais d’ajout d’hôtes et de services. En attendant il y a toujours la documentation officiel.

 

 

Laisser un commentaire

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