Auteur:


Date:
6/11/2012

Catégories:
Nagios
Open-source
Planet-libre
Systeme

Tags:

Installation pas à pas d’un serveur de supervision Shinken

Nous allons aborder l'installation et la configuration basique initiale d'un serveur de supervision basé sur Shinken. Ce billet est le premier d'une série sur le sujet. Dans la suite j'utiliserai une machine virtuelle sous Debian Squeeze 6.0.6 (version minimale) pour illustrer mes dires...

Installation de Shinken

Les commandes sont à saisir à partir du compte root ou en les précédants de la commande 'sudo' si celle-ci est installée.

Attendre quelques minutes...

Lors du premier re-démarrage, je suis tombé sur l'erreur suivante (/tmp/bad_start_for_arbiter):

Pour la résoudre ce problème de droit, j'ai effectué les actions suivantes:

L'installation se fait dans le répertoire /usr/local/shinken. Pour identifier les éventuels problèmes que vous pouvez rencontrer lors de l'installation, vous pouvez consulter le fichier de log /tmp/shinken.install.log.

Configuration initiale de Shinken

Les fichiers de configuration se trouvent dans le répertoire /usr/local/shinken/etc/.

Avant de commencer à jouer avec cette configuration, il est important d'avoir une connaissance générale de l'architecture de Shinken. Je vous conseille donc la lecture de cette page sur le wiki officiel.

La première chose à faire et de sécuriser l'accès à l'interface WebUI installé par défaut. Pour cela, il faut éditer la section module / WebUI du fichier shinken-specific.cfg en ajoutant le module Mongodb et en changeant le mot de passe auth_secret:

Puis en éditant le mot de passe du compte admin (par défaut: admin) dans le fichier contacts.cfg:

Comme vous pouvez le voir c'est également dans cette section que vous pouvez changer l'adresse IP (par défaut en écoute sur toute les adresses IP des interfaces) et le port découte (par défaut TCP/7767) de l'interface WebUI.

On peut ensuite relancer Shinken pour prendre en compte la modification:

Il ne reste plus qu'à acceder à la l'interface Shinken WebUI en saisissant l'URL suivante dans votre navigateur (en remplacant @IP par l'adresse IP de votre serveur): http//@IP:7767/

Lors de mon installation (sur une VM), je ne disposais que de 3 Go de libre sur le montage /var. La configuration par défaut de MongoDB, qui est la base de donnée utilisé par la WebUI pour stocker les informations utilisateurs, à besoin d'un fichier journal de plus de 3 Go. J'avais donc le message suivant au niveau de l'interface:

Et le log suivant dans le fichier /var/log/mongodb/mongodb.log:

Pour forcer MongoDB a être moins gourmand, j'ai changer sa configuration dans le fichier /etc/mongodb.conf:

Puis on relance MongoDB:

A ce stade vous devriez avoir une interface WebUI fonctionnelle mais désespérément vide (mis à part votre serveur de supervision)...

Il est donc temps de passer à la prochaine étape.

Superviser votre système d'information avec Shinken

Selon la taille de votre réseau, la tache qui consiste à entrer les machines à superviser dans la configuration de Shinken peut s'averer pour le moins lourde. Heureusement, Shinken fournit un outil permettant de découvrir automatiquement les machines présente sur votre réseau (j'en avais déjà parlé dans ce billet) et même sur votre serveur de virtualisation VMWare (via vCenter).

Cet outil se base sur:

On commence donc par installer ces deux pré-requis sur notre serveur de supervision:

Si vous avez un serveur VMWare vCenter, vous pouvez vérifier le bon fonctionnement du plugin check_esx3 en le lancant en ligne de commande:

Il faut ensuite donner à Shinken les informations sur les réseaux (et serveurs vCenters) ou le logiciel de découverte doit être lancé. Pour cela, il faut éditer le fichier /usr/local/shinken/etc/resource.cfg (section Discovery):

Il est bien sur possible d'ajouter des réseaux ou de machines à la variable $NMAPTARGETS$ en séparant chaque entrée par un espace.

On peut lancer shinken-discovery qui va effectuer la découverte automatique:

