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 
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 
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
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");
?>On appelle le script : php alerte-sms_bascule-IpFO.php
et hop; magique, un SMS du 6011
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
;;
esacCô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 )
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
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 & ~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
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
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
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
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
