Vous venez de passer en production votre application web. C’est très bien, mais il va falloir maintenant superviser celle-ci pour être alerté immédiatement de tout problème qui pourrait survenir. C’est là que Prelude, Prewikka et Nagios peuvent intervenir.
Installation Prelude et Prewikka
Sur la partie installation, je ne peux que vous conseiller de votre rendre sur ce tuto très complet et très bien fait sur le site mondedie. Le pas à pas est très détaillé et vous pourrez ainsi installer et configurer sans souci les différents éléments, à savoir :
- Prelude et Prelude-Manager, les modules principaux qui vont recevoir les alertes et gérer les sondes.
- Prelude-Correlator, que je n’ai pour ma part pas installé.
- Prelude-LML, qui permet de faire des sondes pouvant lire les fichiers de logs (qui correspond à mon besoin principal, à savoir vérifier la bonne marche des mes applications web en production).
- Prewikka, l’interface web qui vous permettra de visualiser et contrôler le tout.
Configuration et définition des ruleset de Prelude-LML
Notre objectif est que Prelude aille lire des fichiers de log pour remonter tout événement notable. Il va falloir pour cela lui dire quels fichiers de logs il faut qu’il aille lire, et qu’est-ce qu’il doit chercher à l’intérieur de ceux-ci.
Le premier pas de cette configuration se fait dans le fichier de configuration de la sonde LML, chez moi localisé à cet endroit :
/usr/local/etc/prelude-lml/prelude-lml.conf
On peut définir les logs à auditer comme suit :
[format=apperror] file = /var/log/apache2/error.log [format=pqb] file = /var/www/intranet/pqb/logs/mysql_logs/mysql_error_log file = /var/www/intranet/pqb/logs/php_logs/php_error_log
Ici nous allons regarder le log d’erreur apache et deux autres logs alimentés par des outils internes.
Autre point à définir dans ce fichier de configuration, à savoir les règles qui vont permettre de définir les expressions régulières qui vont permettre de parser les fichiers de logs à la recherche des éléments qui nous intéressent :
[Pcre] ruleset=/usr/local/etc/prelude-lml/ruleset/pcre.rules
Le fichier pcre.rules sera ici le fichier qui permettra de centraliser toutes les règles que l’on souhaite charger. Dans ce dernier, on peut inclure des fichiers de règles, qui peuvent être inclus directement, ou conditionnés par des regexp :
#Exemple de règle conditionnée regex=pfDoS:; include = arbor.rules; #Exemple de règle chargée directement include = portail.rules;
Enfin, les fichiers de règles vont intégrer des expressions régulières pour savoir quoi chercher dans les logs, et comment classifier les messages trouvés (via la sévérité, permettant ainsi de classer en faible, moyen ou haut le problème). Exemple :
regex=\[:error\] \[pid [0-9]+\] \[client ([\d\.]+):[0-9]+\] (PHP Fatal error:) (.+); \ classification.text=$3; \ id=4100; \ revision=1; \ analyzer(0).name=portail; \ analyzer(0).manufacturer=www.apache.org; \ analyzer(0).class=Service; \ assessment.impact.severity=high; \ assessment.impact.completion=succeeded; \ assessment.impact.type=other; \ assessment.impact.description=$3; \ 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; \ target(0).service.name=http; \ last;
Dans ce cas les PHP Fatal Error sont classés en sévérité haute, et on récupère le texte de l’erreur via classification.text.
Vous pourrez trouver de la documentation sur la façon d’écrire les règles sur le site de l’outil. Vous aurez également à l’installation un certain nombre de règles existantes (mais plus orientées souvent administration système que suivi applicatif).
Remontée des soucis constatés
Vous avez maintenant des sondes opérationnelles qui sont capables de lire et d’extraire tout ce que vous souhaitez des fichiers de log. Voyons maintenant comment vous pouvez être avertis des différents soucis.
Nagios
Si vous avez Nagios pour la supervision, vous pouvez brancher Prelude à ce dernier avec un plugin que vous pourrez trouver sur le site de Nagios. Vous pourrez modifier le script pl si vous souhaitez changer les temps d’observation, ou les seuils du nombre d’alertes de type moyennes ou hautes qu’il faudra remonter. Sachant que vous pouvez paramétrer Nagios pour être prévenus par mail s’il y a un problème à remonter, vous serez donc prévenu directement dans votre boîte si un problème survient.
Prewikka
Vous l’avez installé normalement en suivant le tuto que je vous indiquais. Prewikka est l’interface web qui vous permettra de superviser tout cela.
Vous allez déjà pouvoir voir si vos sondes sont bien actives via l’onglet « Agents » :
Si tout est ok, vous pourrez surveiller les remontées de celles-ci via l’onglet « Alertes » :
Création d’un dashboard
Si vous avez déjà créé un dashboard, par exemple pour un écran de monitoring dans le bureau, rien ne vous empêche d’y intégrer les erreurs remontées par Prelude, car tout est stocké dans un base MySQL. Cela permet donc d’avoir accès aux différentes données si vous souhaitez vous créer un tableau de bord personnalisé.
Voici par exemple une requête qui permet de remonter les problèmes moyens ou hauts de la dernière journée, par date décroissante :
SELECT Prelude_DetectTime.time as Detection, Prelude_Impact.severity as Severite, Prelude_Impact.description as Description
FROM
prelude.Prelude_DetectTime,
prelude.Prelude_Impact
WHERE
Prelude_DetectTime._message_ident=Prelude_Impact._message_ident
AND Prelude_DetectTime.time > NOW() - INTERVAL 1 DAY
AND Prelude_Impact.severity IN ("medium","high")
GROUP BY Prelude_Impact.severity, Prelude_Impact.description
ORDER BY Prelude_DetectTime.time DESC;
Avec tout cela, vous allez pouvoir détecter tous les problèmes de production avant l’appel des utilisateurs 🙂
