GuiguiAbloc

Tag: nagios

Surveillance par scénario comportemental avec Grandma

par guiguiabloc le 25 mar, 2010, sous linux, sécurité

Comme tout bon sysadmin, la supervision de vos serveurs et services est pour vous primordiale.

Je ne ferais pas le tour des différentes solutions existantes, la plus réputée étant Nagios.

Nous allons nous focaliser sur la surveillance d’un service bien connu : un site web.

Dans la majorité des cas, les différents éléments que vous scrutez sont les charges du serveur, les différents process Apache, etc,  et bien sur, que le site Web retourne un beau code 200, tout va bien.

Mais si la page d’accueil est « défacée » , ou si un formulaire ne retourne pas la valeur escomptée, ce genre de problème reste transparent.

En lecteur assidu de ce blog, vous avez peut-être mis en place SEC ( http://blog.guiguiabloc.fr/index.php/2009/03/18/interception-des-erreurs-applicatives-dans-nagios-avec-sec-et-prelude-lml ) mais l’idéal serait  de pouvoir simuler les actions d’un utilisateur sur le site web par un scénario défini et de remonter une erreur dans Nagios en cas de comportement anormal.

Ce serait bien hein ?

Alors bien sûr, ce genre de produit existe dans le monde propriétaire (Newtest par exemple) mais en OpenSource, c’était plutôt rare.

Heureusement, mon pote Antoine, le Geek au « garage magique », nous offre une solution efficace : Grandma

Pour reprendre la présentation de l’application :

  • Grandma est une sonde robotisée, elle exécute à intervalles réguliers des scénarii permettant de simuler l’action d’un utilisateur sur une application. Chaque étape du scénario fait l’objet d’une vérification pour valider que la réponse de l’application est satisfaisante.
  • Grandma permet de simuler ces actions sur toute application web, 3270, OpenVMS et Unix (tout ce qui n’est pas client lourd en fait). Elle utilise pour cela les outils GNU : cUrl, c3270, Expect et est écrite en Bash.
  • Grandma prend en charge un calendrier et des profils de scénarii afin de gérer les plages de maintenance et adapter les contrôles aux plages d’activité des applications.
  • Grandma fait office de collecteur/ordonnanceur. Une fois les résultats (scénario terminé avec succès, temps d’exécution) récupérés, l’information est remontée vers Nagios à l’aide du client Nsca.

La classe non ?

Suffit les palabres, on se dérouille les doigts, on ferme tout ce qui pourrait nous déconcentrer (oui, oui, ça aussi…), et on se lance (« pas trop fort », oui je sais, elle est pourrie cette blague… (mais elle est quand même moins lourde que « lot du lac« …))

Je considère déjà que vous avez un Nagios actif et que vous savez configurer des remontées d’alertes par NSCA (sinon, un tour ICI )

Téléchargez les sources de Grandma et décompressez le tout dans /opt

Vous trouverez l’arborescence suivante:

/opt/grandma/arch : répertoire de stockage des archives des scénarios en erreur

/opt/grandma/cfg : répertoire de configuration

/opt/grandma/cfg/grandma.cfg : configuration générale de l’application

/opt/grandma/cfg/Grandma.cfg : configuration spécifique à chaque sonde

/opt/grandma/cfg/send_nsca*.cfg : configuration des envois d’informations vers Nagios

/opt/grandma/checks_available : répertoire de stockage des scénarios

/opt/grandma/checks_enabled : répertoire des scripts activés sur la sonde (lien symbolique vers available)

/opt/grandma/lib : répertoire des scripts communs de l’application

/opt/grandma/web : répertoire des fichiers web (interface d’administration de grandma)

Un « petit » tuto d’installation est disponible ici : http://code.google.com/p/grandma/wiki/HowtoInstallationGrandma

La première chose à faire est de créer un utilisateur spécifique  « grandma » puis de donner les droits sur /opt/grandma.

Ensuite, partie paramétrage :

serveur:# echo "export GRANDMAHOME=/opt/grandma" >> /etc/profile
 
serveur:/opt/grandma/lib# ln -s /opt/grandma/lib/grandma /etc/init.d/grandma
  • Vérifier les différents chemins dans le fichier /opt/grandma/cfg/Grandma.cfg

(par exemple /bin/basename qui sous Debian est /usr/bin/basename).

  • Définition du serveur Nagios : nscaserver= »nagios.guiguiabloc.fr »

Préparons notre premier scénario qui devra vérifier que le texte « Bienvenue sur GuiguiAbloc! » s’affiche sur la page d’accueil du blog.

Un scénario exemple et présent dans /opt/grandma/checks_available.

serveur:/opt/grandma/checks_available$ cat check_site_guiguiabloc
 
#!/bin/bash
#Copyright 2002,2010 - Antoine Theuret
# Affectation des variables et fonction communes
. /etc/profile
. $GRANDMAHOME/cfg/grandma.cfg
 
# Creation des repertoires temporaires et des timestamps
$GRANDMAHOME/lib/creation_rep_travail.sh ; if [ $? -ne 0 ]; then UNKNOWN "KO : Probleme lors de la creation des repertoires temporaires"; fi
 
# Bridage des scenarios en cas de surcharge de la sonde
$GRANDMAHOME/lib/controle_surcharge.sh ; if [ $? -ne 0 ]; then UNKNOWN "KO : La sonde $nomsonde est surchargee, l'execution des scenarios est bridee" ; fi
 
# Controle des plages horaires et jours d'execution
$GRANDMAHOME/lib/verif_heure_exception.sh FTN $1 ; if [ $? -eq 1 ]; then OKOUT "OK : pas de contrôle a faire sur cette periode"; fi
 
# Recuperation des mots de passe
source $GRANDMAHOME/lib/gestion_motdepasse.sh 123456 ; if [ $? -eq 3 ]; then UNKNOWN "KO : Probleme lors de la recuperation des mots de passe"; fi
 
# Test de la page d'accueil
$curl $curl_opts "http://blog.guiguiabloc.fr/" >; $tmpdir/page.html 2>&1
TESTRET ; COUNT "Bienvenue sur GuiguiAbloc!"
if [ "$count" -ne 1 ];then FATAL "KO : Pas de page d'accueil"; fi
 
OK "OK : Scenario Blog Guiguiabloc nominal"
 
serveur:/opt/grandma/checks_enabled$ ln -s ../checks_available/check_site_guiguiabloc check_site_guiguiabloc

Premier test :

serveur:/opt/grandma/checks_enabled$ ./check_site_guiguiabloc
OK : Scenario Blog Guiguiabloc nominal - Scenario execute en 1.236361391 s | ok=1.236361391

Changeons le texte sur la page et retestons :

serveur:/opt/grandma/checks_available$ ./check_site_guiguiabloc
KO : Pas de page d'accueil - Scenario execute en 1.076389951 s - <A href=http://dummy:8080/arch/check_site_guiguiabloc/20100323-155230 target=_blank>ERREUR> | ko=1.076389951

Deuxième test, on vérifie le moteur de recherche ainsi que le résultat obtenu :

# test du moteur de recherche
$curl $curl_opts "http://blog.guiguiabloc.fr/?s=tux+droid" > $tmpdir/page.html 2>&1
TESTRET ; COUNT "GuiguiAbloc search results: tux droid"
if [ "$count" -ne 1 ];then FATAL "KO : Impossible d'effectuer une recherche" ; fi
 
$curl $curl_opts "http://blog.guiguiabloc.fr/?s=tux+droid" > $tmpdir/page.html 2>&1
TESTRET ; COUNT "Les Geeks sont de grands enfants"
if [ "$count" -ne 3 ];then FATAL "KO : Retour résulat recherche incorrect" ; fi
 
serveur:/opt/grandma/checks_available$ ./check_site_guiguiabloc
OK : Scenario Blog Guiguiabloc nominal - Scenario execute en 2.043520474 s | ok=2.043520474

Les possibilités sont presque infinies, la phase la plus longue étant d’écrire les scénarios pour les rendre compatibles avec Curl.

Une fois tout en place, il ne vous reste qu’a lancer le démon Grandma sous root :

serveur:~# /opt/grandma/lib/grandma start
Lancement de grandma : [OK]

Dans Nagios, les traps Nsca  :

Mar 25 14:10:50 nagios: EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;Grandma;check_site_guiguiabloc;2;KO : Pas de page d'accueil - Scenario execute en 0.625854926 s - <A href=http://dummy:8080/arch/check_site_guiguiabloc/20100325-141051 target=_blank>ERREUR< | ko=0.625854926

Et cela vous donne un « zoli » service Nagios supplémentaire :

Il existe également une interface Web, facile à mettre en place, qui vous permettra d’un coup d’oeil d’avoir accès aux résultats des divers scénarios.

Bilan, un excellent outil composé de simples scripts shell qui semble basique,  mais redoutablement efficace pour aller plus loin dans la supervision de vos sites internet.

Amusez vous bien :-)

