Nouveautés ElasticSearch 6.0

28 septembre 2017, Elastic met à disposition la RC1 de la Stack Elastic, à savoir :

• ElasticSearch
• Logstash
• Kibana
• Famille Beats

A l’aube de la sortie de la version finale, je me propose de vous présenter quelques une des nouveautés qui composent cette version.

A noter : cette liste n’est pas exaustive, et certaines des nouveautés présentées ci-dessous ont déjà introduites dans les versions de la stack Elastic 5 supérieures à 5.0.

ElasticSearch 6.0

Dépréciation mappings multiples pour un index

En Elastic v1, on pouvait définir un index contenant plusieurs mappings, chacun ayant sa propre définition.

Avec Elastic v2 et v5, des restrictions se sont appliquées aux mappings : au sein d’un même index, un nom de champ partagé entre plusieurs mappings doit avoir un type unique par exemple.

En v6, à présent, la volonté est d’avoir 1 index = 1 mapping. La gestion des mappings multiples est encore supportée, mais dépréciée. Le warning est donné en v6, et il ne sera plus possible de définir plusieurs mappings au sein d’un même index en v7.

Ceci permettra d’éviter les conflits malheureux entre mappings.

Stockage amélioré

ElasticSearch 6.0 promet de gagner de l’espace disque dans le stockage.

Deux facteurs participent au gain de place :

• Dépréciation du champ spécial _all dans ElasticSearch 6.0. Si vous ne connaissez pas ce champ, il s’agissait d’un champ spécial qui concaténait toutes les valeurs des champs du document, permettant une recherche facilitée sans avoir à préciser le champ.

• Elasticsearch 6.0 se base sur Lucene en version 7, ce qui permet de gagner de la place pour les champs aux valeurs éparses (sparse field), c’est à dire les champs qui ne possèdent une valeur que pour un faible pourcentage des documents.

Au niveau du gain, on peut espérer 40% d’économie d’après l’article du blog “Space Saving Improvements in Elasticsearch 6.0”.

Amélioration récupération des shards

Chaque opération possède désormais un numéro de séquence unique, qui permet d’améliorer l’ordonancement des opérations lors de la réplication entre noeuds, voire entre clusters. Ces numéros de séquence permettent également d’améliorer la récupération des shards en cas d’indisponibilité d’un noeud pendant un laps de temps.

Concrètement, à chaque résultat d’opération (pas sur les documents), 2 champs sont ajoutés :

• un champ meta _seq_no qui contient le numéro de l’opération
• un champ meta _primary_term, valeur qui s’incrémente quand un shard primaire est promu

Elastic met ainsi en évidence quelques perspectives pour ces champs dans les versions suivantes, notamment la réplication Cross-Datacenter.

Fin de support pour les index créés en ElasticSearch 2.0

Les index créés en ElasticSearch 5.X seront lus par ElasticSearch 6.0. En revanche, Les index créés dans ElasticSearch 2.X devront être réindexés dans ElasticSearch 5.X avant de pouvoir être lus par ElasticSearch 6.0

Logstash 6.0

Plus simple que Grok : Dissect

Grok était déjà une révolution par rapport à l’utilisation des expressions régulières. Le fait de pouvoir définir des patterns réutilisables rendait les expressions beaucoup plus lisibles.

Logstash va désormais encore plus loin avec le nouveau filtre Dissect, qui permet de définir l’expression en indiquant simplement le nom des variables à récupérer, et en laissant à Dissect le soin de déterminer le pattern correspondant.

Au niveau performance, Dissect offre de meilleurs résultats car il se base sur des séparateurs et non sur des expressions régulières.

ex:

une trace de log :

2017/04/12 - elastic - 1951

L’expression Grok pour récupérer les informations :

%{DATE:date} - %{WORD:name} - %{NUMBER:pid}

L’expression Dissect pour récupérer les informations :

%{date} - %{name} - %{pid}

Lien vers le blog Elastic qui présente le filtre en détails : Logstash Dude, where’s my chainsaw? I need to dissect my logs

Queues persistantes

Par défaut, Logstash stocke les messages à traiter en mémoire. En cas de crash serveur temporaire (process logstash killé par exemple), les messages empilés en mémoire sont perdus. Afin de pallier à ce problème, les queues peuvent désormais être persistées sur disque, afin de ne perdre aucune donnée en cours de traitement. L’impact sur les performances est mineur. Seuls certains inputs sont compatibles, tels que HTTP. Les inputs qui ne fonctionnent pas sur un principe de requête réponse sont exclus, ex : TCP, UDP, ZeroMQ Push+Pull, et bien d’autres.

Autre limitation : ce mécanisme ne protège pas les données en cas de corruption ou crash disque, ou d’indisponibilité permanente de serveur.

Logstash Intermediate Representation (LIR)

Nouvelle représentation interne des pipelines afin de pouvoir les afficher dans Kibana. Pour chaque opération (input, filtre, output) des indicateurs de performance sont présents, afin d’identifier les points de contention. Cette fonctionalité est disponible via x-pack.

Pour le futur : Visual Builder

Un nouvel outil fera son apparition dans une future version de Kibana, afin d’éditer visuellement les pipelines de traitement Logstash.

Kibana 6.0

En dehors du monitoring LIR et du Visual Builder à venir, quelques nouveautés également prévues pour Kibbana :

Nouvelles couleurs

Kibana 5 avait opté pour le rose, Kibana 6 opte pour le bleu marine :

Nouvelles représentations

Deux nouvelles représentations ont été ajoutées : Gauge et Regions map.

• Gauge : une simple jauge permettant de représenter un pourtentage à un instant donné:

• Regions Map : cette représentation permet de faire la correspondance entre les valeurs d’une agrégation et un fichier vectoriel. Exemple présenté dans la documentation officielle :

Export CSV

Une des fonctionalités annoncée est de pouvoir exporter des données au format CSV, y compris pour les données des graphes.

Conclusion

Cette nouvelle version s’annonce pleine de promesses, avec notamment des améliorations de stockage et de performance. La sortie de la version finale est imminente, restez connectés !

Sources

• Breaking Changes in ElasticSearch 6.0
• What’s the Latest in Logstash?
• Space Saving Improvements in Elasticsearch 6.0
• Sequence IDs: Coming Soon to an Elasticsearch Cluster Near You
• Logstash Dude, where’s my chainsaw? I need to dissect my logs
• Logstash Persistent Queues
• Region Maps and Gauges in Kibana
• Writing Logstash Plugins in the 5.X Era