Qu’est-ce qu’un log et pourquoi en faire l’analyse? Chaque application génère des événements, et certains de ces événements sont assez importants pour être archivés et écrits sur un média persistant. Dans le cas d’une GUI de trading, l’application peut générer jusqu’à 1 giga de logs par jour et par utilisateur. Cela représente plusieurs centaines de milliers de lignes et énormément d’informations. Certaines informations sont superflues, d’autres plus intéressantes.

Mise à jour du 26 Julllet 2016 : nous recrutons des profils ELK ! Vous souhaitez rejoindre une structure dynamique, engagée et en pleine croissance ?N’hésitez plus et envoyez nous votre candidature : recrutement@revolve.team

A lire également sur le sujet : Bonnes pratiques Elastic Stack

Il est difficile pour un développeur d’exploiter rapidement ce fichier de milliers de lignes pour trouver l’information pertinente, et d’en faire une synthèse. Pour un profil non technique, c’est encore plus difficile. Les logs sont pourtant riches d’enseignements, notamment en termes de débugguage : en analysant les logs, on peut comprendre la cause du problème et l’origine du bug. D’où l’intérêt de mettre en place des outils d’analyse de logs applicatifs, comme la suite ElasticSearch.

Logstash, Elastic Search et Kibana : ces trois outils ont chacun un rôle bien précis dans le workflow permettant de passer des logs bruts au format fichier à des dashboards avec graphiques et statistiques, qui montreront de manière synthétique le contenu des logs.

Logstash

Ce premier outil permet de mettre en place l’analyse des logs.  Les points d’entrée (input) utilisés pour aller chercher l’information sont définis via un fichier de configuration. Plusieurs types de point d’entrée peuvent être choisis, et notamment les fichiers : dans ce cas, on indique à Logstash l’emplacement où aller lire les fichiers de log. Logstash lit ensuite ces fichiers ligne par ligne. Il est alors possible d’appliquer certains “filtres” sur ces lignes : il ne s’agit pas seulement de sélectionner certains informations et d’en écarter d’autres, mais également de faire des opérations plus complexes, comme du mapping. Par exemple dans le cas d’un log avec UID, il est possible de résoudre l’ID en “Nom, Prénom” en faisant un appel externe. Il est également possible  d’extraire des informations spécifiques et les stocker dans des champs spécifiques, ou encore d’exécuter du code Ruby. Autre exemple : le filtre GROK permet d’extraire des informations à l’aide de RegEx (expressions régulières) pour matcher certains patterns, comme un numéro de version.

Une fois que les points d’entrée et les filtres sont définis, on indique à Logstash où envoyer les résultats : plusieurs points de sortie, ou adapteurs, peuvent être définis. Le plus utilisé est Elasticsearch, mais il pourrait s’agir d’une BDD, ou d’un fichier…Logstash est bien un ETL (Extract Transform Load, des entrées, des sorties, un traitement entre les deux).

Logstash peut également être utilisé seul, par exemple pour récupérer des fichiers, y trouver les exceptions et en faire un output dans Jira afin de créer un nouveau ticket pour chaque exception rencontrée. L’équipe peut ainsi récupérer chaque jour les tickets crées et bénéficier d’un système de reporting de bug automatique, sans que l’utilisateur ait besoin de faire quoi que ce soit.

Elasticsearch

Toutes les données de Logstash sont ensuite envoyées vers Elasticsearch. C’est un outil de stockage où toutes les données sont indexées, pour ensuite être retrouvées plus facilement. C’est une base NoSQL qui est orientée Big Data : il peut donc gérer un très grand volume de données.

Elasticsearch fonctionne sur le principe d’un cluster, soit un groupement de nœuds.  Un nœud est une instance d’Elasticsearch, et chaque instance peut tourner sur une machine différente. Un cluster est donc constitué de plusieurs machines qui sont connectées sur un même réseau, avec plusieurs instances d’Elasticsearch qui communiquent ensemble.

Les données sont stockées dans des index, qui sont découpés en un certain nombre de fragments (shards);  par défaut Elasticsearch découpe un index en 3 fragments. Les fragments sont ensuite répartis sur différents nœuds du cluster ; ainsi un index de 100 documents sera réparti en 2 index de 33 et un de 34. Cela permet d’utiliser la puissance des différentes machines du cluster (stockage, mémoire vive ou processeur), et donc de répartir la charge (load balancing). Le système est scalable, et on peut ajouter des machines selon les besoins.

