Bonnes Pratiques : comment développer les plugins de supervision Nagios

Comme vous le savez, Centreon fournit des plugins pour certains points de contrôle. Cependant, vous utilisez peut-être des équipements sur votre Système d’informations, non connus de l’équipe Centreon, que vous souhaitez superviser. En cherchant sur Internet, vous pourrez trouver un plugin correspondant à votre besoin mais dans certains cas, votre besoin ne sera pas totalement couvert voire pas du tout. Il vous faudra alors développer votre propre plugin. Pas d’inquiétude ! Cela est tout-à-fait possible et assez simplement, même pour des non-développeurs. L’objectif de cet article est de vous donner les bonnes pratiques du développement de sondes de supervision.

Avant de rentrer dans le vif du sujet, un petit rappel s’impose.
Une sonde peut-être appelé plugin (« greffon » selon l’académie française). Nous préférons utiliser le terme de sonde en lieu et place de greffon car la sonde a sa propre existence et peut être utilisée seule. Dans le reste du document, les termes « sonde » et « plugin » sont utilisés indifféremment.
Un plugin permet de récupérer l’état d’un élément supervisé. Exemple : pourcentage d’utilisation du CPU, occupation de la mémoire, présence d’un processus, statut d’un service, temps de réponse à une requête SQL, etc.
Une sonde est une application (ou un script exécuté) en ligne de commande et peut-être lancée avec ou sans argument. Un plugin peut-être écrit dans différents langages (Bash, Perl, C, Python, …). Le langage doit être supporté sur le serveur sur lequel est exécutée la sonde.

Codes de retour

Une sonde doit renvoyer un code de retour. Ce code interprété correspond au résultat de l’exécution de cette sonde. Le résultat est appelé « statut ». Voici deux tableaux récapitulatifs des codes de retours pour les hôtes et les services :

Hôtes :

Plugin return code Host status
0 UP
1 DOWN
Autre Conserve dernier état connu

Services :

Code de retour de la sonde Statut de l’hôte
0 OK
1 WARNING
2 CRITICAL
3 UNKNOWN
Autre CRITICAL : code de retour inconnu

 

Message de sortie de la sonde

Le message de sortie de la sonde doit faciliter à un utilisateur la compréhension de l’information.
Il y a deux types de sortie pour les plugins :

  • OUTPUT : affiché dans les écrans de supervision temps réel des hôtes et des services, sa taille est limitée à 255 caractères.
  • LONGOUTPUT : affiché dans la page de détails de l’hôte et du service, sa taille est limitée à 8192 caractères.

La sonde peut avoir des données de performances. Celles-ci sont optionnelles. Cependant, si vous souhaitez disposer d’un graphique représentant l’évolution du résultat, il est obligatoire que la sonde génère les données de performance.
Les données de performances sont décrites après le caractère « | »(pipe). Ce caractère est disponible par la combinaison de touches AltGR+6.

Les données de performances doivent-être affichées sous la forme :
‘label’=value[UOM];[warn] ;[crit];[min];[max]

  • UOM : unité de mesure (octets, bits/s, volts, …)
  • warn : seuil WARNING
  • crit : seuil CRITICAL
  • min : valeur minimale du contrôle
  • max : valeur maximale du contrôle

Exemple : GPING OK – rtt min/avg/max/mdev = 0.021/0.541/0.598/0.541 ms|time=0.541344ms pl=0%

Nous obtenons alors deux courbes sur le graphique :

  • « time » ayant pour unité un temps en milliseconde (ms)
  • « pl » ayant pour unité un pourcentage de paquets perdus (%)

Ces données de performance sont appelées « métriques » (ou « metrics » en anglais).

De nouvelles sorties sont possibles pour les plugins si vous utilisez Centreon Broker dans une version supérieure à la version 2.3.
Voici un exemple de sortie :

CPU Usage 98%|c[cpu]=98%;80;95;0;100

Les informations sont :

  • CPU Usage 98 %: Sortie (OUTPUT) du plugin
  • c : Type de DATA SOURCE (http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html)
  • 98 : Valeur %: Unité de mesure
  • 80 : Seuil warning
  • 95 : Seuil critical
  • 0 : Valeur minimale du contrôle
  •  100 : Valeur maximale du contrôle

