Shinken : Monitoring système et Réseau

Shinken est un logiciel de monitoring système et réseau. Vous allez pouvoir surveiller vos serveurs directement à partir de son interface web et recevoir des alertes quand un service comme apache cesse de fonctionner ou lorsque votre machine consomme une quantité trop importante de mémoire vive.

Je vais détailler l’installation et la configuration de Shinken sur une machine Debian Squeeze.

Pour réaliser ce tutoriel j’ai pri appuie sur 3 sites : 

Le blog de nicolargo
wiki.monitoring-fr.org
www.tcweb.org

 Etape 1 : Installation de Shinken :

On installe curl pour récupérer la dernière version de shinken.

et lsb-release sinon vous aurez une erreur lors de l’installation de shinken

On récupére maintenant la dernière version de  Shinken à l’aide de cette commande :

Une fois l’installation terminée on va modifier le fichier shinken-specific.cfg pour configurer le mot de passe de l’interface web et ajouter le module Mongodb qui vous évitera d’avoir cette erreur au lancement de l’interface web :

warning

host : Par défaut l’interface web écoute sur toutes les interfaces réseaux disponibles (0.0.0.0),  vous pouvez changer l’adresse IP en la remplaçant par l’une de vos interfaces réseaux

auth_secret : A modifier avec votre mot de passe

On va aussi éditer le mot de passe du compte admin (par défaut:admin) dans le fichier contacts.cfg

On relance shinken pour prendre en compte la configuration :

Pour accéder à l’interface web de Shinken il faut utiliser l’url suivante : http://ip_srv_supervision:7767

Etape 2 : Découverte automatique du réseau

Une des forces du logiciel Shinken est sa fonction de découverte automatique du réseau.

Pour se faire il suffit d’installer nmap sur le serveur Shinken

D’éditer le fichier ressource.cfg en ajoutant le réseau que devra scanner nmap

$NMAPTARGETS$= : Ajouter le réseau qui sera scanner par nmap

et de lancer la commande suivante :

Enfin on redémarre shinken pour qu’il prenne en compte l’ajout des nouveaux hosts.

Les fichiers de configuration des hosts découverts automatiquement se trouve dans /usr/local/shinken/etc/objects/discovery/

En vous rendant sur l’interface web vous risquez de rencontrer cette erreur :

pluginnotfound

Si c’est le cas il vous faudra installer les plugins manquant nécessaire au check.

Rien de plus simple rendez-vous dans le dossier /usr/local/shinken/

Vous pouvez obtenir une liste des plugins installables avec cette commande :

Voici une bonne base de plugins à installer par défaut qui vous éviteras les erreurs présentées dans la capture ci-dessus

Etape 3 : Ajout d’un host manuellement

Pour avoir une configuration plus fine que lors d’une découverte automatique des hôtes, nous pouvons rajouter manuellement les hôtes dans Shinken ainsi que les services supervisés ect …

La définition des hosts se fait dans le dossier /usr/local/shinken/etc/hosts/

Pour chaque host que l’on souhaite rajouter il faut créer un fichier .cfg

Nous allons ajouter manuellement l’host test.labo qui est un serveur debian dans Shinken

On crée un nouveau fichier .cfg dans /usr/local/shinken/etc/hosts/

vi /usr/local/shinken/etc/hosts/test.labo.cfg

use : permet d’utiliser des templates d’hosts
contact_groups : permet de définir les groupes de contacts tels définit
host_name : nom à faire apparaitre (pour l’interface web surtout)
address : indispensable pour joindre la machine.
icon_set : l’icon a utiliser pour l’interface web

Dans cet exemple nous supervisons le ping et le ssh de la machine test.labo ayant pour IP 10.0.0.13

On redémarre Shinken pour prendre en compte la configuration

Dans l’interface web de Shinken nous pouvons maintenant voir le serveur que nous venons de rajouter :

test.lab

On peut rajouter la template « linux » qui va superviser le système du serveur en modifiant le fichier .cfg que nous avons créer de cette manière:

Vous trouverez la liste des templates disponiblent dans /usr/local/shinken/etc/packs/

On redémarre Shinken pour prendre en compte la configuration

Voilà ce que nous obtenons dans l’interface web de Shinken

test.lab2

Si vous avez des erreurs vous pouvez passer Shinken en mode debug avec cette commande :

