Le volume de données générées par les systèmes d’informations augmente de façon quotidienne, et l’exploitation de ces données est un enjeu pour beaucoup d’entreprises. Parmi les solutions permettant de répondre à ce besoin, on cite souvent la suite Elastic Stack, ElasticSearch, Logstash et Kibana, afin d’analyser les données en masse, les visualiser et faire émerger des tendances. Méthodologie, bonnes pratiques Elastic Stack… nous partageons ici avec vous notre retour d’expérience sur la mise en place de projets ELK.

Dans quel contexte sont menés les projets ELK ?

A l’origine de la plupart des projets ELK, on trouve le plus souvent la même demande, celle d’extraire une information qui est dissimulée dans un lot de données volumineux. Peu importe le format sous lequel est stocké l’information: fichier de logs, base de données, autre média… la finalité est toujours d’extraire certaines données et de les synthétiser dans un graphique ou un dashboard.

Deux cas de figure sont alors possibles : soit l’information existe déjà, et il reste à aller la chercher dans le flot de données; soit elle n’existe pas encore, et dans ce cas il faut modifier son application ou son infrastructure pour qu’elle soit disponible et ensuite incorporée dans la chaîne ELK.

Cependant, il faudra au préalable s’assurer de définir très exactement le besoin, la demande des équipes souhaitant utiliser ELK pouvant souvent être floue. A quel besoin doit répondre la stack ELK ? Quelles informations sont nécessaires à la prise de décision, et existent-elles déjà dans le système ? Si ce n’est pas le cas, comment peut-on les fournir ? Ensuite seulement, on pourra envisager d’utiliser ELK pour répondre à ce besoin.

Dashboard Kibana

Cas d’usage : corriger un dysfonctionnement applicatif

Comment déterminer son besoin d’information ? C’est la problématique du Big Data, où l’on ne sait pas toujours ce que l’on cherche avant de l’avoir trouvé. Cependant, dans les cas que nous avons rencontrés, l’élément déclencheur du besoin était souvent un dysfonctionnement applicatif. Dans ce cas, la résolution passe par l’analyse des logs pour comprendre ce qui s’est passé, l’identification du problème pour éviter qu’il ne se reproduise. Toute la difficulté consistant à identifier les données et caractéristiques qui permettraient de résoudre ce problème.

Cette phase d’identification est dé-corrélée d’ELK : quelle information permettrait de prévenir un bug ou une situation anormale ? Cela suppose de comprendre l’architecture de l’application et ses différents workflows. Nous avons par exemple rencontré le cas d’un workflow complexe, où il fallait sortir des informations à un point déterminé du workflow, et les mettre en corrélation avec une autre information pour détecter une anomalie.

Encore une fois, il y a un certain travail à faire en amont pour savoir à quel besoin doit répondre l’outil. Attention à “l’effet de mode” : on peut être séduit par ELK, sa capacité à traiter des données et à les synthétiser … mais sans savoir vraiment à quoi ça va servir et ce qu’on analyse.

Cas d’usages fréquents d’ELK

Récupération des erreurs explicites (exception, message d’erreur), collecte de données statistiques pour avoir une vision globale de la production, suivi de la charge d’une application (mémoire consommée, CPU), extraction de données spécifiques pour le métier (permettant de valider une chaîne de workflow, ou un input et un output)… les cas d’usage de la suite ELK sont nombreux.

Le premier cas d’usage le plus fréquemment rencontré est d’obtenir une vision globale du système : numéros de versions, monitoring des différentes machines et applications, mémoire et CPU consommés, statistiques sur les entrées et sorties de l’application. Ce monitoring se fait sur le long terme, afin de voir se dégager des tendances sur 3 mois, 6 mois ou une année. On peut ainsi détecter les signes d’un dysfonctionnement : fuite mémoire, alourdissement anormal de l’application qui ne correspond pas à une augmentation de la charge, etc.

