Shinken : Supervision de nouveaux services

Suite à mon article sur l’installation et la configuration de shinken nous allons voir maintenant comme ajouter de nouveaux services pour superviser un serveur linux grâce aux différents plugins disponibles sur shinken.

Les plugins disponibles sont stockés dans le répertoire /usr/local/shinken/libexec/ et portent l’extension *.pl.

Le but ici sera de rajouter la supervision de l’espace disponible sur un disque (/) , la RAM disponible ainsi que l’utilisation de la partition de SWAP.

test.lago2

Tout va se faire grâce au plugin check_snmp_storage.pl.

Etape 1 : Création de la commande de check

Sur votre serveur de supervision linux, allez dans le dossier  /usr/local/shinken/libexec/.

La première commande que nous allons tester nous permet de connaitre l’espace libre disponible sur le disque dur de notre machine.

Remplacer -H 10.0.0.4 par l’ip de l’host que vous souhaitez superviser.

[sh]./check_snmp_storage.pl -H 10.0.0.4 -C public -m / -r -w 80 -c 90[/sh]

-H = IP de la machine à superviser

-C = Communauté snmp

-m = Type de stockage

-w = % avant la mise en « warning » du service

-c = % avant la mise en « critique » du service

Voici le résultat de la commande après l’avoir exécuté dans le shell de mon serveur de supervision

/: 4%used(1154MB/29041MB) (<80%) : OK

La seconde commande va nous donner le % de swap utilisé :

[sh]./check_snmp_storage.pl -H 10.0.0.4 -C public -m Swap -w 50 -c 80[/sh]

Voici le résultat de la commande après l’avoir exécuté dans le shell de mon serveur de supervision

Swap space: 0%used(0MB/968MB) (<50%) : OK

Enfin cette commande va nous donner le % de RAM utilisé par notre serveur :

[sh]./check_snmp_storage.pl -H 10.0.0.4 -C public -m Physical Memory -w 80 -c 90 -f[/sh]

Voici le résultat de la commande après l’avoir exécuté dans le shell de mon serveur de supervision

Physical memory: 56%used(1123MB/2012MB) (<80%) : OK | ‘Physical_memory’=1123MB;1610;1811;0;2012

Maintenant que nous arrivons à remonter les checks dans notre shell il va falloir les intégrer directement dans Shinken :-)

Etape 2 : Intégration des nouveaux services dans Shinken

Il va falloir modifier plusieurs fichiers pour pouvoir intégrer nos nouveaux checks.

On va d’abord modifier le fichier commands.cfg  situé dans le dossier suivant /usr/local/shinken/etc/ pour que Shinken reconnaisse les nouvelles commandes qui lui permettront de réaliser les checks

[sh]vi /usr/local/shinken/etc/commands.cfg[/sh]

Rajouter ceci à la fin du fichier :

[sh]define command {
command_name    check_snmp_ram
command_line    $PLUGINSDIR$/check_snmp_storage.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -m Physical Memory -w 80 -c 90 -f
}

define command {
command_name    check_snmp_disk_usage
command_line    $PLUGINSDIR$/check_snmp_storage.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -m / -r -w 80 -c 90 -f
}

define command {
command_name    check_snmp_swap_usage
command_line    $PLUGINSDIR$/check_snmp_storage.pl -H $HOSTADDRESS$ -C $SNMPCOMMUNITYREAD$ -m Swap -w 40  -c 60 -f

}[/sh]

Nous avons ici adapté les commandes pour y inclure les variables d’environnement utilisé par Shinken.

On va maintenant créer le fichier qui va nous permettre d’ajouter dans la configuration de Shinken l’host que nous souhaitons superviser.

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

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

[sh]vi /usr/local/shinken/etc/hosts/test.labo.cfg[/sh]

[sh]
define host{
use generic-host
host_name test.labo
address 10.0.0.4
icon_set server
}

define service{
service_description Disk Usage
use generic-service
host_name test.labo
check_command check_snmp_disk_usage

}