2 Commentairess :, plus...

Remontée d’alerte par SMS avec les API SFR

par guiguiabloc le 03 déc, 2009, sous architecture, geekerie, linux

Comme tout bon sysadmin qui se respecte, vous surveillez scrupuleusement vos serveurs, vos équipements ou que sais-je encore via des outils de monitoring divers et variés.

Votre infrastructure chérie est tellement scrutée que cela rendrais jalouse n’importe quelle jeune maman devant surveiller son bambin.

D’ailleurs, je me suis toujours demander pourquoi on ne passait pas les bébés sous Nagios…

Cela donnerait des résultats intéressants :

AH AH AH  :D   :D

Bref…

Les remontées d’alertes « critique » doivent pouvoir avertir en temps réel le sysadmin et comme vous le savez, c’est toujours quand on est loin de son écran que la panne intervient.

L’idéal étant de pouvoir ajouter aux diverses méthodes d’alertes (mails, alarme Nagios, etc…) l’envoi d’un SMS sur votre portable.

Si votre opérateur téléphonique est SFR, vous avez la première solution de vous créer une adresse mail en @sfr.fr.

En activant sur www.sfr.fr, rubrique Messagerie, l’alerte SMS, vous recevez un texto a chaque mail reçu sur cette BAL.

Il vous suffit donc de donner un Sujet de mail lié a l’alerte pour voir s’afficher succinctement sur votre téléphone l’alerte en question.