Comme vous le constaterez, vous pouvez spécifier le type de data source (DS) dans le plugin directement.
Nous vous invitons à consulter le site web de RRDTool pour obtenir des informations détaillées sur les data sources et leur mode de fonctionnement (http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html).

Langage utilisé

Pour cet article nous aborderons les plugins en Perl.
Pourquoi utiliser ce langage pour développer des sondes de supervision ? Voici quelques éléments de réponse :

  • Langage interprété assez simple à apprendre ;
  • Peu de contraintes imposées par le langage qui rebuteraient fortement un administrateur systèmes et réseaux ;
  • Généralement connu des administrateurs systèmes ;
  • Nombreuses bibliothèques disponibles gratuitement sur internet ;
  • Installé sur de nombreux Unix et Linux par défaut ;
  • simplicité de gestion dans le lancement de commandes systèmes et récupération du résultat ;
  • Traitement de chaînes de caractères très avancé ;
  • Performant (relativement au travail demandé) ;
  • Interpréteur Perl embarqué dans Nagios : performances encore optimisées ;
  • Connecteur Perl disponible avec Centreon 2.4 et Centreon-Engine 1.3 : performances encore plus optimisées.

Syntaxe d’un plugin Perl

#!/usr/bin/perl -w
use strict;
# ceci est un commentaire
printf « %s\n », « Hello World »;

