Introduction à ELK : Elasticsearch, Logstash et Kibana

J’ai commencé à suivre Logstash en 2011 et le moins que l’on puisse dire, c’est qu’il a fait un sacré bonhomme de chemin. Il faut dire que hormis SEC, il n’y avait pas grand chose de disponible dans le monde Open Source pour ce genre de travail.

Et puis le rapprochement naturel qui s’est opéré avec Elasticsearch et Kibana amène aujourd’hui le projet vers de nouvelles ambitions. Devenir une des pierres angulaires de la Business Intelligence… Rien moins que ça !

Il faut dire que Logstash est désormais bien entouré.

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.

Schéma de principe du fonctionnement Logstash

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.

Les entrées

Logstash accepte à peu près tout ce qui peut être représenté sous forme de chaîne de caractères en entrée. Texte, nombre, date…. La liste des entrées disponibles est impressionnate et couvre des plugins particuliers pour Collectd, Graphite, websocket, les interruptions SNMP et même l’IRC.

Il est tout à fait possible d’envisager un jour un plugin permettant de récupérer les données depuis Check my Website pour les envoyer vers une instance Logstash.

Des plugins plus génériques sont bien sûr disponibles comme Syslog, AMQP pour recevoir des messages depuis ce genre de bus messages…

Les encodeurs/décodeurs

Les « codecs » sont arrivés pour pouvoir normaliser et packager un ensemble de filtres (à découvrir ci-dessous).

Il existe de nombreux codecs dont Graphite pour encoder, décoder le format natif des métriques Graphite ou encore Netflow, qui permet lui l’encodage, décodage des flux Netflow, très utilisé (mais pas assez à mon goût) pour la supervision réseau.

Les filtres

Les filtres permettent de triturer tout message arrivant dans Logstash. Par triturer, j’entends découper un message en plusieurs parties et inversement, formatter les dates, normaliser le nom des champs mais pas seulement. Au programme, des filtres pour créer des sommes de contrôles, extraire des nombres, supprimer des messages avant stockage et bien sûr Grok.

Grok est sûrement l’un des plus puissants et permet de structurer n’importe quel message, comme des logs Apache 2 par exemple. Sa force réside dans sa capacité à construire des expressions complexes à partir d’expressions régulières plus simples.

%{SYSLOGHOST:syslog_hostname}

Dans l’exemple ci-dessus, SYSLOGHOST est une « expression » Grok qui permet de capturer une partie du message correspondant aux expressions régulières nécessaires pour reconnaître un nom d’hôte FQDN.

Les sorties

Une fois que Logstash a opéré sur les messages, ceux-ci peuvent désormais être « routés » vers les plugins de sortie qui permettent d’envoyer les messages vers un bon paquet d’outils tierces, en plus de la sortie « naturelle » de Logstash; à savoir Elasticsearch.

Des sorties sont disponibles pour des services en ligne comme Librato, DatadogHQ mais aussi vers des outils internes comme OpenTSDB, Graphite bien sûr. Il vous est tout à fait possible de soumettre un résultat de contrôle passif à Nagios par ce biais. Zabbix n’est pas oublié non plus !

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 !