Le concept est intéressant, malheureusement, le SMS arrive assez aléatoirement, entre une dizaine de minutes à… plusieurs heures.

Forcément, côté remontée d’alerte en temps réel, on fait mieux…

La deuxième solution est beaucoup plus fun et plus efficace.

Je vous propose tout simplement d’utiliser les API de SFR et de contacter directement leur Webservice en SOAP, comme on peut le faire avec OVH.

Classe, non ?

Car chose que vous ne savez peut-être pas, mais les opérateurs téléphoniques proposent discrètement des kits des développement (SDK) permettant de communiquer avec leur infrastructure via la plupart du temps un webservice accessible depuis le nain ternet.

C’est le cas chez Orange  sur http://www.orangepartner.com/site/frfr/home/p_home.jsp et également chez SFR.

Client SFR, c’est donc chez eux que je vais utiliser  les API.

L’atelier de développement SFR, appelé RED, est accessible sur http://red.sfr.fr/dev-zone/index.php.

L’inscription est gratuite et vous donne accès aux téléchargements des SDK (Php, JAVA et PUB (Market Place SFR).

Egalement avec la mise a disposition des SDK, vous disposez d’un « compte » lié a une application  (le red101) qui vous crédite d’un nombre de points vous permettant de tester le service et vos développements (100 SMS pour le mois par exemple)

Les API disponibles sont nombreuses et franchement intéressantes (envoi et réception de SMS, de MMS, géolocalisation de portable, gestion d’évenement, utilisation de carnet d’adresses unifié, etc…)

D’ailleurs, certaines applications développées par la communauté mérite le coup d’oeil ;-)

Sachez également que vous avez la possiblité d’acheter des packs de jetons. Exemple pour une vingtaine d’euros vous avec 350 utilisations de l’API SMS ou 267 utilisations de l’API Loc.

Le solde offert est largement suffisant pour couvrir ce que nous voulons faire, une remontée d’alerte critique par SMS sur notre portable.

N’étant pas développeur, j’ai donc choisi forcément le kit PHP, langage qui s’adaptera parfaitement à mon niveau :-)

Les prérequis sur votre serveur sont le module soap et les librairies openssl

Sous Debian :

apt-get install php-soap openssl libssl0.9.8

Tout d’abord, téléchargement du SFR-Red_PHP_SDK_v1.1.

Avec le SDK, vous recevrez également par mail vos certificats SSL a utiliser avec l’API.

Première chose a faire, changer le mot de passe par défaut du certificat (fourni dans le mail) :