define service{
service_description Swap Usage
use  generic-service
host_name test.labo
check_command check_snmp_swap_usage

}

define service {
service_description Ram_load
use generic-service
host_name test.labo
check_command check_snmp_ram

}
[/sh]

On vérifie que la configuration de Shinken est bonne

[sh]/etc/init.d/shinken check [/sh]

Il ne nous reste plus qu’à relancer Shinken pour que la configuration soit prise en compte.

[sh]/etc/init.d/shinken restart[/sh]

Voici ce que cela donne dans Shinken :

test.lago

 

Etape 3 : Configuration des notifications par e-mails

Il est possible avec shinken d’être alerté par e-mail lorsqu’un service change d’état.

Pour ce faire nous allons d’abord définir une personne à contacter :

[sh]vi /usr/local/shinken/etc/contacts.cfg[/sh]

[sh]define contact{
use generic-contact
contact_name admin
email email@votre-email.com
pager 0600000000 ; contact phone number
password secret
is_admin 1
}[/sh]

Nos services utilisent la template generic-service que nous avons configuré dans l’étape 2 lors de la définition des services vous pouvez la modifier en allant dans le fichier suivant : /usr/local/shinken/etc/templates.cfg
Pour ma part j’ai légèrement modifié la configuration par défaut.

[sh]
define service{
name generic-service ; Nom de la template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted

# Check part
# By default, there is no check_command here
check_interval 3 ; Check les services toutes les 3 minutes lorsqu’ils sont dans un état normal
retry_interval 1 ; Re-check le service toutes les minutes lorsque le service n’est plus actif
max_check_attempts 2 ; Re-check the service up to 3 times in order to determine its final (hard) state
check_period 24×7 ; Le service est en supervision 24h par jour

# Notification part
notifications_enabled 1 ; Notification des services activés
notification_options w,u,c,r ; Envoie de notification lorsqu’un service tombe en warning, unknown, critical, and recovery events
notification_interval 1440 ; Re-notify about service problems tous les 24h (Valeur en minute)
notification_period 24×7; envoie des notifications 24/24H 7/7
# If the contacts and contact_groups options are not set, it will notify host contacts instead
# contact_groups admins

# Advanced options. Change with care
#event_handler_enabled 1
# event_handler super_event_kill_everyone!DIE
flap_detection_enabled 1 ; Flap detection is enabled
check_freshness 0
freshness_threshold 3600
#stalking_options w,c
obsess_over_service 0
#escalations ToLevel2
process_perf_data 1 ; Process perf data, like for PNP
is_volatile 0 ; for log monitoring. See doc for more info about it

# For the WebUI
icon_set server ; can be database, disk, network_service, server

register 0
}[/sh]

On vérifie que la configuration de Shinken est bonne

[sh]/etc/init.d/shinken check [/sh]

Il ne nous reste plus qu’à relancer Shinken pour que la configuration soit prise en compte.

[sh]/etc/init.d/shinken restart[/sh]

Vous devez maintenant installer et configurer Postfix pour permettre à votre serveur d’envoyer des e-mails sur votre boite de réception vous pouvez suivre ce tutorial pour le faire.

Voilà un exemple de notification que vous recevrez lorsqu’un service changera d’état :
notification_shinken

 

