Enfin du nouveau dans la gestion des logs

Posted by 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

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

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

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.

10 Comments

  1. 9-6-2011

    Quid de Splunk ? 🙂

  2. 9-6-2011

    Splunk est un excellent logiciel mais la version Open Source s’arrête à 600 Mo de données traitées par jour; ce qui peut s’avérer court pour de gros environnements. Nous essayons de privilégier des solutions sans limitation d’aucune sorte dans leur version libre.

    • 10-6-2011

      Je suis d’accord avec Olivier, Splunk est un outil de fou … facilement installable 5 min montre en main, puissant, ergonomique, dynamique, reporting de fou mais dommage qu’il soit tant limité en version libre.

      Juste pour info, la licence est à 5000$ en illimité après faut croiser avec ce qui se fait d’autre.

      Mais c’est vrai que dans la centralisation des logs notre quête de la solution qui envoie du bois continue toujours 😉

  3. 9-6-2011

    Bien le bonjour,
    Très bon 😉 J’en étais resté à OctoPussy 😉
    Je devais déjà trouver du temps pour mettre en place ce dernier, il ne me reste plus qu’à en trouver plus pour tester ceux-ci…
    Merci bien pour l’info en tous cas
    CiaO ++

    • 10-6-2011

      Humm, si tu veux mettre Octopussy sur environnement de PROD et autre chose que du Debian, accroche toi.

      Retour d’expérience

      Installation sur Redhat, beaucoup de modification de fichier car chemin en dur et Octo a dû mal à supporter la charge (gros log) –> Requêtage en regex très long

  4. 12-6-2011

    Bonjour,

    Très bon article moi qui pensait tester octopussy dans les prochains jours voilà un article qui va plutôt m’orienter vers Graylog2.

    Merci pour l’information. 😉

    • 12-6-2011

      OOps faute de frappe sed -i ‘s/testé/tester/g’ mon_message précédent

  5. 30-6-2011

    je suis entrain de faire la mise en place d’une plate forme de supervision et la je viens de commencer la supervision applicative…(supervisier les fichiers log des serveurs), j’hesite encore entre Graylog2 et octopussy …surtout au niveau de la supervision des serveurs Windows!!ma question est comment faire pour récupérer les fichiers log windows dans les deux cas…!
    Aussi en fait je veux mettre sur environnement de PROD et l’installation sera sur un REdhat.. quelqu’un à des idées…!!merci:))

    • 1-7-2011

      Même si ce genre de question à plus sa place dans nos forums, je vais tenter d’y répondre rapidement ici. Il existe plusieurs solutions pour faire suivre des logs Windows vers Syslog dont notamment SNARE. Centreon possède un module E2S.

  6. 31-8-2011

    Bonjour,

    Je viens de tester la solution de Graylog2 : tout est Ok sauf que pour certains logs provenant d’un JBOSS (redirigé vers le serveur SYSLOG), les logs sont tronqués (je n’ai que les 3 dernières lignes).
    Si quelqu’un a eu ce problème…