openssl rsa -des3 -in guiguiabloc.pem -out guiguiabloc.pem
Enter pass phrase for Guiguiabloc.pem:
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

L’arborescence se présente ainsi (j’ai copié mes certificats dans le répertoire pour des raisons de facilité) :

docs/      config.php    examples/  wsdl/     Guiguiabloc.crt  Guiguiabloc.p12  lib/
config.php   Guiguiabloc.jks  Guiguiabloc.pem

On renseigne le fichier config.php

 

Et c’est tout :-D

A vous maintenant d’écrire le script PHP utilisant la méthode SendSMS par exemple :

alerte-sms_bascule-IpFO.php
sendSMS(new
UserIdentifier("0612345678","PhoneNumber"),"ALERTE Bascule IPFailOver");
?&gt;

On appelle le script : php alerte-sms_bascule-IpFO.php

et hop; magique, un SMS du  6011 :-D :-D

Si vous utilisez heartbeat pour vos bascules d’IP FailOver (suite à la lecture de cet excellent billet ), il vous suffit de rajouter l’appel a ce script dans /etc/ha.d/ressource.d/IPaddrFO.

case $2 in
  start)        /etc/ha.d/ns11111-failoverupdate.py
                php /opt/sfr/alerte-sms_bascule-IpFO.php
                ip_start $1;;
  stop)         ip_stop $1;;
  status)       ip_status $1;;
  monitor)      ip_monitor $1;;
  *)            usage
                exit 1
                ;;
esac

Côté Nagios, je suppose que vous gérez déjà les niveaux d’escalades (lire cet excellent Wifi : http://wiki.nagios-fr.org/nagios/objects-reference )

Nagios envoi un mail à la BAL d’escalade et vous executer le script a réception de mail :

dans /etc/aliases

nagiossms: "|php /opt/sfr/alerte-nagios.php"

(par exemple hein, je vous laisse à votre imagination débordante :-D )

Voilà donc une solution simple pour remonter vos alertes en temps réels, que ce soit vos états critiques Nagios, vos bascules d’IP failover ou la coupure EDF sur votre Onduleur :-)

Amusez-vous bien :-D

24 Commentairess :, , , plus...

Interception des erreurs applicatives dans Nagios avec SEC et Prelude-lml

par guiguiabloc le 18 mar, 2009, sous architecture, linux

Ce billet est né d’une demande de mon ami « Poupinade » qui connaissant mon goût pour les challenges divers et variés, me demanda avec fourberie innocemment comment je ferais, moi, pour intercepter des erreurs applicatives dans Nagios.

Nagios est un outil de surveillance système et réseau. Largement éprouvé, il est déployé fréquemment pour monitorer les équipements, services etc…

Pour moi, il reste un outil d’alerte et doit être utilisé comme tel. Je ne pense pas que ce soit à lui de remonter des informations détaillées sur un problème quelconque, mais de permettre au « superviseur » de débrancher sur un autre outil s’il veut peaufiner la cause de la panne/alerte (ceux qui utilisent un Nagios avec plus de 1000 hôtes et une dizaine de services par machine me comprendront aisément ;-) ).

Je ne m’étendrais pas sur Nagios ici, encore moins sur son installation et son paramétrage.

Vous trouverez de nombreuses références et tutos sur le Nain Ternet pour vous aider à sa mise en place.

La problématique qui se pose ici est de permettre d’être informer rapidement en cas d’erreur dans les logs d’une application.

Car oui on peut surveiller le bon fonctionnement du serveur httpd, de la Base de Données, du lien réseau etc… , mais il peut arriver qu’un autre problème surgisse et que Nagios ne supervise pas.

Je simplifie à l’extrême le concept « application » et prenant comme exemple une application « web », libre à vous d’adapter ce billet à autre chose.

Dans les exemples qui suivront et pour la maquette d’architecture choisie, j’ai pris un simple site en php (en l’occurrence un FlySpray ) qui me sert au suivi de mes « travaux » (a la manière d’OVH).

Les erreurs rencontrées par une « application » sont dans la majorité des cas lisibles dans un fichier de log dédié.

Première chose, faire « tomber » les erreurs php dans le log d’erreur du Vhost d’apache :

Edition du php.ini :
 
error_reporting  =  E_ALL &amp; ~E_NOTICE
display_errors = On
 
Configuration du vhost :
 
