Le 9 novembre 2016, l’Elastic{ON} était de passage à Paris. Tout juste deux semaines après la sortie officielle d’Elasticsearch 5, c’était l’occasion pour nous d’en apprendre plus sur les dernières évolutions de la stack Elastic. Voici un retour sur cette journée de conférences.

Conférences de la société Elastic

Les six conférences de la matinée ont été assurées par l’entreprise Elastic. Avec la nouvelle version sur les rails, les conférences se sont principalement concentrées sur les nouveautés.

De ELK à la stack Elastic

Pour ouvrir cet événement, c’est Shay Banon qui est monté sur scène. Il s’agit du créateur d’Elasticsearch et il occupe aujourd’hui la place de co-fondateur et CTO de l’entreprise Elastic. Il nous a présenté les évolutions qui ont permis à ELK (Elasticsearch/Logstash/Kibana) de devenir la stack Elastic que l’on a aujourd’hui.

Cette présentation montre la diversification des usages proposés aujourd’hui par Elastic, qui propose maintenant outre ElasticSearch (le backend), Logstash (l’ETL) et Kibana (l’interface de datamining) de nouveaux produits comme Beats (version plus légère et plus spécialisée de Logstash) et le pack payant X-Pack, qui fournit des outils de sécurité (anciennement Shield), d’alerting (Watcher), de monitoring (anciennement Marvel), de reporting ou de recherche par graphes.

Elasticsearch 5 - Les nouveautés

C’est ensuite Adrien Grand qui prend la parole. Il est ingénieur chez Elastic et travaille sur les évolutions d’Elasticsearch. Pour débuter, il rappelle que la stack évolue mais qu’Elasticsearch reste le cœur de l’entreprise. Tous les autres services s’articulent autour de ce dernier. Les trois axes régulants les évolutions d’Elasticsearch restent : la simplicité d’utilisation, la vitesse et la scalabilité.

Elastcisearch

Adrien a ensuite enchainé sur quelques une des nouveautés :

  • Nouveau format d’indexation pour les nombres :
    • C’est une structure de type BKD tree qui est maintenant utilisée, au lieu de l’ancien fonctionnement “bricolé” autour des index textuels Lucene.
    • Plus de rapidité, moins de charge sur le disque dur et une utilisation moindre de la RAM.
    • Cela permet d’indexer de nouveau format plus facilement (ex : des IP V6).
    • Deux nouveaux formats pour le mapping : Half float et Scaled float qui permettent d’économiser de l’espace disque (Plus d’informations sur le mapping).
  • De meilleures performances lors de l’indexation permettant de gagner du temps.
  • Fiabilisation et mise en open source du projet Rally. Il s’agit de l’outil de benchmark utilisé pour assurer les évolutions introduites dans Elasticsearch 5 (Voir le projet).
  • Nouveau langage de script : Painless
    • Dans l’idée de remplacer Groovy (qui est toujours là pour le moment). Les problèmes de ce dernier :
      • L’exécution dans des sandbox pouvaient introduire des bugs.
      • Il était nécessaire d’introduire un langage embarqué.
    • Les avantages du nouveau langage :
      • Plus sécurisé
      • Plus rapide
      • Il reste familier (La syntaxe est proche du Groovy)
    • Il est devenu le langage par défaut pour l’exécution des scripts.
  • Rollover API
    • Simplifier la création des index temporels.
    • On définit des contraintes (ex : de temps et/ou de nombre de documents dans l’index).
    • Lorsque la limite est atteinte, en automatique, l’index est archivé et un nouveau est créé pour prendre sa place.
  • Shrink API
    • Permet de diminuer facilement le nombre de shards pour les index à archiver.
  • Paramètre “refresh=wait_for”
    • Avec ce paramètre, l’API d’indexation ne nous rend la main qu’une fois les documents indexés et disponibles à la recherche au lieu de rendre la main immédiatement. Cela permet de garantir que dans un même processus, une donnée indexée est réellement disponible immédiadement ensuite.
  • Ingest Node
    • Permet d’enrichir les documents lors de la phase d’indexation.
    • Il y a eu une conférence dédiée par la suite.
  • Résilience et sécurité
    • Elasticsearch procède à une vérification des options lors de son démarrage pour prévenir les mauvaises surprises une fois la production branchée dessus.
    • Si la configuration est mauvaise, Elasticsearch refuse tout simplement de démarrer.
    • Il est possible en environnement de développement, d’outrepasser cette vérification.
  • Circuit breaker
    • Permet de détecter, en amont, l’explosion de la mémoire dans la JVM.
  • Cluster state
    • La mise à jour de l’état du cluster est maintenant plus fiable grâce à un commit en plusieurs phases. Cela garantit une meilleur stabilité du cluster lors de l’ajout ou du retrait de nœuds, du changement de paramètres, etc.
  • Amélioration de l’aspect distribué d’Elasticsearch.
  • Completion Suggester Version 2
    • Cette nouvelle version gère la suppression de document pour ne pas les prendre en compte dans les suggestions.
  • Percolator
    • Les requêtes enregistrées sont maintenant indexées pour n’exécuter que celles qui semblent pertinentes lors de la soumission d’un document.
  • Instant Aggregations
    • Lorsqu’on utilise des index découpés temporellement (par exemple un index par jour) et qu’on effectue des requêtes utilisant le mot-clé “now”, ElasticSearch est maintenant capable d’optimiser ces requêtes pour n’interroger que les index concernés par la plage de date demandée et surtout, est capable de mettre en cache les résultats de manière intelligente. Cela rend les recherches et aggrégations de ce type beaucoup plus rapides.
  • Profile API
    • Le profiling des requêtes est plus détaillé.