Les logs sont dans /tmp/shinken_checkconfig_result

Etape 4 : Configuration du snmp

Pour que Shinken puisse récupérer des informations sur le système comme l’usage du CPU et de la RAM il faut configurer le snmp sur la machine supervisé.
Je vais configurer snmp sur une machine Debian Squeeze. Attention la configuration peut changer selon la distribution.

Il faut modifier le fichier de configuration suivant pour autoriser snmp à être écouter à distance /etc/snmp/snmpd.conf

Remplacer  192.168.1.10 par l’adresse IP de votre serveur Shinken

On redémare snmpd pour que la configuration soit prise en compte

On peut vérifier que le deamon écoute bien les connexions distantes avec la commande suivante :

Sur votre serveur de supervision vous pouvez tester la bonne remonter des informations grâce à la commande suivante :

Remplacez 10.0.0.13 par l’ip de la machine sur laquelle vous avez configuré le snmp.

Etape 5 : Configuration du Firewall

Si vous disposez d’un firewall il faut ouvrir sur vos serveurs qui seront supervisés, le port 161 et 162 en UDP.

Pour le firewall Iptables :

Si vous souhaitez aller plus loin avec Shinken vous pouvez consulter  mon article sur comment ajouter de nouveaux services sur Shinken  ;-)

