Enfin du nouveau dans la gestion des logs

Posted by Olivier Jan on 9 Juin 2011 in Planet, Supervision | 10 comments

Dans une époque qui deviendra peut-être lointaine, à part centraliser ses fichiers journaux aka logs via le protocole syslog (pour les fichiers à cette norme) et un bon vieux tail -f sur le résultat ou mieux, un multitail, arrosé d’un soupçon de scripts personnels, il n’y avait pas grand chose de possible en matière de centralisation, gestion (recherche, archivage) des fichiers journaux.

Et puis sont apparus les premières initiatives pour tenter d’aller plus loin pour gérer et voir ces fichiers depuis un seul point d’accès. PHPLogCon, 8pussy, pour ne citer que ceux que je connais (comprendre testé voir mis en production) appartiennent à cette catégorie de logiciels apportant un côté plus « moderne » à cette problématique. Même si ce sont tous les deux de bons outils, certains choix technologiques comme le stockage des messages reçus en bases MySQL pouvait faire vite exploser la volumétrie sur le serveur central gérant ces logs.

Il semble qu’un vent nouveau souffle ces temps-ci et que des approches nouvelles apportent un regain d’intérêt pour cette problématique bien connu des administrateurs systèmes (mais pas que car les administrateurs réseaux et applicatifs gèrent aussi des fichiers journaux). Faisons ensemble le tour de ces nouveaux acteurs de la gestion des fichiers journaux.

Graylog2

Le premier, le plus ambitieux peut-être ou tout au moins le plus complet (et accessoirement celui que j’ai le plus testé pour le moment) est graylog2.

Ce logiciel commence fort en apportant un nouveau format de journalisation appelé GELF (pour Graylog2 Extended Logging Format) qui permet d’aller plus loin que le vénérable Syslog, notamment sur la longueur des messages gérés. Mais ce n’est pas tout. Un démon écrit en Java et une interface web écrite en Ruby complète ce logiciel fort bien né. Le démon Java (on aime ou pas) n’est autre qu’un serveur de type centralisation Syslog avec des performances qui semblent vraiment très bonnes. Une autre de ces particularités est de stocker les messages dans une base MongoDB, appartenant au mouvement NoSQL. En dehors de l’effet de mode pour ce mouvement, il faut reconnaître la pertinence de ce choix en regardant la rapidité de requêtage sur une base bien remplie, l’efficience du stockage (500 Mo pour 2 millions de messages environ) et la possibilité d’avoir une rotation des dits messages à la RRD. C’est à dire que vous fixez au départ une taille maximale de base et les anciens messages seront effacés dès lors que celle-ci atteint cette taille. Fini les fastidieuses purges MySQL.

Au quotidien, Graylog2 permet de se construire des streams (pensez flux comme les RSS) qui permettent de n’afficher dans l’interface que les messages, événements qui vous intéressent. Il est possible de connecter ce logiciel à Nagios et d’être alerter par mail quand un nouvel événement suivi apparaît. Une bien jolie réalisation qui arrive bientôt en version 1 et qui est déjà en production (sans souci) sur l’infrastructure monitoring-fr. Vous pouvez trouver un didacticiel d’installation de graylog2 dans le wiki.

Logstash

Le deuxième, Logstash, est peut-être plus à ranger dans les outils de pré-processing de fichiers journaux. Sa force réside dans ses nombreuses possibilités d’entré-sortie et à son interfaçage possible avec Elasticsearch, puissant moteur de recherche en mode full web. Au programme des entrées possibles, outre les traditionnels fichiers journaux au format syslog, il est possible d’ingurgiter des messages au format amqp, file (Apache, Nginx…), redis, stdin, stomp, syslog, tcp, twitter. Excuser du peu ! Sur ces entrées sont appliqués des filtres et là aussi, il y a du choix avec des filtres possibles sur les date, field, grep, grok, grokdiscovery, multiline. Enfin, une fois reçu et filtré, il est possible de renvoyer le résultat vers des sorties amqp, elasticsearch, gelf (utilisable en amont de Graylog2 donc), internal, mongodb, nagios (hum les bonnes alertes), redis, stdout, stomp, tcp, websocket. Bref, pour centraliser, manipuler, triturer et réexpédier dans le backend adéquat les messages de tout type, il y a de quoi faire.

Log.io

Le petit dernier de ce renouveau est log.io. Même si une partie du logiciel permet de collecter les messages à afficher, celui-ci donne la part belle à l’interface temps réel avec dans le moteur les toutes dernières tendances web comme node.js. Cette interface permet de filtrer à coup de regex les messages s’affichant et l’écran permet de scinder temps réel et historisation pour un type de messages. Ce projet encore jeune, suscite déjà pas mal d’intérêt sur la toile, preuve qu’il correspond à un besoin non couvert. L’auteur de Graylog2 a d’ores et déjà annoncé un plugin pour ce logiciel.

Gageons qu’il y a là de bien jolies briques pour se construire une gestion centralisée, personnalisée et efficace des fichiers journaux. Vous devriez pouvoir trouver des tutos bientôt en plus grand nombre sur ces outils dans le wiki.