La première ligne du script (# !/usr/bin/perl) s’appelle le shebang ou encore hashbang.
L’option -w du shebang et « use strict ; » permettent la vérification des variables et des actions non « propres » afin d’aider le debuggage.

Options du plugin

#!/usr/bin/perl -w
use strict;
# Getopt pour récupérer les paramètres du plugins
use Getopt::Long;
# Utilisation de l’API Nagios
use lib « /usr/lib/nagios/plugins»;
use utils qw($TIMEOUT %ERRORS &print_revision &support);
# Déclaration des variables
my %OPTION = (‘help’ => undef, ‘warning’ => 90, ‘critical’ => 95,
‘host’ => undef) ;
# Récupération des valeurs des différents paramètres
Getopt::Long::Configure(‘bundling’);
GetOptions
(“h” => \$OPTION{‘help’}, “help” => \$OPTION{‘help’},
“H=s” => \$OPTION{‘host’}, “hostname=s” => \$OPTION{‘host’},
“w=s” => \$OPTION{‘warning’}, “warning=s” => \$OPTION{‘warning’},
“c=s” => \$OPTION{‘critical’}, “critical=s” => \$OPTION{‘critical’}) ;
if (defined($OPTION{‘help’})) {
# Afficher l’aide
exit $ERRORS{‘UNKNOWN’};
}

Possibilité d’utiliser les variables suivantes :

$TIMEOUT
&print_revision(“check_machin.pl”, “1.0”);

Pour les codes de retour du plugin, il est préférable d’utiliser :

exit ($ERRORS{‘OK’}) ;
exit ($ERRORS{‘WARNING’}) ;
exit ($ERRORS{‘CRITICAL’}) ;
exit ($ERRORS{‘UNKNOWN’}) ;

Ce qui est plus lisible que exit 0, exit 1, exit 2, etc

Si vous désirez vous connecter à un équipement distant via le protocole SNMP, il est conseillé d’utiliser la librairie Net::SNMP qui est très répandu et souvent utilisé dans de nombreux plugins Nagios. Cette librairie vous évitera de lancer une commande système dans votre plugin ce qui aura pour effet de le rendre moins performant.

Exemple de GET via la librairie perl Net::SNMP :

#!/usr/bin/perl-w
use strict;
use Net::SNMP ;
use lib « /usr/lib/nagios/plugins»;
use utils qw($TIMEOUT %ERRORS &print_revision &support);
my %OPTION = (‘help’ => undef, ‘warning’ => 90, ‘critical’ => 95,
‘host’ => undef, ‘snmpcommunity’ => public, snmpversion => 1);
my ( $session, $error ) = Net::SNMP->session(-hostname => $snmp_host, -community => $snmp_community, -version => $snmp_version);
if ( !defined($session) ) {
print(“UNKNOWN: $error\n”);
exit ($ERRORS{‘UNKNOWN’}) ;
}
my $snmp_oid = “1.3.6.1.2.1.1.5.0”;
# Exemple de get
my $resultOID = $session->get_request(-varbindlist => [$snmp_oid]);
if (!defined($resultOID)) {
printf(“UNKNOWN: %s.\n”, $session->error); $session->close;
exit ($ERRORS{‘UNKNOWN’});
}
my $result = $resultOID->{$snmp_oid};printf(“OID : $snmp_oid, DESC : $result \n”);

Exemple de WALK via la librairie perl Net::SNMP :

#!/usr/bin/perl-w
use strict;
use Net::SNMP ;
use lib « /usr/lib/nagios/plugins»;
use utils qw($TIMEOUT %ERRORS &print_revision &support);
my %OPTION = (‘help’ => undef, ‘warning’ => 90, ‘critical’ => 95,
‘host’ => undef, ‘snmpcommunity’ => public, snmpversion => 1);
my ( $session, $error ) = Net::SNMP->session(-hostname => $snmp_host, -community => $snmp_community, -version => $snmp_version);
if ( !defined($session) ) {
print(“UNKNOWN: $error\n”);
exit ($ERRORS{‘UNKNOWN’}) ;
}
my $snmp_oid = “1.3.6.1.2.1”;
# Exemple de walk

my $resultOID = $session->get_table(-baseoid => [$snmp_oid]);
if (!defined($resultOID)) {
printf(“UNKNOWN: %s.\n”, $session->error); $session->close;
exit ($ERRORS{‘UNKNOWN’});
}
foreach my $key (keys %$resultOID) {
printf(« OID : $key, Desc : $$resultOID{$key}\n) ;
}

Autre exemples, pour vous connecter à une base de données Oracle(r), vous pouvez utiliser la librairie Perl DBD-Oracle au lieu d’utiliser sqlplus en mode silencieux.
A chaque fois que vous désirez développer une sonde vous permettant de vous connecter à distance à un équipement ou serveur par l’intermédiaire d’un protocole quelconque, prenez toujours l’habitude de vérifier sur CPAN (Comprehensive Perl Archive Network) si une librairie existe afin de vous faciliter le travail et aussi d’avoir un plugin performant.

Conseils à suivre concernant les options

1. Utiliser les options standards (-h/–help, -H/–host, -w/–warning, -c/–critical, -C/–community, -p/–port, -u/–user, -P/–password, …)
2. Afficher une aide détaillée lors de l’appel à -h/–help : Printf « -H|–host Host name or IP adress »;
3. Vérifiez que les options sont correctement définies, exemple : If (!defined($opt_H)) {help(); exit $ERRORS{UNKNOWN};}
4. Utiliser l’API Nagios (utils.pm)
5. Utiliser l’API Net::SNMP pour interroger un équipement ou un serveur via le protocole SNMP
6. Éviter de faire appel aux programmes externes :
grep/sed/awk/cut/… sont INTERDITS! Perl peut le faire
snmpget/snmpwalk sont INTERDITS! Perl peut le faire

Développer un plugin n’est pas toujours simple et avant de le mettre en production, il est vivement conseiller de le tester. Pour ce faire, vous pouvez (devriez!) vérifier la syntaxe de votre sonde comme suis :

perl -c masonde.pl

Une fois la syntaxe du plugin testée, vous pourrez le tester en ligne de commande avec l’utilisateur Nagios avant de le mettre en production. Lorsque vous êtes en ligne de commande, prenez soin de lancer les sondes depuis le compte utilisateur « nagios ». Certains plugins écrivent dans des fichiers temporaires si vous les lancez en tant que « root » et une fois en production, ils ne fonctionneront pas car ils seront exécutés avec l’utilisateur « nagios ». Les fichiers temporaires ne pourront pas être modifiés par l’utilisateur « nagios ». De ce fait, votre plugin retournera une erreur car l’utilisateur nagios ne pourra pas écrire dans le fichier tampon.
Il existe aussi des « règles de développement de plugins pour Nagios », une documentation est disponible en cliquant sur le lien suivant : http://nagiosplug.sourceforge.net/developer-guidelines.html

Incoming search terms:

  • unknown code 255
  • unknown code 255 mail
  • codes graphiques en sh
  • configurer une sonde akcp sur nagios
  • recuperer le resultat dun shell nagios
  • script centreon

Une réflexion au sujet de « Bonnes Pratiques : comment développer les plugins de supervision Nagios »

  1. bonjour je suis un etudiant en administration reseau je travail sur la supervision via nagios sur l interface graphique centrion je compte sur votre aide
    merci

Leave a Reply