ServerName application.guiguiabloc.fr
DocumentRoot /var/www/application
ErrorLog /var/log/apache2/application-error.log
LogLevel warn
CustomLog /var/log/apache2/application-access.log combined

Toujours a des fins de test, je simule une erreur critique, la perte de liaison avec le serveur de base de données.
En l’occurrence, j’ajoute une entrée dans le /etc/hosts du serveur httpd avec une fausse adresse IP vers le serveur Mysql, ce qui génère l’erreur suivante :

[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.2] PHP Warning:  mysqli_real_connect():
(HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108

Erreur je l’avoue très sournoise, Nagios me disant que mon serveur Mysql répond très bien et que le réseau entre le serveur applicatif et le serveur de base de données est opérationnel.

Comment surveiller ce genre de fichier et alerter Nagios quand quelque chose se produit ?

  • SEC Simple Event Correlator

SEC est un programme écrit en Perl, extrêmement puissant et configurable à souhait, qui permet de scruter des fichiers de logs et d’y détecter des événements divers et variés.

Le site est ICI

Côté installation sur le serveur applicatif, pas de soucis :

srv-appli:/usr/local/src# wget http://prdownloads.sourceforge.net/simple-evcorr/sec-2.5.1.tar.gz
srv-appli:/usr/local/src# tar xzvf sec-2.5.1.tar.gz
srv-appli:/usr/local/src# cd sec-2.5.1
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec
srv-appli:/usr/local/src/sec-2.5.1# mkdir /usr/local/bin/sec/etc
srv-appli:/usr/local/src/sec-2.5.1# cp sec.pl /usr/local/bin/sec/

Une configuration toute simple :

srv-appli:/usr/local/bin/sec/etc# cat sec.conf
type=Single
ptype=RegExp
pattern=error
desc=$0
action=shellcmd  /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "$0"

Ici, nous demandons à SEC de réagir sur la chaîne « error » (bien évidemment, vous pouvez affiner vos expression régulières…) et en cas de détection, d’exécuter la commande « /opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca  » avec en paramètre, le nom du host dans Nagios, le nom du service, le code retour Nagios et le message d’erreur.

Auparavant, vous avez ajouté une entrée de type « Passive » dans Nagios :

# NSCA
define service{
        use         passive_checkservice
        host_name    srv-appli
        service_description    Application
        # ici la commande check_smtp n'a aucune signification particuliere
        # c'est simplement que sans check_command cela ne marche pas !
        check_command                check_smtp
      }

Et oui, ce type de fonctionnement implique que vous utilisez NSCA sur le serveur d’application (surveillance passive de Nagios, c’est le serveur d’appli qui envoie l’alerte)

Vous devez sur votre Nagios, avoir une entrée de ce genre

Ne reste plus qu’à lancer le script SEC :

srv-appli:/# perl -w /usr/local/bin/sec/sec.pl -conf=/usr/local/bin/sec/etc/sec.conf -input=/var/log/apache2/application-error.log -log /var/log/sec.log
SEC (Simple Event Correlator) 2.5.1
Reading configuration from /usr/local/bin/sec/etc/sec.conf
1 rules loaded from /usr/local/bin/sec/etc/sec.conf
Stdin connected to terminal, SIGINT can't be used for changing the logging level

On provoque l’erreur

Executing shell command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
Child 10131 created for command '/opt/nagios/libexec/eventhandlers/submit_check_result_via_nsca srv-appli  'Application' 2 "[Tue Mar 17 11:13:34 2009] [error] [client 192.168.99.14] PHP Warning:  mysqli_real_connect(): (HY000/2003): Can't connect to MySQL server on 'mysql-serveur' (113) in /var/www/application/adodb/drivers/adodb-mysqli.inc.php on line 108"'
1 data packet(s) sent to host successfully.

Et l’alerte remonte dans Nagios :

Alerte Nagios

Alerte Nagios

Cela fonctionne mais bon…

Premier point bloquant, cela signifie que l’on utilise la surveillance Passive de Nagios (NSCA) sur le srv-appli, ce qui n’est pas forcément le cas.

Deuxième point bloquant, si une deuxième erreur surgit à la suite (pas de chance hein :-p), c’est celle ci qui sera affichée dans Nagios.
Je peux très bien acquitter l’alarme et passer à côté d’un problème plus crucial…

Pour le test :

srv-appli:/# echo « [Mon Mar 17 14:25:42 2009] [error] Une autre erreur » >> /var/log/apache2/application-error.log

Donc, obligation d’aller sur le serveur, de vérifier le /var/log/Sec.log….

Autre solution ;-)

  • PRELUDE IDS