La présentation se termine sur les évolutions prévues. On peut retenir parmi celles-ci, que la nouvelle structure des données numériques devrait permettre d’indexer directement des plages et de pouvoir chercher dessus (ex : Indexer des horaires d’ouvertures et chercher directement qui est ouvert à un moment donné).

Kibana 5 - La fenêtre de la stack Elastic

Kibana

Tout comme la première conférence, celle-ci a débutée avec un petit historique de Kibana. Elle a été assurée par Christian Zumbiehl (consultant chez Elastic). Il a ensuite enchainé sur quelques démonstrations (Timelion, discorver, etc). Parmis les nouveautés :

  • L’interface graphique a été revu pour un meilleur découpage en rubrique des différentes fonctionnalités. Elle se veut également plus moderne et lisible que la précédente.
  • X-Pack fonctionne sous forme de plugin à Kibana en rajoutant de nouvelles rubriques ou en enrichissant les existantes.

Ingestion dans Elasticsearch 5 - Beats et Logstash

C’est au tour de David Pilato de nous présenter l’ingestion dans Elasticsearch mais également les évolutions de Beats et Logstash. La présentation débute avec un rappel sur l’intérêt de Beats en le différenciant de Logstash. En résumé, Logstash est lourd alors que Beats est plus léger mais comporte moins de fonctionnalités. Il est donc courant d’utiliser Beats pour envoyer dans un Logstash qui enverra lui-même, après traitement, les données dans Elasticsearch.

C’est efficace mais on est face à une structure un peu lourde à gérer dans des cas simples (comme l’envoi d’une ligne de log que l’on veut juste normaliser). L’idée derrière l’ingestion, c’est de déporter une version allégée des fonctionnalités de Logstash dans Elasticsearch. On va donc avoir Filebeats qui enverra directement à Elasticsearch les données et le processus d’ingestion va le normaliser.

Beats