shinken-discovery va générer la configuration des machines découvertes dans le répertoire /usr/local/shinken/etc/objects/discovery/ (configurable dans la commande ci-dessus avec l'option -o).

On relance Shinken pour intégrer les machines ainsi découvertes:

En allant dans l'interface graphique, vous allez sûrement rencontrer des erreurs de check car tous les plugins ne sont pas installés par défaut. Par exemple :

Il faut donc utiliser le script d'installation pour installer les plugins manquant.

Sur ma configuration j'ai ainsi fait:

Il faut procéder ainsi jusqu'à avoir installé tous les plugins manquants nécessaires. Pour avoir une liste exhaustive des plugins dont l'installation est supporté par le script Shinken install, il suffit de saisir la commande suivante:

La découverte automatique est vraiment un plus mais ce n'est pas le Saint Grall. En effet pour configurer finement ce que l'on veut suppervier, il faudra obligatoirement reprendre la configuration à la main en éditant les fichiers se trouvant dans le répertoire /usr/local/shinken/etc/objects/discovery. De plus, la notion de groupe étant plus une problématique fonctionnelle que technique, il vous faudra configurer ces derniers manuellement à partir du fichier /usr/local/shinken/etc/hostgroups.com.

Un exemple de configuration de groupe:

Attention à bien sauvegarder ce répertoire avant de relancer un shinken-discovery, histoire de ne pas perdre vos modifications.

Reste ensuite la phase la plus longue mais également la plus importante de la configuration de Shinken: ne surveiller que les choses importantes pour votre système d'information.

En effet, le mode de découverte automatique n'est pas assez fin pour déterminer par lui même ce qu'il faut superviser. La CPU du PC de la secrétaire monte régulièrement au dessus de 90% d'utilisation ? What else... Par contre si on constate la même consommation CPU sur le serveur Web de votre entreprise, il faut aller y jeter un coup d'oeil...

Le plus simple pour effectuer cette lourde tache est de manipuler la WebUI (voir le chapitre suivant), puis de parcourir l'ensemble des hosts et des services en supprimant ce que l'on juge peu important.

Prise en main de Shinken WebUI

A ce stade, vous devriez avoir un serveur de supervision qui commence à remonter un certain nombres d'informations dans l'interface WebUI.

Je vous encourage ensuite à vous familiariser avec cette nouvelle interface WebUI qui peut être un peu déroutante pour les personnes habituées à manipuler d'autres solutions de supervision. A ce sujet, il est également possible d'utiliser des interfaces alternatives comme Thruk qui se rapproche plus de l'interface native de Nagios.

Thruk, une alternative à Shinken WebUI

Personnellement, je trouve qu'une fois la première impression passée (c'est quoi ces gros icônes ? Ou sont mes hosts !). La modularité apportée par le Dasboard, les filtres et les bookmarks permet d'adapter cette interface à vos besoins. Si les développeurs de Shinken lisent cet article (et je suis sûr qu'ils vont le faire, coucou @naparuba :)), il serait bon près configurer le Dashboard par défaut et quelques filtres bien pensées histoire que les nouveaux utilisateurs ne se trouvent pas devant des pages blanches.

 

On peut également se créer des filtres personnels (par exemple toutes les machines appartenant au groupe "serveur" ou tout les services remontant la charge des machines...) et créer des bookmarks dans la page All de la WebUI.

Et après ?