25 réflexions sur « Shinken : Supervision de nouveaux services »

  1. Merci pour ce tuto :) je suis moi aussi en train de monter une supervision basée sur shinken.

    As-tu trouvé le moyen de superviser une machine pfSense avec shinken ? Car le mode « switch » ne fonctionne pas :/

      1. En pratique ça fonctionne, mais je sais que les tools permettent de réaliser un contrôle plus fin des VM, notamment dans le cas des backup avec des outils comme Veeam ou Acronis Backup for VMw, sans parler des pilotes vmxnet & co :)

  2. Salut Ophyde !

    As-tu poussé jusqu’à la création d’un script d’utilisation personnalisé qui remonte les informations de manière formatée pour Shinken ?

    Le but étant d’obtenir un script « libre » dans lequel tu injecte un OID en argument afin de t’en ressortir une valeur pré-formatée pour l’interface de Shinken.

    Évidement, les bases fournies par SNMPD ou Net:SNMP ne sont pas utilisable car non-formatée (et donc non reconnue comme services) pour l’interface.

    Je dispose déjà de la panoplie complète de base pour le pack (templates, commands, services,…) mais il me manque ce script qui actuellement retournent les bonnes informations mais sans le formatage demandé par Shinken…

    merci :)

    1. Salut Burn !

      J’ai pas été aussi loin dans la compréhension de Shinken et de la supervision en général.
      Malheureusement je ne peux pas t’aider mais je crois comprendre ce que tu cherches et ça m’intéresse donc si à l’occasion tu as plus d’info … :-)

      Ophyde

      1. Salut Ophyde !
        Ok, pas de soucis :)

        Donc voila le projet qui est en cours:
        Un script module travaillant en SNMP qui reçoit en argument un OID et une IP et ressort une donnée formatée.
        Il sera prévu (à la base) pour les imprimantes, celle-ci ayant des registres vraiment typiques à la marque/modele (d’où l’argument OID en entrée).
        De la, il te ressortira le total de pages Imprimées (à la base) triés par type (a4 a3 noir couleur…) avec le total du mois en cours et le total précédent directement dans l’interface Shinken.
        Toutes les données seront sauvées dans un fichier afin de reprendre en cas de crash ou arrêt système et, si le temps, sortir des graphs par mois via PNP :)

        Évidement, le script sera commenté au maximum afin de l’adapter suivant les besoins, je n’ai aucuns problèmes avec le fait que quelqu’un repasse dedans ;-)

        Le tout est pour éviter SNMPBooster qui est une usine à gaz et vraiment pas stable sous Shinken 2.0.

        Un simple module SNMP qui s’adapte à presque tout (j’espère) ^^

        Je te tiens au jus ;-)

          1. Dans ce cas, j’vais faire au mieux :)

            N’étant pas vraiment codeur de base…
            mon dada, c’est plus Cisco, la sécurité, la virtu, les serveurs,… ^^
            >> Un bon I.T. quoi :)

  3. Il se concrétise doucement,
    Je teste une 2e version ‘alpha’ ^^

    Il remonte sur une même ligne dans Shinken :
    >> Le nombre d’impressions du mois en cours avec le nom du mois
    >> Le nombre d’impressions du mois dernier
    >> Gère le passage de mois de manière automatique

    Après, il faut définir un service pour les types de papier dans Shinken et lui envoyer le bon OID en fonction de l’imprimante mais toujours avec le même script ;-)

    Pour la sécurité:
    * Vérifie si premier lancement ou pas
    * Détecte si ses fichiers sont sains ou non
    * Gère la sortie sur hôtes injoignable
    * Accès aux fichiers centralisée afin de réduire la possibilité de corruption
    * Normalement, remonte ces codes d’erreurs en lieu des impressions dans Shinken.

    Et il est vachement commenté pour qui voudrait repasser dedans ^^

    TODO (j’aimerais bien en tout cas) :
    * Historique plus poussé pour sortir des graphs PNP par mois
    * Restauration de données automatiques en cas de gros crash

    Capture pour voir ce que ça donne en vrai : http://hpics.li/d6b810a
    L’imprimante n’a que du A4 mais ce n’est qu’une service à créer dans Shinken pour A3, couleur, etc vu que le script attends l’OID perso.
    NB: mois dernier = 8140. c’est parce que le script lors de l’init, n’ayant pas d’historique prends par défaut un mois dernier à 0 donc il obtient la valeur total du registre. Cependant, si on est certain de nombre du mois passé, le script accepte que l’on entre ce chiffre manuellement :)

    Enjoy :)

        1. C’est vraiment quelque chose auquel je n’avais jamais pensé la supervision des imprimantes !
          Vu que tu comptes partager ton script j’en parlerai surement sur mon site si tu le veux bien :-)

            1. Voila, la version 0.7 est disponible.
              Elle ajoute un historique des mois précédents dans un fichier afin de pouvoir récupérer ces données facilement et corrige une erreur lors du changement d’année ;-)

              Une version anglaise est également apparue.

              @Ophyde:
              Dans le cas où tu ferais un article, cela pourrait être un petit plus pour mon TFE :) (sans vouloir t’intimider non plus ^^)

              Désolé, je n’ai pas trouvé où éditer mon dernier message :-/

                1. tu peux me contacter sur l’adresse que je viens de changer dans ce mail (la gmail, pas la hotmail) ;-)

                  Sinon, c’est la même que sur mon profil github.

                  Travail de Fin d’étude,
                  c’est pour la validation de mon bac 3 en sécurité et technologies réseaux :)

                  1. Bonjour,

                    Un truc avec les imprimantes c’est qu’elles peuvent-être éteintes (c’est souvent le cas avec les gros traceurs A0, on ne les allume que quand on en a besoin).

                    Du coup, j’aimerais que si l’imprimante est DOWN ou UNREACHABLE, que les services ne soient pas vérifiés mais que la dernière valeur soit conservée (actuellement le check est lancé et j’ai un WARNING renvoyé pour cause de SNMP qui ne réponds pas).
                    Ce serait bien aussi, dans le cas où il n’y a pas de valeur précédente, d’avoir un UNKNOWN plutôt que WARNING.

                    Mais je n’ai pas encore trouvé comment faire; dans la doc de shinken on décrit comment rendre un service dépendant d’un autre service, mais pas comment le rendre dépendant de l’état de la machine.
                    Si quelqu’un spécialiste de shinken sait comment faire…

                    merci

  4. Bonjour, j ‘ai suivi avec attention le tuto sur l’install de Shinken qui est vraiment bien fait. Mais j’ai plusieurs petits soucis.
    Je cherche a monitorer des ports sur des switchs procurve ce que j arrive a faire avec les templates. Le probleme c ‘est que avec le template « switch » Shinken me supervise tout les ports alors que je n en veux que certain les autres etant down. La finalité de mon projet etant d avoir un shema Nagvis fonctionnel et etant donné que je dois supervisé des gros swtich (4208.3500.2810 ect) la lisibilité pour le moment est quelque peu « bordelique » si quelqu’un peut me sauver ma semaine ! Merci

  5. Salut ! :)
    Petit message pour dire que le script est prêt pour les tests extérieurs (cela fait quelques jours qu’il tourne sans générer d’erreur de mon côté donc ça à l’air d’être stable, il reprends bien aussi si la machine se coupe) :)

    J’ai aussi fais un second script au passage pour les fax kyocera,
    il permet de récupérer autant de derniers documents envoyés que souhaité avec le status, le nom, le nombre de page, le type (fax, mail,…) et des erreurs status Shinken pour les triggers :)

    Tout se trouve labas : https://github.com/Arnaud-Burn

    PS: j’ai aussi rajouter une archive avec les librairies perl dépendantes pour la facilité ^^
    Si vous avez des questions, mon mail est sur la page github :)

  6. Bonjour,
    j’ai suivi votre tuto la première fois sur mon serveur de test en shinken 1.4 et par la suite j’ai fait la migration sur la version 2.0 mais lors de ce passage la premiere fois les notifications par mails ont continué … mais par la suite je suis passer en prod ayant reussi mes différents tests mais à ce jour pas moyen de reussir à bien configurer la notif de mail … pouvez vous m’aider
    Cdlmnt

  7. Bonjour j’ai reinstallé le serveur et cela fonctionne de nouveau … en espérant que cela va tenir quand je vais installé mes modules et effectué ma conf –‘ dans les logs je ne voyais aucun message partir dans le schuderd.log je voyais bien les shinken notifications mais rien d’autre :/

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.