David mentionne ensuite les nouveautés de Beats 5.0 :

  • Mise en place de processeurs
    • Permet par exemple de filtrer pour limiter les envois
    • On aura ainsi l’envoi de logs HTTP qui seront filtrés pour éviter de communiquer les requêtes avec un code 200.
  • Mise en place de Packetbeat
    • Permet de surveiller les activités réseau.
  • Une sortie directe pour Kafka.
  • Mise en place de Metricbeat
    • Permet de collecter des informations sur le système courant (CPU, mémoire, etc).
    • A la base, c’était un projet de démo de plugin pour Beats (Topbeat) mais la communauté en a décidé autrement ;).
  • Des graphs pré-faits sont proposés pour Kibana.

Logstash

Côté Logstash, pour les évolutions, David a mentionné :

  • Une amélioration des performances (jusqu’à 20% de gain).
  • Ajout de nouveaux plugins.
  • Ajout du support de Kafka.
  • Mise en place d’un plugin qui permet de générer des templates.

Au passage, David mentionne que l’API scroll, qui avant n’était que séquentielle, peut maintenant lire des groupes de résultats en parallèle grâce à l’option slice.

Cette conférence met ensuite le cap vers le futur.

  • Beats :
    • Du côté de Metricbeat, de nouvelles métriques seront récupérables.
    • De nouveaux plugins en préparation.
    • Proposer des packs tout faits pour les cas les plus communs (par exemple, proposer directement la config de Beats + Kibana pour surveiller des logs Apache).
    • Intégrer dans le monitoring de Kibana le statut de Beats.
    • Centraliser la configuration de Beats dans Elasticsearch pour faciliter la propagation des configurations.
  • Logstash :
    • Validation des messages dans le but d’éviter les pertes dans un cas de plantage de Logstash. Les messages seront persistés sur disque dur.
    • Intégrer dans le monitoring de Kibana le statut de Logstash.
    • Centraliser la configuration de Logstash dans Elasticsearch pour faciliter la propagation des configurations.
    • Gérer plusieurs pipelines dans une seule JVM en conservant le projet maintenable. Actuellement, il faut soit démarrer plusieurs instances de Logstash pour gérer cela ou rajouter une flopée de conditions.
    • Event routing : Permet de choisir quoi faire avec les événements en entrée.

Démonstrations

De l’ingestion à l’analyse

Pour faire suite à sa propre présentation le matin même, David reprend la main pour faire une démonstration d’un cas un peu plus concret utilisant les différents outils vus dans la journée. Il a ainsi mis en place un système permettant de détecter les tentatives d’intrusion via des attaques par force brute et qui permet d’alerter si une tentative est détectée.

On a ainsi pu voir une nouveauté dans Elasticsearch : il est possible de générer des alias dynamiques avec de simples formules mathématiques. Par exemple : je veux chercher dans les indexes de log entre aujourd’hui et il y a 3 jours. Sans créer d’alias, il est ainsi possible de chercher sur une liste d’index de façon dynamique.

En conclusion

Les sujets étaient assez variés et la sortie de la nouvelle version de la stack Elastic (2 semaines plus tôt) coïncidait parfaitement pour cette journée. D’autres sujets ont été abordés durant la journée (Prelert, X-Pack, des retours d’expériences) mais ils ne sont pas retranscrits ici car cela s’éloigne de notre cœur de métier.

Comme points positifs, on peut noter de bonnes présentations sur les nouveautés et le futur des projets. Il y en avait pour tous les profils (Elasticsearch pour les développeurs, Kibana pour ceux qui adorent les graphes, etc). Les démonstrations/formations en fin de journée sur des cas concrets permettent de mieux situer l’utilisation des éléments présentés le matin et donnent également des idées sur les intégrations possibles dans nos propres projets.

Du côté des aspects négatifs de la journée, il a été assez navrant de constater que certains intervenants n’ont pas (ou pas assez) préparé leur présentation et n’ont pas non plus écouté les présentations précédentes. Nous avons eu le droit à des explications en double qui ont été données 20 minutes auparavant ou bien à des moments “découverte de ma démonstration/j’ai besoin d’aide pour comprendre ce que j’explique” un peu génants.

Les logos présents sur cet article sont issus du site d’Elastic.

Commentaires