Nous arrivons au terme de ce premier article sur une configuration pas à pas de Shinken. Au prochain épisode, nous allons nous pencher sur la notion d'impacts/dépendances et de business rules qui sont de grosses valeurs ajoutées de Shinken par rapport à Nagios.

  • http://twitter.com/bastienlaunay ♫ Bastien L. ♫

    Actuellement, j’utilise NRPE sur une config 100% Nagios. Est-il possible de garder les mêmes démons sur mes serveurs clients et de les “utiliser” sur un serveur Shinken?

    • http://www.nicolargo.com nicolargo

      Oui sans problème. Le système de plugins de Shinken est 100% compatible avec celui de Nagios.

      je te conseille même de faire tourner les deux système en parallèle pour effectuer une migration en “douceur”.

      • http://twitter.com/bastienlaunay ♫ Bastien L. ♫

        C’était justement mon idée, d’où ma question de “compatibilité” entre tout ça !
        Un grand merci à toi en tout cas ! :)

        • http://twitter.com/naparuba jean gabès

          Salut,

          en fait Shinken a débuté comme une réimplantation de Nagios, donc de base c’est compatible :)

    • http://www.shinken-monitoring.org David GUENAULT

      Oui il est tout à fait possible d’utiliser nrpe sur vos serveurs. Mais vous n’avez plus besoin du plugin nrpe sur le serveur de supervision car le protocole est géré en natif dans shinken grâce au module nrpebooster. Il suffit simplement de l’activer comme module du démon poller dans le fichier shinken-specific.cfg. Pour le reste les commandes.

  • Pingback: Installation pas à pas d'un serveur de supervision Shinken | formation 2.0 | Scoop.it

  • Pingback: Installation pas à pas d’un serveur de supervision Shinken « Formation 2.0

  • Xavier

    Merci beaucoup pour ce billet :)

    J’ai aussi un serveur NAGIOS en production avec une base de donnée Mysql NDO. Est-ce qu’on peut connecter Shinken à cette base afin de tout récupérer ?

    Bonne continuation!

    • http://www.nicolargo.com nicolargo

      Après avoir fait une sauvegarde de ta base MySQL (on ne sait jamais…), tu peux essayer de configurer le broker NDO pour voir ce que cela donne.

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

      Je te conseille de poser la question sur le forum officiel de Shinken. je suis sur que d’autres personnes ont essayé de le faire.

      http://www.shinken-monitoring.org/forum/index.php

      • Xavier

        Merci pour cette réponse rapide, je vais me pencher sur le forum et la doc ;)

        • http://twitter.com/naparuba jean gabès

          Je te confirme pour le backup de la base. En effet, mais en même temps la bdd ndo n’est que temporaire le temps de lancement des daemons, elle n’a pas de vraie utilité sur le long terme en fait. (non on ne fait pas de reporting à partir de données non agrégées à moins de vouloir tuer son serveur de bdd et se mettre les dba à dos…)

  • Pingback: Installation pas à pas d'un serveur de supervision Shinken - Le blog de NicoLargo | The libre | Scoop.it

  • Pingback: Installation pas à pas d'un serveur de supervision Shinken | GTSUP- L'informatique avancée | Scoop.it

  • eXorus

    Il n’y a rien à installer sur les machines à superviser ?

    Sinon existe il un plugin similaire à checked pour un serveur virtualité avec openvz ?

    Merci d’avance j’ai jamais réussi à créer ma vm de supervision j’espère que cette fois avec ce tutoriel je vais réussir :-D

    • http://twitter.com/naparuba jean gabès

      Il n’y a pas de miracle, il faut bien un moyen d’obtenir des informations des serveurs.

      Soit tu utilises l’agent par défaut sur les machines (snmp sous linux, wmi pour les windows) soit tu mets ton propre agent genre NRPE.

  • Zorg

    Shinken est une bonne initiative et comporte des nouvelles fonctionnalités interessantes. Le travail des auteurs est a saluer d’autant que la solution est gratuite.
    Néanmoins, je ne comprend pas qu’on soit encore obligé d’editer des fichiers de config pour ajouter des hosts ou configurer des groupes. D’autre part, qu’en est-il au niveau des ajouts de services et de commandes ? Ce sont des taches recurrentes qui meritent une belle interface graphique.

    My 2 cents

  • Zorg

    EDIT : J’ai compris que nmap permet d’ajouter des hosts automatiquement, mais dans un contexte d’infogérance la découverte du réseau n’est pas utile

    • http://www.shinken-monitoring.org Gabès Jean

      Salut,

      C’est pour ça qu’on a lancé le projet skonf d’interface de configuration. Toute aide est la bienvenue d’ailleurs :)

  • http://twitter.com/naparuba jean gabès

    Héhé grillé, comment tu savais que j’allais lire :p

    Je vois en tout cas que malgré le script d’installation, ce n’est pas encore launch & play.

    Il restera toujours la partie de découverte et rajout des hôtes, point de miracle, mais la première partie est encore améliorable (surtout le coup du chown :p qui sent le bug à plein nez ).

    Je note aussi la remarque de WebUI qui démarre un peu vide sur le dashboard, on va tenter de régler ça :p

  • SuperPoney

    Pour moi le point le plus rageant en ce qui concerne la supervision c’est la configuration des ports d’écoute.

    à quoi bon utiliser l’outil/interface le plus génialissime sur le serveur de supervision, si on est incapable de récupérer la moindre donnée ?

    Impossible de trouver une solution pour monitorer tout cela depuis un port ouvert (port 80) comme le ferai un banal webservice !
    Quelle solution pour superviser une VM, sur une machine physique, derrière un routeur qui ont tous leur propre firewall ? Dans 90% des cas l’accès au routeur est impossible. A ce jour toutes les solutions de supervision demandent à ouvrir le port XXXX pour pouvoir fonctionner (que se soit en passif ou en actif).

    Tant que ce frein ne sera pas levé, le monde de la supervision restera cantonné à une minorité…

    • Zorg

      Je ne vois pas ou est le problème d’ouvrir quelques ports…Le plus souvent il suffit d’autoriser snmp et icmp. Je ne saisis pas bien ou vous voulez en venir..

      • SuperPoney

        Là ou je veux en venir c’est pourquoi cette obligation de passer par un port lambda alors qu’une solution comme un webservice qui utilisent le port 80 (ouvert dans tous les cas) n’existe pas.

        “Je ne vois pas ou est le problème d’ouvrir quelques ports” justement tout le problème est là.

        Utiliser shinken, Nagios, Centron, Zabbix, etc… quel intérêt si aucune donnée ne peut être récupérée…

        • http://twitter.com/naparuba jean gabès

          Ca dépends si tu parles des agents de supervisions à installer sur tes machines ou de la communication entre tes daemons.

          Pour le second cas, on a besoin de protocoles rapides de communications, ici Pyro pour Shinken. Un XMLPRC ou autre est juste catastrophique pour faire passer le volume d’information entre les daemons.

          Par contre la première problématique est faisable, c’est à dire avoir un daemon “nrpe-like” mais en mode web, c’est à dire une bette appli web qui lance des sous process. C’est très pratique pour les serveurs webqui auront déjà ce qu’il faut, mais tu fais comment sur les serveurs de bases de données qui n’ont pas et n’ont pas à avoir d’apache/nginx installé par contre? Car au final, si tu laisses tout passer sur le 80, il te sers à quoi ton firewall si tu fais tout passer dessus?
          (Modulo le cas où tu ne gères pas l’infra évidement, et où une demande de port 80 est plus facile à passer auprès de son client, mais qui va faire une drôle de tête quand tu vas demander un apache sur ses serveurs Oracle, ou le rajout d’une application tierce au sens de son websphere…)

  • Bertrand

    Pour la partie interface j’ai l’habitude de placer ce genre de service derrière un nginx qui sert de proxy (ça permet par exemple d’avoir une sous-url “/munin”, voire de placer le service en sous-url “/shinken” si c’est bien supporté; ça permet aussi de filtrer et sécuriser des choses entrantes ou sortantes au niveau de nginx).

    Le petit souci avec l’UI de shinken c’est qu’il est impossible d’avoir un nginx qui sert les pages en “https”, car derrière le service web de shinken ne prend pas en compte les en-tête standard (indication du ssl par exemple; pour le “script préfix” et le “Host” je ne sais plus) et du coup tous les liens seront en “http”.

    • http://twitter.com/naparuba jean gabès

      Salut,

      les liens internes à WebUI sont sencés être relatifs, donc pointer vers un /autrepage ce qui ne devrait pas poser trop de soucis ou alors j’ai pas tout compris.

      Par contre l’UI ne gère pas encore un autre root que / et ça c’est problématique pour la proxifier.

      • Bertrand

        Salut,

        en fait avec shinken 1.0 j’avais essayé de l’installer avec https (ssl!) parce que l’UI devait être accessible par internet, et au premier lien/login (je ne sais plus vraiment, j’avoue) ça me renvoyait vers du http “plain”. Adieu SSL :-/

        Si c’est censé marcher sans problème en https, je ne sais pas ce que j’ai bien pu rater?

  • Guillaume

    Salut,

    Bravo et merci pour ton tuto!

    J’ai juste un petit problème avec le plugin check_esx3.pl sous la WebUI qui me donne ce message en sortie:

    CHECK_ESX3.PL CRITICAL – Error: Server version unavailable at ‘https://10.155.252.32:443/sdk/vimServ

    Cependant si je lance les commandes directement sur shinken, tout fonctionne.

    Quelqu’un a-il rencontré le même problème?

    • http://www.schinze.fr/ ScHinZe

      Rajoute cette ligne au début de ton fichier check_esx3.pl

      $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0;

  • tacos

    Salut,

    Merci Nico pour ce tuto !

    Juste une question, sur ton screenshot on voit des graphs or j’ai suivi ce ta procédure et de mon coté la partie pnp4nagios ou graphite ne s’installe pas avec le script … Je voulais juste savoir si c’était normal ou si j’avais zappé un truc ?

    • tacos

      Autant pour moi, ça marche nikel.
      Impatient de lire la suite avec les impacts/dépendances et business rules

  • http://p3ter.fr P3ter

    Hello,

    J’ai pleins de plugins de base qui sont “No such file or directory” dans webUI :
    check_ssh
    check_mem.pl
    check_http
    check_load
    check_swap
    check_disk

    “/usr/local/shinken/install -p” ne permet pas de les installer.

    • http://p3ter.fr P3ter

      Autant pour moi, c’est corrigé avec :
      /usr/local/shinken/install -p nagios-plugins
      /usr/local/shinken/install -p manubulon

  • Pingback: Nono’s Vrac 84 « m0le'o'blog

  • http://frechdesign.blogspot.fr/ Issa

    Hello, j’ai reussi à installer Shrinken :)

    par contre pour l’esx j’avais le message d’erreur suivant :

    CHECK_ESX.PL CRITICAL – Server version unavailable at ‘https://vmw-vc-ip:443/sdk/vimService.wsdl’ at /usr/share/perl/5.14

    j’ai du faire la manip suivante :

    http://roshamboot.org/main/?p=40

    et après ça a fonctionner en ligne de commande !
    bon je vais tester le reste maintenant !!
    thanks pour ce how to !

    • anthony

      Hello !
      Jai suivis ta manip et grace à cela jai pu passer mes check :
      /usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l cpu

      sa me repond correctement mais le probleme cest apres, quand je veux restart mon service pour quils sois synchronisé avec mon webUI. sa me marque :

      [warn] full result is in /tmp/shinken_checkconfig_result … (warning).
      [FAIL] ConfigCheck failed: Configuration is incorrect, sorry, I bail out … failed!
      failed!

      Je ne comprend pas …

  • issa

    Bonjour,

    par contre j’ai un soucis,

    j’ai installer chinken sur un ubuntu server 12.04

    mais je n’est pas de graph sur mon itnerface, et j’ai aussi :popup d’authentification : Nagios Access

    j’ai essayer le login mot de passe de shinken, mais aussi utilisateur du serveur, je ne vois pas laquelle ça peut être ?
    quelqu’un à une idée svp ?

  • Issa

    Ok je pensé avoir la solution ici :

    http://forums.monitoring-fr.org/index.php?topic=5901.0

    Lors de l’installation via le script d’install de shinken, ça rajoute, sur une distrib Debian,
    un fichier pnp4nagios.conf dans le dossier /etc/apache2/conf.d.

    Et ce fichier dispose de directives obligeant une authentification.

    A commenter donc :
    Code: [Sélectionner]
    # AuthName “Nagios Access”
    # AuthType Basic
    # AuthUserFile /usr/local/shinken/etc/htpasswd.users
    # Require valid-user

    mais en fait je n’est plus le message de connexion, mais je nai toujours pas de graph

    • tacos

      De mémoire le mot de passe par défaut c’est nagiosadmin/nagiosadmin

      Sinon t’aurais pu rajouter l’utilisateur de ton choix dans le fichier qui contient les comptes :
      htpasswd /usr/local/shinken/etc/htpasswd.users user1

  • http://frechdesign.blogspot.fr/ Issa

    Hello,
    j’ai redémarrage mon serveur, et du coup la je n’est plus de graph, j’ai le message :
    Oh snap! No graphs available!

    J’ai lancé directement l’interface de php4nagios

    http://X.X.X.X/pnp4nagios/index.php/graph?host=localhost

    et je me retour à ne plus avoir de graph depuis mon redémarrage de serveur.

    comment réactiver les graphs svp ?

  • Pingback: Installation pas à pas d'un serveur de supervision Shinken | Le blog ... | Nagios | Scoop.it

  • Locktif

    Bonjour,

    Tout d’abord je tiens a te remercier pour toute cette aide que tu nous apportes, franchement merci.
    Ca fait plaisir d’etre guidé ainsi lorsque nous ne sommes pas des utilisateur avancé de Linux comme moi.

    Toutefois, j’ai remarqué depuis hier que le script d’installation présente des erreurs. En effet, en début de semaine l’installation se passait correctement mais depuis hier j’ai remarqué que le script rencontre des problèmes et n’installe pas Shinken comme il le faisait auparavant.

    A chaque étape à laquelle parvient (des étapes de vérification) le script il indique en jour qu’il faut d’abord installer Shinken et annule ensuite l’installation. Je le fais pourtant sur la même distribution (centos 6.3) qu’en début de semaine et dans les mêmes conditions (sous machine virtuelle VMware workstation 9). Y’aurait il eu une modification dans le script provoquant ceci ?

    En vous remerciant.

    • Locktif

      Je m’excuse pour les fautes et les mots incohérents dans mes phrases.

      Je parlais de message en rouge non pas en jour…

      • Locktif

        J’ai pu mieux voir l’erreur :

        Error while trying to download EPEL repositories

  • Pingback: Tech Digest 20 02 13 ← 3615alex

  • Issa

    Bonjour,

    je me suis laisser retenter par une installation, j’ai reussi à l’installer mais le probléme c’est que Shinken ne m’affiche que des messages :(Service Check Timed Out)

    une capture d’écran :http://img194.imageshack.us/img194/7686/allproblemsgooglechrome.jpg

    vous en pensez quoi svp ?

    • http://www.schinze.fr/ ScHinZe

      Tu dois tout simplement éditer ton fichier /etc/snmp/snmpd.conf et le modifier pour avoir ceci (je te mets que les lignes importantes)

      # view systemonly included .1.3.6.1.2.1.1 (ligne à commenter)
      # view systemonly included .1.3.6.1.2.1.25.1 (ligne à commenter)
      view systemonly included .1 (ligne à rajouter)
      # Full access from the local host
      #rocommunity public localhost
      # Default access to basic system info
      # rocommunity public default -V systemonly (ligne à commenter)
      rocommunity public (ligne à rajouter)

  • Stanislas

    Bonjour,

    Supert tuto.

    Juste une petite erreur à l’installation des plugins

    /usr/local/shinken/insatll -p check_wmi_plus

    PAR

    /usr/local/shinken/install -p check_wmi_plus

    au niveau du INSTALL. Une petite faute de frappe :)

    • http://blog.nicolargo.com/ Nicolas Hennion

      Thk, je corrige !

  • Pingback: Installation de shinken | GuiGeek.org

  • petitpadawan

    Bonjour,
    Je suis actuellement en formation d’administrateur réseaux et néophyte (j’ai commencé il y a un an).
    Étant en ce moment en stage et ayant pour projet l’installation d’un outil de surveillance je me suis tourné vers Shinken suite à de nombreux avis favorables à son égard.
    Par contre j’ai pas mal galéré avant de débarquer ici avec pas mal de choses et je tire mon chapeau devant la qualité de ce tutoriel.
    Alors, oui, je poste juste pour dire un grand MERCI !!!
    PS : moi aussi j’adore le monde du libre ;-)

  • Pingback: Installation pas à pas d'un serveur de s...