Second cas d’usage, le besoin de valider en continu le déroulement d’un workflow en plusieurs étapes. A chaque étape, un certain nombre d’informations est loggé (sous format de fichier ou autre), et à terme on compare l’état à chacune des étapes. On peut ainsi établir un modèle prédictif dès la première étape, et analyser ensuite les écarts éventuels.

Mise en place d’ELK – Logstash

La première étape consiste à trouver comment fournir les informations dont on a besoin : logs, fichiers, base de données, etc. S’il s’agit de logs, il faut alors modifier l’application pour qu’elle produise les logs nécessaires. On peut ensuite passer à l’extraction des informations avec Logstash. C’est la partie la plus délicate, et qui demande un accompagnement : pour extraire les informations, il faut appliquer un certain nombre de Regular Expressions (regex). Dans le cas des logs, l’information y est en effet présente dans un format particulier : elle se trouve dans une chaîne de caractères constituée de la date du log, de la source, de l’information en elle-même, et d’autres informations. On doit donc découper en segments, pour aller chercher l’information nécessaire (voir tutoriel ici).

Logstash fonctionne à bas niveau : le logiciel prend les lignes une par une, et les envoie au format brut à ElasticSearch. La complexité de l’utilisation de Logstash vient du fait qu’il est possible d’appliquer des filtres entre la réception et l’envoi pour découper l’information, la transformer, la mapper . Les possibilités offertes par les filtres sont nombreuses, et on peut aussi créer ses propres filtres en Ruby. De ce point de vue, Splunk offre plus de facilité à l’utilisateur, en permettant à l’utilisateur d’aller chercher de l’information graphiquement (clicks and selects). Splunk s’occupant de traduire les sélection de l’utilisateur en regex.

Mise en place d’ELK – ElasticSearch, Kibana

Dans le cas de l’installation d’ElasticSearch, deux cas de figure peuvent se présenter, selon la taille de l’entreprise : soit on installe ElasticSearch indépendamment pour chaque équipe qui en fait la demande, soit on centralise l’infrastructure ElasticSearch. Plutôt qu’une instance pour chaque équipe, un seul serveur centralise les données de toute l’entreprise. Cette solution permet aux utilisateurs d’ElasticSearch de ne pas avoir à gérer son infrastructure.

Le même principe de centralisation est valable pour Kibana, mais à l’heure actuelle ElasticSearch et Kibana ne proposent pas un système d’autorisation suffisamment fin pour pouvoir séparer l’accès aux données pour chaque équipe. Il est possible d’utiliser une séparation par domaine, mais un même domaine (le trading électronique par exemple), peut regrouper plusieurs équipes. Une équipe pourrait alors avoir accès à des données qui ne sont pas les siennes, ce qui pose des problèmes de sécurité et de confidentialité sur les données sensibles. A l’heure actuelle, la seule option pour prévenir ce problème est d’installer en local. Des initiatives, de la part d’Elastic et de la communauté, sont actuellement en cours afin de combler ce manque.

Enfin, notons qu’il est également possible d’utiliser Kafka en complément d’ElasticSearch, afin de faire tampon entre ElasticSearch et ceux qui envoient les messages. Cela permet par exemple d’arrêter ElasticSearch le temps d’une mise à jour, Kafka se chargeant de stocker les messages et de les transmettre une fois que le serveur ElasticSearch est à nouveau disponible.

Dans un prochain article, nous comparerons ElasticSearch et Splunk : si la première solution séduit par son absence de licence, Splunk fournit plus d’assistance à l’utilisateur et permet d’extraire des données plus facilement qu’avec Logstash. Autre avantage pour Splunk, celui de pouvoir extraire des champs de données à tout moment, les données étant stockées au format brut.

En complément, découvrez un aperçu de l’architecture ElasticSearch Deezer par Aurélien Saint Requier :

Automatisation, Big Data, DevOps, Désautomatisation… tous ces sujets seront abordés lors du TIAD 2016. Rejoignez-nous !