Prelude est un « Security Information Management » (SIM) Universel. Prelude collecte, normalise, catégorise, agrège, corrèle et présente tous les événements sécurité indépendamment de la marque ou de la licence du produit dont ces événements sont issus : il est « Agentless ».

Cela tombe très bien, j’avais déjà écrit un billet sur Prelude l’année dernière :-D

http://blog.guiguiabloc.fr/index.php/2008/01/27/installer-et-configurer-prelude/

Vous ne serez pas pas dépaysé.

Pour scruter nos logs, nous allons utiliser un des modules de Prelude : Prelude-lml

Ce n’est pas le rôle premier de ce logiciel (qui est surtout un centralisateur d’alertes IDS/NIDS), mais rien nous interdit de le détourner de sa voie.

Je vous passe l’installation du module sur le serveur d’application ainsi que son enregistrement dans le Prelude Manager, tout est expliqué dans le billet précité.

srv-appli:/# prelude-adduser register prelude-lml "idmef:w admin:r" IP_Prelude_Manager --uid 1000 --gid 1000
prelude-manager:/:# prelude-adduser registration-server prelude-manager
 
... - prelude-lml registration to IP_Prelude_Manager successful

Une configuration succincte pour nos tests :

prelude-lml.conf :
 
file = /var/log/apache2/application-error.log
 
/etc/prelude-lml/ruleset/pcre.rules :
 
regex=(\[error\]);              include = appli.rules;
include = single.rules;
 
/etc/prelude-lml/ruleset/appli.rules :
 
#LOG:[Sun Mar 15 17:27:09 2009] [error] [client 192.168.0.1] PHP Warning:  mysqli_real_connect(
):
 
regex=\[error\] \[client ([\d\.]+)\] ; \
 classification.text=server error; \
 id=44100; \
 revision=1; \
 analyzer(0).name=Appli; \
 analyzer(0).manufacturer=blog.guiguiabloc.fr; \
 analyzer(0).class=Service; \
 assessment.impact.severity=high; \
 assessment.impact.completion=failed; \
 assessment.impact.type=other; \
 assessment.impact.description=Erreur applicative; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$1; \
 source(0).service.iana_protocol_name=tcp; \
 source(0).service.iana_protocol_number=6; \
 target(0).service.iana_protocol_name=tcp; \
 target(0).service.iana_protocol_number=6; \
 last;

Je ne m’étendrais pas sur les expressions régulières, ni sur les normes IDMEF utilisées (cela prendrait un billet complet) et je vous invite à consulter ses pages :

https://trac.prelude-ids.org/wiki/PreludeLml

http://www.rfc-editor.org/rfc/rfc4765.txt

http://www.gscore.org/blog/index.php/post/2007/08/13/IDMEF-for-dummies-part-1

On reproduit de nouveau l’erreur qui maintenant est interceptée par Prelude-lml et envoyée au Manager

Report Prelude

Report Prelude

Déjà plus classieux comme système de centralisations, non :-)

Et là vous me dites « Et comment je le sais tout cela dans Nagios ????? »

Grâce à la communauté Nagios :-D

http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2287.html;d=1

Vous y trouverez le check_prelude.pl , fonctionnant en NRPE, qui vous permet d’aller vérifier le nombre d’entrées HIGH ou MEDIUM dans la base Mysql Prelude :-)

Nagios remontera donc une alerte Critique ou Warning que vous acquitterez (ou pas :-p) avant d’aller vous connecter sur le Prelude Manager et vérifier la teneur exacte du message d’erreur applicatif et de le supprimer dès sa résolution.

Tout ceci est bien sûr un simple exercice de style, à prendre comme une piste de travail.
Je suis certain que vous trouverez d’autres solutions à mettre en oeuvre.

Amusez vous bien :-)

Laisser un commentaire :, , plus...

Vous cherchez quelque chose ?

Utilisez le formulaire ci-dessous:

Vous ne trouvez pas ce que vous voulez ? Laisser un Commentaire sur un Billet !

Special Copinage!

Quelques sites amis ou recommandés...