Introduction à ELK : Elasticsearch, Logstash et Kibana

Mon premier s’appelle Elasticsearch

S’il y a un élément qui prend une importance priomordiale dès lors que l’on souhaite analyser, stocker des messages, événénements systèmes ou applicatifs, c’est la base de données utilisée. Les bases de données traditionnelles (SGBD) ont montré, comme dans le cadre du stockage des métriques, leurs « limites » pour travailler sur les volumes imposés par ce genre de pratique.

Et le choix de Elasticsearch n’était pas si évident que ça en 2011. Très jeune à l’époque, - il vient de passer en version 1.0 il n’y a pas si longtemps - Elasticsearch n’est pas à proprement parlé une base de données mais un moteur d’indexation, de recherche et d’analyse de données. Et c’est certainement là que Jordan Sissel, auteur de Logstash a fait une bonne pioche. Car du coup, son projet bénéficie des fonctionnalités intrinsèques à Elasticsearch comme :

• Le mode cluster actif/actif natif de Elasticsearch.
• Les volumes qu’est capable de traiter Elasticsearch en matière de recherche tout en restant temps réel; ou quasi.
• Le système de « facets » qui permet, sans coût supplémentaire, de récupérer tout un ensemble de statistiques sur les éléments trouvés, comme le nombre, la répartition de ces éléments par rapport à une clé…
• La possibilité de commencer à envoyer des résultats à l’utilisateur alors que la recherche n’est pas terminée sur l’ensemble des données. Logstash créé par exemple un index par jour, ce qui fait que vos recherches les plus courantes restent rapides, quelque soit le volume total d’événements stockés en base. Je m’appuie pour cette affirmation sur le fait que les recherches dans les logs se font souvent pour la journée en cours.
• La possibilité d’effectuer toutes les recherches via une API REST donc pas de client dédié nécessaire.

Ceci n’est pas une liste exhaustive des qualités de Elasticsearch mais simplement celles qui m’ont le plus marquées dans son utilisation. J’aurais également pu présenté les « rivers » Elasticsearch mais elles ne sont pas vraiment utiles dans le contexte qui nous préoccupe; le stockage et l’analyse de logs. Notre « rivière » dans le contexte gestion de logs, c’est Logstash !

Mon second Logstash

Ce qui est particulièrement frappant aujourd’hui est de constater la diversité des usages que font les gens de Logstash, ce qui atteste de la polyvalence du projet en matière de traitement sur les messages et autres événements.

C’était jusqu’à peu la seule solution à ma connaissance qui permettait de contruire des systèmes de gestion de logs structurés et normalisés pour Unix et Windows.

Ce genre de chose est désormais également possible avec Rsyslog qui lui aussi sait désormais envoyer ces messages vers Elasticsearch. Bel exemple de convergence technologique !

Logstash fonctionne sur un principe simple, un peu comme un routeur de messages. Il est possible de parler de chaînes de liaisons entre ces différents composants.

Tous les différents éléments que nous allons détailler sont implémentés sous forme de plugins, ce qui rend très « facile » d’ajouter des possibilités à Logstash. La liste de ces plugins ne cessent d’ailleurs de croître.

%{SYSLOGHOST:syslog_hostname} 

Mon troisième Kibana

Kibana a démarré comme un projet d’interface à Logstash. C’est aujourd’hui l’interface officielle de Elasticsearch.

Vous pouvez donc l’utiliser pour visualiser, rechercher parmi les messages de logs et autres événements système mais n’est pas du tout limité à ça. Kibana vous permet de requêter et visualiser n’importe quelle données contenues dans Elasticsearch.

Personnellement, j’aimerais beaucoup voir s’opérer un rapprochement Kibana et Grafana afin de n’avoir qu’une interface pour visualiser métriques et événements, messages. Ce rapprochement paraît possible au moins techniquement puisque Grafana puise une bonne partie de son code de base à Kibana.

Et mon tout s’appelle ELK

Ces trois logiciels combinés forment désormais ce qu’il est convenu d’appeler la « pile ELK ». L’ensemble est à disposition sur le site de Elasticsearch et il est désormais possible d’installer tout ce joli monde soit via des paquets spécifiques à votre OS (RPM, DEB…) soit directement depuis des dépots officiels.

Bref, c’est pas l’installation qui devrait vous empêcher de commencer à utiliser ELK. Et une fois qu’on y a goûté, il devient très difficile de s’en passer, parole d’ « ELK addict » !

D’autant qu’il est possible de trouver un tas d’application à cette pile de logiciels, bien au delà de la supervision. Je vous laisse libre de décider si ELK pourrait être la base d’une solution ETL complètement générique !

#Monitoringlove ?

#monitoringsucks et #monitoringlove sont deux hastags sur Twitter pour commenter les deux relations qu’il est possible d’entretenir avec les outils de supervision en général.

Je crois que cette fois, c’est plutôt monitoringlove ! Nous avons une solution plutôt complète qui va servir à monitorer en interne, côté serveur, sites et applications web.

Bien sûr, nous ajouterons encore quelques petites pépites pour avoir des notifications, détecter des comportements anormaux sur nos métriques et messages.

Tous les billets à venir concernant les métriques et événements à analyser pour pouvoir offrir la meilleure vision et analyse de vos sites web s’appuieront sur cette « pile » logicielle désormais constituée de ELK, Graphite et Grafana. Ca va roxer sévère sur Wooster !