Lancement de la Suite Elastic 6.6.0

La version 6.6.0 est arrivée !

Cette version propose de nouvelles fonctionnalités d'un bout à l'autre de la Suite Elastic. Entre autres nouveautés, elle simplifie la gestion et la montée en charge de votre cluster, accélère l'indexation et la recherche des formes géométriques, booste l'efficacité du stockage et apporte d'importantes améliorations à Elasticsearch SQL, Machine Learning, ou encore Auditbeat.

Déployez un cluster sur Elasticsearch Service ou téléchargez notre Suite et partez à la découverte des nouvelles fonctionnalités.

Gérer le cycle de vie des données à grande échelle grâce à la fonctionnalité de gestion du cycle de vie des index

En général, lorsque votre cas d'utilisation s'appuie sur des séries temporelles, comme c'est le cas pour le logging, les indicateurs et APM, vous stockez vos données dans des index temporels. À mesure que ces données vieillissent, différents moyens vous permettent de veiller à ce que leur stockage soit le plus économique possible. Par exemple, en présence d'un index vieillissant, l'utilisateur peut réduire le nombre de partitions ou de réplicas servant à le stocker, ou le déplacer vers des nœuds déployés sur du matériel moins coûteux. Il peut aussi supprimer les index qui ont dépassé un certain âge. Mais les méthodes existantes qui servent à définir les règles de gestion du cycle de vie des index résident en dehors du cluster (on pense à Curator ou aux scripts d'automatisation personnalisés, par exemple) ; elles sont en outre limitées et entraînent des frais de gestion liés à la configuration et au monitoring. La nouvelle fonctionnalité de gestion du cycle de vie des index vous permet de gérer ces données de manière intégrée et rationalisée, tout en facilitant le respect des bonnes pratiques.

La fonctionnalité de gestion du cycle de vie des index subdivise le cycle de vie en quatre phases : "hot", "warm", "cold" et suppression. Vous pouvez définir une règle relative au cycle de vie des index qui vous permette d'effectuer ce qui suit :

- Disposer d'une partition principale sur chaque nœud hot, afin d'accélérer au maximum l'indexation. - Remplacer l'index hot par un nouvel index vide dès que l'index existant est plein, ou passé un certain délai. - Déplacer l'ancien index vers des nœuds warm, où il n'occupera plus qu'une seule partition, et forcer sa fusion en un seul segment, afin d'optimiser le stockage et la recherche. - Déplacer ensuite l'index vers des nœuds cold pour un stockage plus économique.

Dans une prochaine version, la gestion du cycle de vie des index sera compatible avec la fonctionnalité de gel des index. Autrement dit, la règle vous permettra de faire passer un index de l'état ouvert à l'état "gelé", troquant ainsi une moindre densité de stockage contre une meilleure latence de recherche. Enfin, vous pourrez supprimer l'index une fois que vous n'en aurez plus besoin.

Et grâce à la fonctionnalité de gestion du cycle de vie des index, tout cela fait l'objet d'un traitement automatique.

De meilleurs ratios stockage/mémoire grâce aux index gelés

Hautement optimisé à cette fin, Elasticsearch est synonyme de recherches extrêmement rapides et efficaces. Historiquement, chaque index ouvert (autrement dit, avec possibilité de recherche) utilisait une petite quantité de mémoire pour assurer la rapidité d'exécution de n'importe quelle requête qu'il recevait. Or, plus les index d'un nœud donné sont nombreux et volumineux, plus le maintien de cet état ouvert nécessite de mémoire. Concrètement, cela signifie qu'il existe des limites pratiques à la quantité de stockage que peut traiter un nœud donné avec une seule machine virtuelle Java (JVM). Pour la majorité des utilisateurs et des cas d'utilisation, cela ne constitue pas un problème. Mais dans certains cas (par exemple, quand il s'agit d'archiver à long terme plusieurs années de données pour des raisons réglementaires), les données doivent être conservées en ligne et pouvoir faire l'objet de recherches, sans pour autant nécessiter de performances maximales lorsqu'il s'agit d'interroger des données anciennes.

Les index gelés permettent d'obtenir un ratio stockage sur disque/mémoire bien plus élevé, au détriment de la latence de recherche. Lorsqu'un index est gelé, il n'utilise aucun segment de mémoire. Un seul nœud peut ainsi facilement gérer des milliers d'index de manière très économique. Et quand une recherche cible des index gelés, cela entraîne séquentiellement l'ouverture complète de chaque index, le lancement d'une recherche sur ce dernier, puis sa fermeture. Contrairement aux index fermés, les index gelés sont répliqués. Ils vous offrent de nouvelles possibilités d'optimisation des coûts et des performances de votre cluster en fonction de vos besoins.

Formes géométriques basées sur l'arborescence Bkd : gain d'espace et de performances

