Centraliser de gros volumes de log pour mieux les exploiter

Vladislav Pernin est venu au Lyon Jug parler d’un sujet qui l’occupe depuis un petit moment… la centralisation des logs. Sa présentation était très intéressante car elle mêlait une présentation rapide des outils, du livecoding et un retour d’expérience sur l’implémentation de ces solutions chez un client final. Ce que j’ai aimé dans cette présentation c’est que Vlad nous a remonté son ressenti et ses résultats observés sans langue de bois.

Centraliser ses logs
La centralisation des logs est un des sujets à la mode en ce moment dans l’IT et de nombreuses entreprises cherchent à exploiter au mieux leur logs. Nous sommes rentré dans l’air du BigData et les outils sont aujourd’hui assez performants pour pouvoir analyser efficacement des gros volumes de données. De plus dans les nouvelles architectures redondées le nombre de serveur ne fait qu’augmenter. Il est parfois difficile de suivre les problèmes quand on doit analyser x noeuds, qu’un utilisateur est dispatché sur plusieurs serveurs…. Les contraintes de sécurité demandent aussi de limiter les accès aux serveurs frontaux. Avoir un outil centralisé permet de résoudre ces différentes problématiques.

Plusieurs solutions sont possibles pour mettre en place cette centralisation. Mais pour faire adhérer les personnes et leur donner confiance plusieurs éléments doivent être réunis. L’architecture mise en place doit être

• réactive et ne pas mettre des heures à remonter les logs 
• scalable pour facilement plugger de nouvelles applications
• robuste pour pouvoir encaisser la volumétrie des logs
• fiable sans perte de logs
• exploitable en fournissant des outils d’analyse simples

Nous avons vu le côté architecture mais il faut également mettre en place d’autres éléments pour faciliter le suivi. Prenons l’exemple d’un problème remonté par un utilisateur. Il faut avoir les moyens de retracer les différentes opérations qu’il a lancées sur les différents serveurs qu’il a utilisés (application, base de données….). Pour celà il est préférable de disposer d’un id de corélation. Sur des applications écrites en spécifique, ceci n’est pas forcément compliqué mais c’est plus dur lorsque l’on souhaite exploiter des logs générées par des applications tierces.

Avant de se pencher sur les produits, voici un schéma de l’architecture cible. Dans la solution proposée, il faut être capable d’interagir avec des applications spécifiques et avec des progiciels.

Solution proposée
Voici la stack proposée par Vlad

Logstash
Pour les connaisseurs de shell Linux, logstash se comporte comme un tail intelligent. Il capture les logs générées à la volée pour les réexpédier tout en étant capable de reprendre là où il en était en cas de relance. Il gère également la rotation des logs et offre de nombreux filtres pour réaranger les logs avant de les envoyer. Logstash est un agent Java. On le lance en lui passant un fichier de configuration dans lequel une source de logs et une cible sont définies. Les logs sont poussées vers un broker de message AMQP, RabbitMQ

  

logstash est aujourd’hui intégré à elasticsearch

Logstash est le composant idéal pour s’interfacer à des fichiers de logs générés par exemples par des logiciels existants ou des progiciels.

AMQP
Un petit rappel AMQP (Advanced Message Queing Protocol) est un protocole d’échange de messages interapplicatif fiable et sécurisé utilisable par différentes applications quelque soit le langage de programmation utilisé.

RabbitMQ

RabbitMQ est le broker AMQP le plus populaire. Basé sur le langage Erlang il permet de gérer les échanges AMQP. En cas de plantage son mode persistant permet de s’assurer qu’aucun message ne sera perdu. De plus logstash est capable d'attendre que RabbitMQ réponde à nouveau. RabbitMQ est également scalable et a l’avantage de fournir une interface web permettant de suivre les queues définies et les messages envoyés.

 

Spring AMQP

Pour des développements spécifiques faits en Java nous utilisons souvent log4j pour gérer nos logs. Log4j propose différents appenders pour orienter les logs vers différentes cibles. Spring AMQP et l’appender log4j permet de réorienter les logs applicatives vers une queue AMQP

Elasticsearch.
Centraliser les logs est une bonne chose mais l’intérêt est de pouvoir les exploiter. Pour faire des recherches pertinentes il faut indexer les différentes données reçues. Elasticsearch permet de le faire efficacement. Vous pouvez utiliser la river RabbitMQ permettant d’envoyer les messages d’une queue à elasticsearch.

Par contre pour faciliter la lecture il est préférable de retravailler les données reçues en uniformisant les informations indexées. Le plugin grok de logstash fournit différents patterns pour formater les logs et il est fournit avec différents patterns d’analyse de logs de solutions existantes (comme le serveur web Apache par exemple)

.

Kibana
Au niveau interface graphique Kibana fournit avec Elasticsearch permet de restituer des statistiques dans une application Web. Cette application fournit plusieurs graphiques construits sur les données indexées qui peuvent être une bonne base pour un début d’analyse. Pour des besoins plus poussés vous devrez créer votre propre interface.

On pourrait se dire que l’architecture est compliquée, longue à mettre en place et coûteuse. Certes il y a un coût mais qui peut se transformer en gain en fonction de l’architecture applicative d’un SI. Niveau complexité, Vlad a pu lors de sa partie Livecoding mettre en place une solution opérationnelle en moins d’une heure. Certes le scénario était prêt et cadré, et une réelle mise en place sur un SI complexe peut demander un peu plus de temps. La plus grande problématique restent les problèmes d’intégration et de sécurité.

Quelques critiques sur les différents produits cités
Logstash
++ Le plus riche de sa catégorie fonctionnellement
++ Rapide à mettre en oeuvre et bonne communauté
+ Performance assez bonne. Les problèmes commencent à partir de 2000 lignes/sec
-- Encore jeune et mouvant
- Logstash conseille l’utilisation de Redis ou ZeroMQ plutôt que RabbitMQ mais la sécurité et la persistance ne sont pas au rendez vous

RabbitMQ
++ Bonne documentation
++ mode cluster et mode sécurisé
- Mode persistant pose des problèmes à partir de 10000msg/sec
- Empreinte CPU importante

Elasticsearch.
++ Grande communauté
++ Super performances qq ms sur 30 millions de ligne de logs
++ Haute disponbilité et sacalable facilement
-- Manque de documentation
-- la river RabbitMQ sera deprecated en version 1.0
-- Difficile de faire des recherches complexes
- Outillage limité pour le moment car le produit est jeune
- nécessite de savoir ce que l’on va chercher pour indexer efficacement. Demande de l’expertise sur le sujet

Pour terminer Vlad a rapidement parlé de Apache Kafka qui offre de très bonnes performances et qui serait une bonne alternative à RabbitMQ

Reférences
Je vous invite vivement à lire les slides de Vlad et merci pour son retour.
Pour les outils utilisés je vous oriente vers les sites des éditeurs logstash, elasticsearch, rabbitmq, Apache Kafka, Spring AMQP