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

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

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

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 🙂

Ce billet a été posté dans architecture, linux et taggé , , . Bookmark ce permalink.

2 commentaires sur “Interception des erreurs applicatives dans Nagios avec SEC et Prelude-lml

  1. Bonjour,
    Merci pour ce billet!!!
    Je suis a la recherche d’un outils pour faire de la surveillance applicative.
    Or, je viens de voir ce billet (et notamment la partie sur prélude) qui a l’air de répondre a mon besoin.
    1- Tout d’abord, pensez vous que cette solution soient cohérante avec mon besoin? (surveiller des applications)
    2- Le fameux lien vers la communauté nagios qui j’imagine mene vers des aides a la conf ne fonctionne plus, sauriez vous ou retrouver ces infos?

    Merci!

  2. de rien 🙂
    Tout dépend ce que vous voulez surveiller applicativement.
    Monit (http://mmonit.com/monit/) permet la surveillance des applications, nagios peut checker un process, GrandMa (voir billet a ce sujet) peut checker le comportement d’une application web… etc…
    Les scripts de la communauté sont disponibles sur http://exchange.nagios.org/