La structure de données basée sur l'arborescence Bkd continue de tenir ses promesses. Dans la version 5.0, nous vous avions présenté les points géographiques ("geo_points") basés sur l'arborescence Bkd. Ceux-ci s'étaient traduits par des améliorations considérables du stockage, de la mémoire et des performances liés à la recherche des points géographiques. Avec la version 6.6.0, c'est au tour des formes géométriques de bénéficier des avantages de l'arborescence Bkd. Et c'est un triplé gagnant pour la recherche : accélération de l'indexation, gain d'espace disque et moindre consommation de mémoire.

Elasticsearch SQL accepte les histogrammes de date

Elasticsearch SQL continue d'avancer vers la disponibilité générale, avec une pléthore d'améliorations axées sur les requêtes temporelles, comme la prise en charge native des histogrammes de date utilisant la syntaxe SQL. Si ces améliorations sont une excellente nouvelle pour l'ensemble des utilisateurs d'Elasticsearch SQL, nous pensons que la prise en charge des histogrammes de date sera particulièrement utile aux utilisateurs de Canvas, à qui elle facilite la création de graphiques temporels dans Kibana.

Les annotations font leur entrée dans Machine Learning

Lorsque vous examinez un problème système ou un problème de sécurité potentiel, vous avez tout naturellement besoin d'enregistrer votre progression et vos résultats (enregistrement de la cause profonde d'un problème système et actions entreprises pour le résoudre, par exemple). Vous pouvez désormais créer des annotations visibles de tous les utilisateurs, directement dans l'IU de Machine Learning. La collaboration s'en trouve facilitée, et vous gardez trace des actions entreprises sans quitter Kibana.

Elastic APM s'enrichit de nouveaux indicateurs pour les agents

Autre nouveauté de la version 6.6, APM propose de nouveaux indicateurs pour les agents. La toute dernière version de nos agents génère automatiquement des indicateurs relatifs au processeur et à la mémoire, tant au niveau du système que des processus. À cela s'ajoutent aussi des indicateurs de trace et d'erreur.

Toujours au rayon des nouveautés, le traçage distribué est maintenant disponible et tous les agents sont compatibles OpenTracing. Enfin, l'interface utilisateur d'APM vous permet de passer facilement aux vues Logging ou Infrastructure, et l'agent Java vous réserve deux nouvelles fonctionnalités très attendues. Pour tout savoir sur le sujet, n'hésitez pas à consulter cet article de blog dédié à APM.

Et comme nous adorons les bonnes nouvelles, continuons sur notre lancée : nous sommes ravis de vous annoncer qu'Elastic APM est désormais disponible au déploiement sur Elasticsearch Service (voir ce blog) et sur Elastic Cloud Enterprise (voir ce blog).

Et ce n'est pas tout

Comme toutes ces nouveautés ne nous suffisaient pas, nous avons aussi apporté quelques améliorations et ajouté quelques fonctionnalités à Beats, Logstash et Kibana.

Ainsi, Auditbeat intègre un nouveau module système permettant la collecte de différentes informations de sécurité depuis le système : données relatives au système d'exploitation, aux sockets et aux utilisateurs d'un hôte donné, par exemple. Pour en savoir plus sur le module système Auditbeat, consultez l'article de blog que nous lui avons consacré.

Machine Learning intègre maintenant des tâches de machine learning prépackagées pour les données Auditbeat, permettant ainsi aux utilisateurs qui se lancent de détecter rapidement des anomalies courantes dans leurs données d'audit.

Filebeat, quant à lui, propose une nouvelle entrée NetFlow, qui permet de recevoir les enregistrements Netflow et IPFIX via UDP. Il prend en charge NetFlow v1, v5, v6, v7, v8, v9 et IPFIX.

Avec la gestion centralisée de Beats, vous pouvez maintenant configurer Metricbeat et Filebeat pour qu'ils refusent les modifications apportées à certaines parties de leur configuration. Cela permet de veiller, au niveau de l'agent Beat exécuté, au bon respect de ce qui peut ou non être modifié par la configuration distante. Et pour une exécution encore plus sécurisée, nous bloquons maintenant par défaut les modifications susceptibles d'être apportées aux sections relatives à la sortie de la console et à la sortie Fichier.

Du nouveau aussi du côté de Logstash : d'abord proposé en bêta avec la version 6.1, notre moteur d'exécution Java ultraperformant est maintenant disponible.

Kibana n'est pas non plus en reste. Nous l'avons enrichi d'une fonctionnalité très demandée : une seule instance Kibana peut maintenant disposer de plusieurs nœuds Elasticsearch. Exit, les difficultés liées au point de défaillance unique sur la connexion Kibana <> Elasticsearch. Au chapitre Visualisation, les tableaux de bord Kibana peuvent maintenant être exportés au format PNG. Pour un tour d'horizon des nouveautés de Kibana, vous pouvez consulter cette page, qui fait le point sur Kibana 6.6.

Lancez-vous

Déployez un cluster sur Elasticsearch Service ou téléchargez notre Suite et partez à la découverte des nouvelles fonctionnalités.