Création d'un nouveau plugin check_graph_snmp_ink.pl

[jigot]

"Projet de monitoring d'un réseau multisite avec oreon/nagios"

Bonjour,

Pour mon stage, je dois monitorer des imprimantes snmp(niveaux encre, compteurs divers et remonté d'erreur).
De plus la plupart des imprimantes sont sur des sites distants, j'envisage plus un solution basé sur NSCA.

Pour le moment je n'ai pas besoin d'utiliser les trap snmp car un check toutes les 2 heures est plus que suffisant pour contrôler des niveaux d'encre ou le nombre de page imprimé.
Le problème se poseras peut être après mais l'important et de savoir si l'imprimante est en état de faire sont travail(pas obliger de savoir quel est le problème précis).

Après avoir testé le plugin check_hpjd qui me remonte l'a même chose que l'affichage lcd de l'imprimante(pour mes tests j'utilise une imprimante OKI Laser Couleur C5300).

J'ai cherché dans la MIB les OIDs qui correspondaient aux niveaux d'encre :
Black : 1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.1
Cyan : 1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.2
Magenta : 1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.3
Yellow : 1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.4

Je me suis mis au perl pour faire un plugin qui doit vérifier les niveaux via SNMP.

L'objectif et de retourner une ligne du style :
"Ink OK - black=79% cyan=85% magenta=85% yellow=84%"