Chaque shard dispose d’un Replica, une copie conforme, sur laquelle toute modification est reportée. Ainsi, si un nœud du cluster tombe (quelle que soit la raison : disque dur crashé, machine non connectée au réseau…), et qu’il contient des fragments de certains index, Elasticsearch ira chercher les réplicas des fragments qui étaient dans le nœud tombé. Autre intérêt du système de réplica, si un nœud contenant un fragment est très occupé, Elasticsearch fait automatiquement suivre les requêtes vers le nœud contenant le réplica correspondant.

La grande force d’Elasticsearch est de proposer tous ces services de façon transparente pour l’utilisateur. Il lui suffit en effet d’installer Elasticsearch, d’indiquer le nom de cluster que l’instance doit rejoindre et le moteur de recherche fait tout le reste : rejoindre le cluster, communiquer avec les différents nœuds du cluster, gérer les fragments, les replicas, si un nœud tombe, etc. Il est également possible de configurer en profondeur et de prévoir des use case particuliers (comme se comporter sur tel scenario).

Enfin il est également possible de communiquer avec Elasticsearch via une API Rest (ajouter des données, administrer le cluster, etc…voire rajouter une surcouche applicative pour faire plus de choses). Il existe également des outils développés par la communauté, comme Elasticsearch HQ (outil web en HTML et AngularJS) qui se connecte au cluster pour voir ce qui s’y passe : combien de nœuds, index, documents…Elasticsearch HQ permet d’administrer le cluster, d’ajouter des données, d’en enlever, etc.

Elasticsearch intervient après Logstash, et stocke les données envoyées de la meilleure manière possible pour qu’elles soient exploitables. L’outil est basé sur un framework Apache Lucen ; Lucen permet de faire de la recherche instantanée (de l’ordre de la milliseconde) en full text.

Exemple de performance sur une machine Windows 7, 8 giga ram, core I5 : 50 millions de documents indexés sans latence (requête en moins d’un seconde). Au-delà, les temps de réponse sont dégradés. Le plus gros cluster connu représente 500 nœuds pour 80 tera de données (soit 4 milliards de docs).

Kibana

Kibana est le dernier outil de notre suite destinée à l’analyse des logs applicatifs : les données brutes sont analysées dans Logstash, stockées dans Elasticsearch, mais ne sont pas encore exploitables. Kibana est une interface Web qui se connecte au cluster Elasticsearch, et permet de faire des requêtes en mode texte pour générer des graphiques (histogrammes, barres, cartes…), ou des statistiques. De nombreux composants graphiques sont disponibles pour donner une dimension visuelle aux données stockées dans Elasticsearch. La création de tableaux de bord est intuitive grâce à une interface WYSIWYG (pas de code à créer). Les tableaux de bord ainsi générés sont exploitables par les développeurs, les profils techniques, mais aussi par les interlocuteurs du métier ou les managers.

Kibana 3

Retour d’expérience sur la suite Logstash Elasticsearch Kibana

Dans le cas de notre application, de nombreuses versions sont déployées en production, et certaines de ces versions ont plus de 6 mois. Comment savoir quelles versions utilisées en production, par qui, quel pourcentage des instances en telle version? Avec des instances un peu partout dans le monde, obtenir ce genre d’information est compliqué. Pourtant, elle est bien présente dans les logs, et la suite ELK nous permet de produire un graphique montrant le nombre d’instances utilisées par version au cours du temps, et un comparatif entre chaque version (50% des instances avec telle version etc.). Cela nous a permis de savoir qui utilisait d’anciennes versions, et de demander ensuite aux utilisateurs de les mettre à jour.

Par ailleurs, la suite ELK nous permet de monitorer le nombre d’exceptions générées chaque jour : quand il y a un pic, on fait tout de suite le rapprochement avec la dernière livraison, et cela nous permet d’apporter des corrections dans la foulée sans attendre les retours des utilisateurs.

Kibana 4

Tutoriel : Setup Logstash Elasticsearch Kibana sur AWS