30 réflexions au sujet de « Shinken : Monitoring système et Réseau »

  1. Bonjour,

    J’ai suivi votre tuto pour installer shinken. L’installation c’est ok, cependant à la fin l’état est toujours UNKNOWN ou CRITICAL. Lorsque je veux superviser la machine elle même les état son UNKNOWN service check time out. Et lorsque je veux superviser une autre machine je n’ai qu’un seul état (ssh) et son état est CRITICAL connection refused.

    Savez vous d’ou peut venir ce problème ?

    Merci

    1. Salut,

      C’est pour superviser quel OS ? Je pense que tu as un soucis dans configuration du snmp ! Du moins pour les remontées CPU,RAM ect.
      Pour ssh utilises tu le port par défaut (22) ?

      Ophyde

  2. Bonjour,
    Concernant les problème ssh, oui j’utilise le port 22.
    Concernant la config snmp j’ai les 2 identiques sur les 2 machines (debian 7). Mais celle qui pose problème pour les remonté de CPU, RAM… est celle qui héberge shinken, pour l’autre pas de problème hormis ssh

    1. La machine ssh est sur le même réseau que ton serveur Shinken ?
      Concernant ton autre soucis pour les remonté d’information snmp, ton serveur shinken tu l’attaques par son ip privé ou en 127.0.0.1 (localhost) ?
      Fait un :
      snmpwalk -v 2c -c public localhost
      puis
      snmpwalk -v 2c -c public ip_serveur_shinken

      Normalement tu devrais avoir une remontée d’information avec une des deux commandes

  3. Bonjour,
    Désolé de ne répondre que maintenant.
    J’avais mis 127.0.0.1 dans le fichier de conf de l’hote, je test ces commandes des que j’ai 5 minutes.
    merci

    1. Salut,

      Fallait éditer tes messages ça t’aurais éviter de faire plusieurs postes :-).
      Pour le ssh tu aurais pas un parfeu iptables qui tourne sur le serveur que tu essayes de superviser et qui autorise seulement certaine ip à se connecter ?
      C’est quoi l’erreur exacte qui t’ai remonté sur Shinken ?

      Ophyde

  4. j’ai pourtant regardé si je pouvais les modifier mais vu comment ! :/
    Non je n’ai pas de parefeu sur le serveur. L’erreur c’est « connection refused ».
    C’est une maquette sous VMWare mais je pense pas que ça ai de l’influence

    1. Si tu essayes de te connecter en ssh à partir de shinken sur le serveur que tu essayes de superviser ça marche ? Tu as peut être des restrictions au niveau de ta conf ssh :-)

      1. Bonjour,
        Bon en fait sur ce coup j’avais fais le boulet … La seul machine a qui je demandais de superviser le ssh été la seule sur laquelle je ne l avais pas activé … :/

  5. Bonjour,
    merci pour ce tuto qui m’a été fort utile.

    Cependant, j’ai une question. Dans le WebUI, mon serveur Shinken (nommé Hubble) est vu comme « Hublle » et comme « localhost ».

    Avec localhost (en bleu : unknow), j’ai un onglet Linux qui apparait (normal, il est sous Debian 7), et avec Hubble, j’ai pas d’onglet Linux mais un test DB2 en critique, hors, j’ai pas de base de DB2 sur ce serveur.

    Aurais-je loupé un truc ?

    Note : je suis débutant avec la supervision, pour le moment j’en suis à des phase de test pour au final déployer un GLPI + FusionInventory + Shinken.

    Merci :)

      1. Bonjour et merci de la réponse.
        J’avais trop de truc bizarre sur le serveur, du coup j’ai tout réinstallé de 0 …
        Après réinstallation, j’ai bien mon serveur local Shinken qui est vu par son nom avec un template linux, le Dashboard fonctionne et nmap m’a bien trouvé tout mes hosts ! \o/

        Cependant, je n’arrive pas à faire remonter les infos système via snmp, ni de localhost (mon serveur Shinken (Debian 7.5) nommé Hubble), ni d’un autre serveur Linux (basé sur Ubuntu Server 8.04). J’ai suivis ta procédure.

        Sur mon serveur Shinken :
        # netstat -an |grep -i udp
        udp 0 1216 0.0.0.0:37189 0.0.0.0:*
        udp 0 0 0.0.0.0:919 0.0.0.0:*
        udp 0 0 127.0.0.1:973 0.0.0.0:*
        udp 0 0 0.0.0.0:33268 0.0.0.0:*
        udp 0 0 0.0.0.0:55391 0.0.0.0:*
        udp 0 0 0.0.0.0:111 0.0.0.0:*
        udp 0 0 0.0.0.0:161 0.0.0.0:*
        udp6 0 0 :::49475 :::*
        udp6 0 0 :::919 :::*
        udp6 0 0 :::111 :::*
        udp6 0 0 ::1:161 :::*

        # snmpwalk -v 2c -c public 192.168.172.3
        iso.3.6.1.2.1.1.1.0 = STRING: « Linux hubble 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3+deb7u2 i686 »
        iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
        iso.3.6.1.2.1.1.3.0 = Timeticks: (7781448) 21:36:54.48
        iso.3.6.1.2.1.1.4.0 = STRING: « Me  »
        iso.3.6.1.2.1.1.5.0 = STRING: « hubble »
        iso.3.6.1.2.1.1.6.0 = STRING: « Sitting on the Dock of the Bay »
        iso.3.6.1.2.1.1.7.0 = INTEGER: 72
        iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
        iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
        iso.3.6.1.2.1.1.9.1.2.3 = OID: iso.3.6.1.6.3.15.2.1.1
        iso.3.6.1.2.1.1.9.1.2.4 = OID: iso.3.6.1.6.3.1
        iso.3.6.1.2.1.1.9.1.2.5 = OID: iso.3.6.1.2.1.49
        iso.3.6.1.2.1.1.9.1.2.6 = OID: iso.3.6.1.2.1.4
        iso.3.6.1.2.1.1.9.1.2.7 = OID: iso.3.6.1.2.1.50
        iso.3.6.1.2.1.1.9.1.2.8 = OID: iso.3.6.1.6.3.16.2.2.1
        iso.3.6.1.2.1.1.9.1.3.1 = STRING: « The SNMP Management Architecture MIB. »
        iso.3.6.1.2.1.1.9.1.3.2 = STRING: « The MIB for Message Processing and Dispatching. »
        iso.3.6.1.2.1.1.9.1.3.3 = STRING: « The management information definitions for the SNMP User-based Security Model. »
        iso.3.6.1.2.1.1.9.1.3.4 = STRING: « The MIB module for SNMPv2 entities »
        iso.3.6.1.2.1.1.9.1.3.5 = STRING: « The MIB module for managing TCP implementations »
        iso.3.6.1.2.1.1.9.1.3.6 = STRING: « The MIB module for managing IP and ICMP implementations »
        iso.3.6.1.2.1.1.9.1.3.7 = STRING: « The MIB module for managing UDP implementations »
        iso.3.6.1.2.1.1.9.1.3.8 = STRING: « View-based Access Control Model for SNMP. »
        iso.3.6.1.2.1.1.9.1.4.1 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.2 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.3 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.4 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.5 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.6 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.7 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.1.9.1.4.8 = Timeticks: (0) 0:00:00.00
        iso.3.6.1.2.1.25.1.1.0 = Timeticks: (8319520) 23:06:35.20
        iso.3.6.1.2.1.25.1.2.0 = Hex-STRING: 07 DE 06 0D 09 24 16 00 2B 02 00
        iso.3.6.1.2.1.25.1.3.0 = INTEGER: 1536
        iso.3.6.1.2.1.25.1.4.0 = STRING: « BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-686-pae root=UUID=60f6911b-4f35-43a6-b15b-bc678e585a8c ro quiet
         »
        iso.3.6.1.2.1.25.1.5.0 = Gauge32: 2
        iso.3.6.1.2.1.25.1.6.0 = Gauge32: 99
        iso.3.6.1.2.1.25.1.7.0 = INTEGER: 0
        iso.3.6.1.2.1.25.1.7.0 = No more variables left in this MIB View (It is past the end of the MIB tree)

        Et le fichier snmpd.conf :
        # Listen for connections from the local system only
        # agentAddress udp:127.0.0.1:161
        agenAddress udp:0.0.0.0:161
        #rocommunity public default -V systemonly
        rocommunity public 192.168.1.3
        # Listen for connections on all interfaces (both IPv4 *and* IPv6)
        agentAddress udp:161,udp6:[::1]:161

        Merci beaucoup pour l’aide apportée ! :)

        1. Pour un raison que j’ignore, les remonté système se sont faite toutes seule en cours de mâtiné, sans que je modifie un fichier … o.O

          Par contre, j’ai toujours rien pour mon serveur distant sous Ubuntu 8.04 …

  6. Bonjour, merci pour le tuto il est d’une grande aide :)

    j’ai une question au sujet des fichier de configuration, j’ai un autre fichier command.cfg pour un de mes plug in ( router cisco)

    dois-je mettre les define command dans le fichier command.cfg du shinken principal ou je dois le laisser dans ceux du plug in? ( de toute façon dans les deux cas, cela ne fonctionne pas car quand je met les commande dans le cfg de shinken et que je restart, il fail le check)

        1. oui j’ai cette commande pour test le cpu de mon routeur cisco

          qui se trouve dans /usr/local/shinken/etc/packs/network/command.cfg

          define command {
          command_name check_switch_cpu
          command_line $PLUGINSDIR$/check_nwc_health –hostname $HOSTADDRESS$ –timeout $_HOSTSWITCH_TIMEOUT$ –community $_HOSTSNMPCOMMUNITY$ –critical=$_HOSTSWITCH_CPU_LOAD_CRIT$ –warning=$_HOSTSWITCH_CPU_LOAD_WARN$ –mode cpu-load
          }

          dans mon fichier cfg de mon host ( cisco.cfg ) j’ai mis :

          define service{
          service_description Cpu
          use generic-service
          register 0
          host_name ayon
          check_command check_switch_cpu
          }

          apres le restart, rien ne s’affiche et pourtant en shell j’ai bien l’information qui remonte des info cpu … j’avoue je seche extremement ><

            1. biensur,

              le voici:

              define host{
              use router
              host_name cisco
              alias router
              address 10.12.0.250
              }

              # Definition du service de Load Average
              define service{
              use generic-service
              host_name cisco
              service_description Load Average
              check_command check_load!5.0,4.0,3.0!10.0,8.0,6.0
              }

              define service{
              service_description Memory
              use generic-service
              register 0
              host_name cisco
              check_command check_switch_memory!10.12.0.250!60!public!60!80
              }

              define service{
              service_description Cpu
              use generic-service
              register 0
              host_name cisco
              check_command check_switch_cpu
              }

              donc a part mon load average, rien ne s’affiche

                1. wow…

                  ok ca fonctionne maintenant, il sert a quoi exactement ce register ( je suis un nouveau sur linux et encore plus sur le monitoring ^^ )

                  en tout les cas un grand merci a toi ! tu mériterais un boite de praline ! :)

                  1. Visiblement quand la variable register est à 0 shinken n’utilise pas le service et le considère comme une template.
                    Par défaut si tu ne précise pas cette variable elle est à 1.
                    Je ne suis pas contre une boite de praline :D

                    Ophyde

Laisser un commentaire

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