Pour y arrivé je me suis aidé du plugin OREON check_graph_ping.
Mon souci est que je ne comprend pas très bien le fonctionnement de certaines parties :
if ($opt_w =~ /([0-9]+),([0-9]+)%/) {
$rta_warning = $1;
$pl_warning = $2;qu'est ce que récupèrent $rta_warning et $pl_warning?
Ainsi que la partie plugin init, je n'en saisi pas toutes les suptilités.

Quelqu'un pourais me commenter le plugin check_graph_ping en particulier les parties près cités, cela me serait d'une grande aide.

[surcouf]

"Projet de monitoring d'un réseau multisite avec oreon/nagios"

Bonjour,

[...]

L'objectif et de retourner une ligne du style :
"Ink OK - black=79% cyan=85% magenta=85% yellow=84%"

Pour y arrivé je me suis aidé du plugin OREON check_graph_ping.
Mon souci est que je ne comprend pas très bien le fonctionnement de certaines parties :
if ($opt_w =~ /([0-9]+),([0-9]+)%/) {
$rta_warning = $1;
$pl_warning = $2;qu'est ce que récupèrent $rta_warning et $pl_warning?
Ainsi que la partie plugin init, je n'en saisi pas toutes les suptilités.

Quelqu'un pourais me commenter le plugin check_graph_ping en particulier les parties près cités, cela me serait d'une grande aide.

En fait, l'argument des options -w et -c sont composés en deux parties : [rta],[percent lost]
L'objectif de la regex est donc de récupérer les deux valeurs.
Entre crochets, il s'agit d'une classe de caractères (les chiffres de 0 à 9, en l'occurence dans les deux cas). Le caractère + recherche la dite classe au moins fois et plus.
Entre parenthèses, il s'agit d'un groupement qui sera transmis dans les variables $x où x est un nombre entier. La valeur du premier groupe correspondra à la variable $1 et ainsi de suite. Attention toutefois, ces variables sont volatiles. À chaque utilisation d'une telle regex, elles sont automatiquement ré-utilisées.
Le second groupe est délimité juste entre la virgule après le premier groupe et le caractère %.
J'espère que ce sera plus clair.

[jigot]

Merci pour ta réponse.

J'ai avancé, j'ai testé un première version sans la gestion de oreon sur ma machine perso, ca marche nickel.

Je viens de modifier avec des trucs que j'ai repris sur check_graph_ping comme par exemple dans la partie plugin init :
use strict;

use FindBin qw($Bin);
use lib "$Bin";
use oreon;
use vars qw($VERSION %oreon);
use vars qw(%oreon);
BEGIN
{
%oreon=oreon::get_parameters;
}

use lib $oreon{NAGIOS_LIBEXEC} ;

J'ai pas encore pu tester sur le serveur de supervision.
Il y a surment du ménage à faire ou des trucs à écrire différement.

[jigot]

Bon je viens de tester mon plugin sur la plateforme Oreon.

En ligne de commande ca marche très bien avec les options et tout
Il en va de même pour l'utilisation dans oreon.

C'est que du bonheur :)[/code]

[surcouf]

Merci pour ta réponse.

J'ai avancé, j'ai testé un première version sans la gestion de oreon sur ma machine perso, ca marche nickel.

Je viens de modifier avec des trucs que j'ai repris sur check_graph_ping comme par exemple dans la partie plugin init :
use strict;

use FindBin qw($Bin);
use lib "$Bin";
use oreon;
use vars qw($VERSION %oreon);
use vars qw(%oreon);
BEGIN
{
%oreon=oreon::get_parameters;
}

use lib $oreon{NAGIOS_LIBEXEC} ;

J'ai pas encore pu tester sur le serveur de supervision.
Il y a surment du ménage à faire ou des trucs à écrire différement.

Juste une petite remarque: il aurait mieux valu t'appuyer sur un autre plugin car il est dommage d'exécuter les commandes snmpwalk et snmpget alors qu'il existe des modules Perl qui permettent ainsi d'éviter d'utiliser trop de forks. Quand le système est chargé, cela peut vite faire la différence.

[wistof]

Hello,

Comme te le suggeres Surcouf, inspires -toi peut etre du plugin check_graph_dell_temperature.pl

[jigot]

En suivant vos conseils, je me suis remis à l'écriture de se plugin.

Je vais ainsi utiliser le module Net::SNMP de perl en me basant sur check_graph_dell_temperature.pl.

De plus mon objectif étant de fournir un plugin standard (je ne souhaite pas réécrire mon plugin pour chaque imprimante à superviser), j'ai testé avec succès l'utilisation du module XPATH pour rechercher les oid dans un fichier de conf xml.

Je prefère utilister xml qui est plus compréhensible et facile à mettre à jour qu'un fichier texte.

programme perl de test pour le xml :
#!/usr/bin/perl

# utiliser le module
use XML::XPath;
use XML::XPath::XMLParser;

# créer un objet
my $xp = XML::XPath->new(filename => 'printer_oid.xml');
my $oidb;
my $oidc;
my $oidm;
my $oidy;

# accéder aux données XML
foreach my $model ($xp->find('/constructor[@name="oki"]/model[@name="C5300"]')->get_nodelist) {
$oidb = $model->find('black');
$oidc = $model->find('cyan');
$oidm = $model->find('magenta');
$oidy = $model->find('yellow');
}

# afficher le résultat
print "black oid : $oidb\n";
print "cyan oid : $oidc\n";
print "magenta oid : $oidm\n";
print "yellow oid : $oidy\n";
Le fichier xml d'exemple (printer_oid.xml):
<?xml version='1.0'?>
<constructor name='oki'>
<model name='C5300'>
<black>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.1</black>
<cyan>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.2</cyan>
<magenta>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.3</magenta>
<yellow>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.4</yellow>
</model>
</constructor>

L'idée et de passer la marque et le model de l'imprimante en parametre du check d'où l'utilisation de :
find('/constructor[@name="oki"]/model[@name="C5300"]') où les chaines de caractère seront remplacées par des variables.

A noter que je ne suis pas encore très à l'aise dans l'écriture du perl mais ca commence à rentrer ;)

[wistof]

oki, tu aurais aussi pu utiliser le fichier oreon.conf qui contient déjà différent OID utilisé par d'autres plugins. Mais ton bout de code XML n'est pas mal, je le garde dans un coin :D

[jigot]

Le souci de ces oid est que pour ce projet je vais avoir une liste d'oid à utiliser pour chaque model d'imprimante.

Et pour chaque nouveau model à monitorer il n'y a qu'un seul fichier xml à modifier.

De plus ce fichier xml devrais à terme contenir d'autre oid correspondant à divers compteur de nombre de pages imprimés, ...
Afin d'être utilisé par un autre plugin que je doit mettre en place.

Ainsi avec l'utilisation des graphs dans oreon il seras possible de visualiser l'utilisation de l'imprimante en fonction du temps (déceler une utilisation anormalement intensive entre 12h et 13h par exemple).

[wistof]

Et pour chaque nouveau model à monitorer il n'y a qu'un seul fichier xml à modifier.

pareil pour le fichier oreon.conf :D
mais bon, j'insiste pas :roll:

[jigot]

J'ai un peu regardé le fichier oreon.conf (faut pas mourrir idiot).

Je vois pas trop comment l'utiliser à la manière de ce que permet le xml.
C'est a dire, une base de donnée hierrachique très visuelle et compréhensible et facile à étendre et à mettre à jour.

Car si je me retrouve avec une dixaine d'oid par model d'imprimante et qu'il y a une cinquantaine d'imprimantes voir plus ca va pas être la joie pour modifier ou ajouter quelquechose.

Après je fait peut être fausse route. Je ne crois pas avoir un avis très objectif sur la question étant encore qu'un étudiant qui débute sous oreon et en perl.

Mais en tout cas merci pour les conseils.

[jigot]

Petite modif pour ceux qui ne l'auraient pas remarqué, j'ai fait une petite erreur dans mon exemple de testxml.pl, je n'affiche que les oid du dernier model du fichier xml.
Pour avoir la liste des oid par model, il faudrait plutot écrire :
#!/usr/bin/perl

# utiliser le module
use XML::XPath;
use XML::XPath::XMLParser;

# créer un objet
my $xp = XML::XPath->new(filename => 'printer_oid.xml');
my $oidb;
my $oidc;
my $oidm;
my $oidy;

# accéder aux données XML
foreach my $model ($xp->find('/constructor[@name="oki"]/model[@name="C5300"]')->get_nodelist) {
print $model->find('@name')." :\n";
$oidb = $model->find('black');
$oidc = $model->find('cyan');
$oidm = $model->find('magenta');
$oidy = $model->find('yellow');

# afficher le résultat
print "black oid : $oidb\n";
print "cyan oid : $oidc\n";
print "magenta oid : $oidm\n";
print "yellow oid : $oidy\n";
}

[DonKiShoot]

Wistof, tu pourrais nous faire oreon.conf en xml après tout :wink:

[jigot]

C'est ça qui est formidable et que j'aime dans l'informatique (la prog en particulier). A un problème, il y a une multitudes de solution.

Je ne suis pas un spécialiste mais il me semble que ce langage est bien adapté aux fichiers de configuration car très souple et facile à étendre surtout dans le cas d'une utilisation par plusieur plugins

D'une certaine manière ca me rappelle le snmp où chaque fabricant implémente sa partie dans iso.org.dod.internet.private.enterprises.*

Mais dans le cas du fichier de oreon.conf, sa structure dépendrait alors des plugins qui sont installés. Il faudrait faire attention aux conflits entre les plugins utilisant ce fichier unique : ajouter les infos à la main dans le fichier pour chaque plugin ou alors laisser la gestion à oreon ou aux plugins eux même.

Enfin bon, comme d'habitude tout est possible. Reste à savoir si cela repond bien au besoin.

[DonKiShoot]

L'avantage c'est que ca ressemble à une MIB en effet, donc chaque développeur peut y glisser ses bouts de variable sans géner les autres (il se réserve une branche dans l'arbo XML)

[wistof]

Wistof, tu pourrais nous faire oreon.conf en xml après tout :wink:

héhé, j'y pense... mais j'ai encore plein de chose à faire avant, tu veux pas t'y coller :P

[surcouf]

L'avantage c'est que ca ressemble à une MIB en effet, donc chaque développeur peut y glisser ses bouts de variable sans géner les autres (il se réserve une branche dans l'arbo XML)

Justement, au lieu de ré-inventer la roue en XML, il vaudrait sans doute mieux attaquer directement les fichiers MIB en question.
Après tout, il existe tout l'arsenal nécessaire parmi les modules Perl.
D'ailleurs, à ce propos, il en existe un qui se nomme SNMP::Info (http://snmp-info.sourceforge.net/) et qui sert de base à un projet nommé netdisco (http://netdisco.org/).
On peut assez facilement ajouter de nouveaux modules afin de supporter davantage de MIB. L'idée est d'ensuite n'avoir plus qu'à appeler les méthodes nécessaires pour obtenir les informations désirées.

[jigot]

Dans mon idée ca pourait ressembler à un fichier avec des infos propre à oreon et d'autre que chaques plugins installer viens ajouter.

Voici un exemple basique mais c'est qu'une solution :
<?xml version='1.0'?>
<oreon>
<dir name='DIR_NAGIOS'>
<path>/usr/local/nagios/</path>
</dir>
<dir name='DIR_OREON'>
<path>/usr/local/oreon/</path>
</dir>
<dir name='NAGIOS_LIBEXEC'>
<path>/usr/local/nagios/libexec/</path>
</dir>
<dir name='NAGIOS_ETC'>
<path>/usr/local/nagios/etc/</path>
</dir>
<uri name='URI_OREON'>
<url>http://127.0.0.1/oreon</url>
<url>http://192.168.1.12/oreon</uel>
</uri>
<plugin name='check_graph_printer_ink'>
<constructor name='oki'>
<model name='C5300'>
<black>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.1</black>
<cyan>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.2</cyan>
<magenta>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.3</magenta>
<yellow>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.4</yellow>
</model>
</constructor>
</plugin>
<plugin name='check_graph_printer_countpage'>
<constructor name='oki'>
<model name='C5300'>
<TotalPage>1.3.6.1.4.1.2001.1.1.1.1.100.1.1.1.3.1</TotalPage>
</model>
</constructor>
</plugin>
</oreon>

Il n'est peut être pas nécessaire d'en arriver là.
Pour ce qui est de mon plugin, je préfère rester sur mon principe de base avec plusieur plugins et mon fichier xml qui contient les infos utile à leur fonctionnement.

[julio]

Moi j'ai un peu peur que ces plugins deviennent des usines a gaz a devoir parser a chaque fois du XML ou autre... je ne sais pas vous mais bon, le faire a chaque execution n'est a mon avis pas l'idéal.... enfin c du temps cpu de perdu.

[surcouf]

Moi j'ai un peu peur que ces plugins deviennent des usines a gaz a devoir parser a chaque fois du XML ou autre... je ne sais pas vous mais bon, le faire a chaque execution n'est a mon avis pas l'idéal.... enfin c du temps cpu de perdu.

Ce que je trouve dommage, c'est de devoir faire pas mal de modifications pour qu'un plugin soit compatible avec Oreon, du moins, la partie "Graphiques". Je me demande s'il n'est pas possible d'écrire un wrapper qui se charge de tout (et si ça ne serait pas trop consommateur de ressources).

[julio]

ca c sur.... moi perso je n'utlise plus les graphs rrd alors...

[DonKiShoot]

L'avantage c'est que ca ressemble à une MIB en effet, donc chaque développeur peut y glisser ses bouts de variable sans géner les autres (il se réserve une branche dans l'arbo XML)

Justement, au lieu de ré-inventer la roue en XML, il vaudrait sans doute mieux attaquer directement les fichiers MIB en question.
Après tout, il existe tout l'arsenal nécessaire parmi les modules Perl.
D'ailleurs, à ce propos, il en existe un qui se nomme SNMP::Info (http://snmp-info.sourceforge.net/) et qui sert de base à un projet nommé netdisco (http://netdisco.org/).
On peut assez facilement ajouter de nouveaux modules afin de supporter davantage de MIB. L'idée est d'ensuite n'avoir plus qu'à appeler les méthodes nécessaires pour obtenir les informations désirées.

Je n'ai pas tout compris à ta technique mais celle-ci suppose apparement une installation, une configuration correct de net-snmp ainsi que l'incorporation des mib necessaires plus l'installation du module perl d'exploration.

L'avantage avec un fichier de conf c'est qu'on ne parse pas une mib complete car on n'a déja sélectionné certains OID d'avance, cela reste facile à maintenir, il y a juste a installer le module xml mais comme j'ai d'autres softs en perl qui l'utilise ca ne me dérange pas.

[DonKiShoot]

Dans mon idée ca pourait ressembler à un fichier avec des infos propre à oreon et d'autre que chaques plugins installer viens ajouter.

Voici un exemple basique mais c'est qu'une solution :
<?xml version='1.0'?>
<oreon>
<dir name='DIR_NAGIOS'>
<path>/usr/local/nagios/</path>
</dir>
<dir name='DIR_OREON'>
<path>/usr/local/oreon/</path>
</dir>
<dir name='NAGIOS_LIBEXEC'>
<path>/usr/local/nagios/libexec/</path>
</dir>
<dir name='NAGIOS_ETC'>
<path>/usr/local/nagios/etc/</path>
</dir>
<uri name='URI_OREON'>
<url>http://127.0.0.1/oreon</url>
<url>http://192.168.1.12/oreon</uel>
</uri>
<plugin name='check_graph_printer_ink'>
<constructor name='oki'>
<model name='C5300'>
<black>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.1</black>
<cyan>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.2</cyan>
<magenta>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.3</magenta>
<yellow>1.3.6.1.4.1.2001.1.1.1.1.100.3.1.1.3.4</yellow>
</model>
</constructor>
</plugin>
<plugin name='check_graph_printer_countpage'>
<constructor name='oki'>
<model name='C5300'>
<TotalPage>1.3.6.1.4.1.2001.1.1.1.1.100.1.1.1.3.1</TotalPage>
</model>
</constructor>
</plugin>
</oreon>

Il n'est peut être pas nécessaire d'en arriver là.
Pour ce qui est de mon plugin, je préfère rester sur mon principe de base avec plusieur plugins et mon fichier xml qui contient les infos utile à leur fonctionnement.

Je voyais un peu ça comme ça aussi :wink:

[DonKiShoot]

Moi j'ai un peu peur que ces plugins deviennent des usines a gaz a devoir parser a chaque fois du XML ou autre... je ne sais pas vous mais bon, le faire a chaque execution n'est a mon avis pas l'idéal.... enfin c du temps cpu de perdu.

Une autre idée ?

A part coder en dure les OID ce qui suppose une modularité moindre ?

Parser du xml ce n'est ni plus ni moins que lire un fichier de conf.

[gregounet]

Hello tout le monde,

J'arrive sur ce topic à l'improviste et je le trouve plutot interessant.
Tout dabord merci et bravo Jigot,

Ce plugin marche correctement?
Ou doit on placer le fichier xml?
Pour ajouter une autre imprimante il faut juste rajouter l'entré dans le xml?

D'avance merci

Greg

[jigot]

Bonjour,

Pour le moment c'est juste une idée soulevé un peu plus haut dans le post d'avoir le fichier oreon.conf en fichier xml.

Pour ma part, je continu de develloper mon plugin d'interrogation d'imprimante.
Je suis vraiment un débutant en perl et j'avance doucement notament sur l'utilisation du module SNMP. Pour moi ce plugin c'est un peut mon tutoriel pour apprendre tout ca (perl, plugin-oreon, rrd, perl::snmp, perl::xml).

Donc c'est pas encore au point, pour le support de la partie graphique j'y suis pas encore non plus ;)

Pour l'instant j'ai un plugin écrit en perl qui prend en paramettre :
-H : le nom d'hôte
-F : le fichier xml qui contient mes oid
-M : le model de l'imprimante
plus des trucs comme niveau critique, warning ..
Et mon fichier xml qui contient les oid de niveaux d'encre des divers models de chaque marque que je vais monitorer.

Pour info je sais pas si j'en ai parlé, j'utilise XPATH pour trouver les infos dans mon fichier xml.

[gregounet]

Salut,

Pour ma part, ce plugin m'interesse beaucoup.
Si tu cherches quelqu'un pour avancer un peu la dessus, je suis là volontier.
Pour l'instant je vais faire un truc tout con: relever les OID pour checker les niveaux d'encre et allez.. le countpage, soyons fou.
Dans le parc ou je travail, nous avons pas mal d'HP, du xerox, du splash, quelques epson, mais majoritairement de l'HP.
C'est une petite contribution mais en attendant ca reste pratique.

On s'en reparle.

Greg

[surcouf]

L'avantage c'est que ca ressemble à une MIB en effet, donc chaque développeur peut y glisser ses bouts de variable sans géner les autres (il se réserve une branche dans l'arbo XML)

Justement, au lieu de ré-inventer la roue en XML, il vaudrait sans doute mieux attaquer directement les fichiers MIB en question.
Après tout, il existe tout l'arsenal nécessaire parmi les modules Perl.
D'ailleurs, à ce propos, il en existe un qui se nomme SNMP::Info (http://snmp-info.sourceforge.net/) et qui sert de base à un projet nommé netdisco (http://netdisco.org/).
On peut assez facilement ajouter de nouveaux modules afin de supporter davantage de MIB. L'idée est d'ensuite n'avoir plus qu'à appeler les méthodes nécessaires pour obtenir les informations désirées.

Je n'ai pas tout compris à ta technique mais celle-ci suppose apparement une installation, une configuration correct de net-snmp ainsi que l'incorporation des mib necessaires plus l'installation du module perl d'exploration.

Il n'y a pas besoin de net-snmp mais du module Net::SNMP. Ça ne fait jamais qu'un module Perl à installer de plus : SNMP::Info.
Quant aux MIBs, il suffit simplement de les avoir dans le répertoire
« /usr/share/snmp/mibs/ ».

L'avantage avec un fichier de conf c'est qu'on ne parse pas une mib complete car on n'a déja sélectionné certains OID d'avance, cela reste facile à maintenir, il y a juste a installer le module xml mais comme j'ai d'autres softs en perl qui l'utilise ca ne me dérange pas.

De même pour ce module, en somme.
J'ai quand même l'impression que tu as "choisis" de l'XML pour t'amuser un peu avec :wink:
Pourquoi ne pas avoir pris, par exemple, un fichier de type INI ?

[DonKiShoot]

C'est juste que j'ai déja un programme perl qui utilise le XML (ntray), que j'ai passé du temps à le comprendre et que je maitrise un peu le sujet.

J'ai rien contre INI, je ne sais même pas ce que c'est.

Je ne suis pas développeur à la base mais adm réseau et j'essai juste de faire en sorte que l'on arrive à une certaine cohérence avec tout ces plugins pour avoir quelquechose d'omogène dans Oréon et enfin attaquer la partie graphique de façon éfficace pour pouvoir me passer de cacti.

Même si je donne du temps à la communauté, je vais dans le sens qui peut soulager mon travail quotidien comme bcp j'imagine :wink:

[surcouf]

C'est juste que j'ai déja un programme perl qui utilise le XML (ntray), que j'ai passé du temps à le comprendre et que je maitrise un peu le sujet.

J'ai rien contre INI, je ne sais même pas ce que c'est.

Je ne suis pas développeur à la base mais adm réseau et j'essai juste de faire en sorte que l'on arrive à une certaine cohérence avec tout ces plugins pour avoir quelquechose d'omogène dans Oréon et enfin attaquer la partie graphique de façon éfficace pour pouvoir me passer de cacti.

Ce qui fait la grande force de Cacti, àmha, c'est la découverte "automatique" des services en fonction du modèle. En effet, lorsque que tu as, par exemple, plusieurs partitions sur un hôte et que tu les récupères via SNMP, tu as juste à faire dépendre cet hôte du bon modèle et tu te vois de suite proposer la liste des partitions de cet hôte. Il ne reste plus qu'à cocher celles pour lesquelles tu souhaites avoir un graphique !

[jigot]

:!: Recentrons nous sur le sujet

Bon, j'ai pas mal trafiqué dans tout les sens pour faire mon plugin.

J'ai pense avoir finallement trouvé la bonne piste.

Tout d'abord il se trouve que pour interroger les imprimante en SNMP, la PRINTER-MIB semble assez bien implémenté sur les models d'imprimante que j'ai sous la main.
Donc on oubli l'idée de rechercher les oids des niveaux d'encre pour chaque model. ouf!
Ainsi plus besoin de se trimbaler un fichier avec les valeurs des oids en questions.

Pour Réaliser mon plugin je vais m'inspirer des deux plugin déjà existant qui sont :
-check_snmp_printer.pl (pour le check des différent oids standard RFC1759)
-check_graph_snmp_value.pl (partie graph bien entendu)

Une question me vien à l'esprit par rapport à la partie rrd.
#Création de la base rrd
if ($opt_g) {
if (! -e $rrd) {
create_rrd($rrd,1,$start,300,"U","U","GAUGE");
}
}
#Mise à jour de la basse rrd
if ($opt_g) {
$start=time;
update_rrd($rrd,$start,$return_result);
}
Comment fait ton pour avoir plusieurs valeurs sur un même graph.
Ici je vais checker : noir, cyan, magenta et yellow.

[DonKiShoot]

Il faut créer et stocker autant de DS(data source) que tu souhaites mais oreon ne sait pas encore grapher plusieurs data source, peut-être dans l'évolution à venir :wink:

"1" dans create est une data source. J'avais changé le nom dans le mini howto check_graph car "1" ca veut rien dire du tout.

J'imagine que pour updater il suffit d'ajouter à la suite :
update_rrd($rrd,$start,$return_result_cyan,$return _result_magenta, ...);
Pour créer, ca ne doit pas être trés compliqué.

[jigot]

Oui bon pour le moment je vais me contenter de bien le plugin sans la partie graph.
Je verrais ça après.
Car c'est pas interrésant si je peut pas les avoir sur le même graph.

[wistof]

effectivement, tu peux créer plusieurs DS dans le rrd, soit en dur, avec le nb de DS dans la fonction create_rrd, puis les valeurs à la suite

#Création de la base rrd
if ($opt_g) {
if (! -e $rrd) {
create_rrd($rrd,3,$start,300,"U","U","GAUGE");
}
}
#Mise à jour de la basse rrd
if ($opt_g) {
$start=time;
update_rrd($rrd,$start,$return_result_cyan,$return _result_magenta, $return_result_jaune);
}

sinon, avec avec un tableau, comme ça c'est dynamique, genre tu peux géré avec le meme code une imprimante couleur (4 couleurs) ou monochrome...
#Création de la base rrd
if ($opt_g) {
if (! -e $rrd) {
create_rrd($rrd,$#tableau,$start,300,"U","U","GAUGE");
}
}
#Mise à jour de la basse rrd
if ($opt_g) {
$start=time;
update_rrd($rrd,$start,@tableau);
}

pour le moment, pas plus de 2 DS sont graphés en 1.2.3... pour la 1.3, ça devrait le faire, chais plus...

[jigot]

Woah! c'est super joli! lol désolé la journée à été pleine de rebondissement.

Effectivement dans mon idée, je pensais récupérer les valeur de façon dynamique sans prévoir à l'avance le nombre de valeur (monochrome ou couleur).

L'idée c'est après d'afficher un truc du style "Changez le toner cyan : ref_du_toner" mais faut biensur que les champs soit renseignés.

[jigot]

Désolé wistof, j'ai pas encore incorporé ton exemple de multiple rrd.

Je me suis appliqué à refaire la partie de base snmp
Je joint le fichier check_snmp_ink.pl (très commenté à ma sauce ;)).

Marche nickel en ligne de commande (utilisateur www-data ou nagios) mais comme d'hab. ça déconne dans oreon (Return code of 126 is out of bounds - plugin may be missing).

J'attend votre avis.

[wistof]

tu n'aurais pas une imprimante snmp à me preter aussi ?

[jigot]

:lol: Désolé elle sont pas à moi, et sur les 3 que j'utilise y'en a une de prêt ;)

Y'a :
- OKI C5300 (laser couleur, marche nickel)
- EPSON AcuLASER 2600 (laser couleur, marche nickel, c'est celle de prêt)
- MINOLTA Magicolor 2200 DL (laser couleur, printerMIB non implémenté, un fosile de 20tonnes)

J'ai donc un retour pour seulement 2 de mes 3 imprimantes.

[jigot]

C'est lourd j'ai toujours ce soucis de plugin qui ne veut pas fonctionner dans l'interface oreon.
Il répond : (Return code of 126 is out of bounds - plugin may be missing)
Pourtant j'ai bien les droits qu'il faut et il me semble bien configuré.

Sa mèrelipopète ça commence à me lourder!

[proxyo]

moi en ligne de commande ton plugin me renvoie


./check_snmp_ink.pl -H 192.168.0.130 -C public -v 1
Ink level CRITICAL - cyan=100% magenta=100% yellow=100% black=10%


et dans l'interface d'oreon


Imprimante Check_Cartouche OK 28/04/2006 09:53:15 2 m, 20 s 1/3 (No output returned from plugin)



bizarre...

(j'ai modifié l'entete de ton plugin que ne renvoyé pas au bon endroit pour perl...)
j'ai oreon 1.2.3 RC4
et j'ai réatribié les droit à l'user nagios du groupe nagios
et un chmod 755 sur ton script


PS: Imprimante DELL 3000 CN

[wistof]

hello

essait avec

use FindBin;
use lib "$FindBin::Bin";
use lib "/usr/local/nagios/libexec";

au lieu de
use lib "/usr/local/nagios/libexec/";

[jigot]

Salut j'étais en intervention ce vendredi donc un petit post avant le week-end ;)

Merci d'avoir un peu regardé mon plugin.

Alorss pour le tst en ligne de commande :
check_snmp_ink.pl -H 192.168.0.130 -C public -v 1
Ink level CRITICAL - cyan=100% magenta=100% yellow=100% black=10%
ça me semble conforme à ce que ca doit resortir, si biensur t'es toners(ou cartouches) sont pour toute sauf une à 100%?
Pour le critical c'est du au 10% (warning en dessous de 40% et critical en dessous de 20% par défaut).

Pour l'utilisation dans l'interface graphique je rencontre aussi des problèe soit de (No outpu!) ou de (Return code of 126 is out of bounds - plugin may be missing).

Pas de résolution de ce problème en suivant tes indication wistof.
Mais ça doit venir de par là effectivement. Il semblerais que oreon /nagios plutôt ne trouve pas le plugin ou un trucs qu'il a besoins.
Désolé, je suis encore débutant en perl. Mais ça me plait bien.
Donc ça semble être la piste à suivre dès Lundi :)

Hier, j'ai ajouter la partie pour faire les graph rrd j'ai pas encore pu voir se que sa donner mais en ligne de commande ca marche toujours.

Enfin voilà, bon week-end et encore merci.

[wistof]

Hello,

quand j'ai
#!/usr/local/bin/perl -w
j'ai :
(Return code of 126 is out of bounds - plugin may be missing)

quand j'ai
#! /usr/bin/perl -w
j'ai :
CRITICAL: Requested table is empty or does not exist for .1.3.6.1.2.1.43.12.1.1.4

[jigot]

Il me semble que la deuxième solution resseble à ce que ca donne si tu interroge un agent snmp qui implemente pas la printerMIB.

Sur mes trois imprimantes, y'en a une qui me retourne un truc comme ça.
A vérifier mais ça me semble mieux que le (Return code of 126 is out of bounds - plugin may be missing). ;)

Thx wistof

[wistof]

Il me semble que la deuxième solution resseble à ce que ca donne si tu interroge un agent snmp qui implemente pas la printerMIB
normal, je n'ai pas d'imprimante :D

[jigot]

Après une petite modification :#! /usr/bin/perl -w
...
use FindBin;
use lib "$FindBin::Bin";
use lib "/usr/local/nagios/libexec";
J'ai enfin autre chose dans l'interface oreon pour deux imprimante différente j'ai ce résultat :ink level UNKNOWN 02/05/2006 09:01:25 5 m, 14 s 3/3
unable to update '/usr/local/oreon/rrd/1.rrd' : expected 1 data source readings (got 4) from 1146553098:95:71:84:86:...
Il me semble pourtant avoir bien configuré mon check :Command "check_graph_snmp_inklvl"
Type de Commande Check
Nom de la commande check_graph_snmp_inklvl
Ligne de commande
$USER1$/check_graph_snmp_ink.pl -H $HOSTADDRESS$ -g -S $ARG1$
Je ne connai pas vraiment les retours de rrdtool mais il sagit peut être d'un problème avec les multiples source à grapher?

De plus si je n'utilise pas les options -g -S $ARG1$ j'ai un retour correct dans l'interface.
Ca semble bien confirmer la maladroitesse de mon codage de la partie rrd ;)

[jigot]

Bon ca marche mais faut encore améliorer.

C'est bon, j'ai mon retour dans la partie surveillance avec la gestion des warning, critical et tout.
La partie graphique me sort des super graph (original non?).
http://jigot3.free.fr/oreon/graph_image.gif

Par contre, pour la gestion des graph, quelque problèmes : Le -S $ARG1$ ne donne rien, un message d'erreur. j'ai bidouillé en mettant quelque chose à la place de $ARG1$ puis en adaptant après avoir regardé ce qu'il voulait ouvrir dans la partie graphique
A mon avis c'est dans mon plugin, la partie d'import qui gère mal ca ou la récup du paramettre -S.
Ma gestion des multisource est un peu empirique (jetez un coup d'oeil dans e code ;)).
Au final je sais pas si ca gère une imprimante monochrome.
Dernier détail, l'ordre de sortie des valeurs (black, cyan , yellow, ...) est toujours la même pour chaque imprimante et dépend de l'implémentation de la PRINTER-MIB. Donc pour les graphyque faut se reporter à l'affichage dans la partie surveillance pour identifier les sources de donnée.
Bon au final j'ai un plugin qui fonctionne (il boite un peu).

PS : Je suis désolé pour les perlistes assidus mais je ne suis pas un pro en prog ;)

[wistof]

c'est cool tout ça.

remplace update_rrd($rrd,$start,$rrdtab[0],$rrdtab[1],$rrdtab[2],$rrdtab[3]);

par
update_rrd($rrd,$start,@rrdtab);

[jigot]

Oui c'est ce que je faisait au début mais dans le doute j'ai fait comme ca.
Je vais changer mais bon je suis déjà content que ca marche.

[karamazof]

désoler d'etre le mouton noir mais j'arrive même pas à compiler :

./check_graph_snmp_ink.pl

Undefined subroutine &main::get_parameters called t ./check_graph_snmp_ink.pl l ine 18.

me manque t'il qqc ???

[wistof]

hummm... en Oreon 1.2, tu n'as pas d'Oreon.pm donc pas de fonction get_parameters

[proxyo]

ca ne mache tjs pas chez moi ca me renvoie tjs no output... et en cli ca marche... :-/

[karamazof]

hummm... en Oreon 1.2, tu n'as pas d'Oreon.pm donc pas de fonction get_parameters

Merci wistof, désoler javais pas vu la version.
(ya moyen de changer de version simplement sans foutre en l'air ma conf de oreon ?)

[misterfab]

Bonjour,

Je viens découvrir ce topic et il est fort interessant.
Il m'a bien aidé ^^
Merci à toi jigot :)

J'utilise depuis ce matin ton plugin pour la supervision de mes imprimantes.
En ligne de commande, j'ai bien le pourcentage des toners de mes imprimantes.
Mais dans l'interface Nagios, il me mets bien le status "OK" mais dans la ligne "status information", j'ai : "(No Output)".

Est-ce normal ?

Merci d'avance.

Cordialement.

[misterfab]

En le modifiant j'ai supprimé un signe "=" donc c'était normal que ca merdé maintenant il est opérationnel.

Encore merci jigot