Dans ce blog, nous allons explorer l'expérience du développeur de l'éditeur ES|QL dans Elasticsearch 9.1 en le comparant à PPL dans l'analyseur d'événements (PPL en abrégé) dans OpenSearch 3.2.

Les différences apparaissent rapidement : l'éditeur ES|QL offre une autocomplétion intelligente, une aide contextuelle, des requêtes recommandées et une prise en charge des requêtes entre clusters qui permettent aux utilisateurs débutants, mais aussi aux utilisateurs experts, d'être plus autonomes. La conception réfléchie de la rédaction ES|QL est également visible dans l'inspection intégrée des requêtes et l'intégration holistique par le biais des flux de travail Kibana, par exemple, avec les requêtes récentes.

En revanche, PPL n'offre pas de support comparable pour l'autocomplétion, l'orientation contextuelle et les requêtes distribuées, ce qui entraîne une courbe d'apprentissage plus raide et davantage d'essais et d'erreurs.

Faciliter l'apprentissage et l'utilisation d'ES|QL

Se lancer dans l'utilisation d'un nouveau langage d'interrogation peut souvent sembler insurmontable. L'éditeur ES|QL, intégré directement à Kibana Discover, est conçu pour faciliter ce processus en prenant en charge non seulement la création et le débogage des requêtes, mais aussi en accélérant la vitesse à laquelle vous vous familiarisez et vous vous sentez à l'aise avec le langage. Comme l'éditeur aide à réduire les frictions dans les tâches quotidiennes, vous pouvez vous concentrer sur la recherche de solutions plutôt que sur la syntaxe et les essais-erreurs. Pour en savoir plus sur ces principes et sur la manière dont nous les avons intégrés dans l'éditeur , cliquez ici.

Cette expérience d'éditeur n'est pas limitée à Discover ; il s'agit d'un module de code réutilisable que nous travaillons à intégrer dans d'autres parties de Kibana, telles que les tableaux de bord, les alertes Kibana et les cartes Kibana.

Autocomplétion intelligente : accélérer la création de requêtes

L'autocomplétion de l'éditeur ES|QL est complète, offrant des suggestions de fonctions compatibles, d'arguments, de littéraux et même de fonctions imbriquées, une capacité qui fait notablement défaut dans PPL. En fait, il a été reconstruit de fond en comble, comme indiqué ici.

La validation s'exécute au fur et à mesure que l'utilisateur tape, comme indiqué ici, et suggère des champs tout en notifiant l'utilisateur en cas d'erreur. Cela réduit la charge mentale des utilisateurs et permet d'éviter les erreurs dès le début du processus de création de la requête.

Exemple : Des champs et des fonctions compatibles sont proposés dans cette imbrication :

Ce que la PPL ne soutient pas :

Même si l'autocomplétion intelligente vous guide à travers les fonctions compatibles, les arguments et les fonctions imbriquées, il se peut que vous souhaitiez mieux comprendre les options disponibles. C'est précisément là que l'aide contextuelle de l'éditeur ES|QL devient inestimable, offrant une assistance immédiate, au sein de l'éditeur, pour clarifier et améliorer le développement de votre requête.

Une aide contextuelle au bout des doigts

Il suffit d'un clic Ctrl-Espace pour obtenir des informations supplémentaires sur une commande générée par la saisie semi-automatique. Un panneau apparaît immédiatement avec des détails sur la fonction, l'argument ou le champ en question. Cette interaction légère permet aux développeurs de rester dans le flux, en leur fournissant des conseils juste à temps sans les obliger à quitter l'éditeur ou à rechercher de la documentation externe. Cela permet de réduire le temps perdu en recherches syntaxiques et d'éviter les erreurs courantes avant qu'elles ne se produisent.

Voici ce que cela donne en pratique :

PPL ne dispose pas de ce niveau d'orientation intégrée, ce qui oblige les utilisateurs à s'appuyer sur des documents externes ou à procéder par tâtonnements. Cette absence n'est pas seulement une caractéristique manquante ; elle met en évidence une disparité plus large dans la philosophie de conception. ES|QL donne la priorité à une expérience réfléchie et contextuelle qui s'adapte aux données et au flux de travail de l'utilisateur. Cette différence s'accentue au fur et à mesure que les requêtes deviennent plus complexes, ce qui fait de l'Éditeur ES|QL un environnement plus efficace et plus fiable, tant pour l'apprentissage que pour la production.

Requêtes recommandées qui tiennent compte du contexte des données

L'éditeur ES|QL propose des requêtes recommandées qui sont automatiquement adaptées aux données avec lesquelles vous travaillez, telles que les journaux. Au lieu de présenter un éditeur vierge, il fait apparaître les points de départ les plus pertinents pour les cas d'utilisation courants. La sélection d'une requête recommandée génère une requête canonique qui est immédiatement utilisable et peut être affinée si nécessaire. Cette approche accélère le développement des requêtes, en particulier pour les nouveaux utilisateurs qui ne connaissent pas encore toute la syntaxe.

Voici un exemple où un utilisateur sélectionne la requête "Détecter le point de changement" :

Comparez cela à l'expérience PPL :

En revanche, PPL n'offre qu'une autocomplétion de base, ce qui vous laisse le soin d'élaborer des requêtes sans contexte ni structure. Ce manque d'orientation peut conduire à la frustration et au tâtonnement. Grâce aux requêtes recommandées de l'éditeur ES|QL qui tiennent compte des données, vous pouvez éviter de partir de zéro ou de mémoriser la syntaxe pour les tâches de routine. L'éditeur réduit la charge cognitive, aide à prévenir les erreurs et vous permet de vous concentrer sur la résolution de problèmes et sur des objectifs plus larges, tels que l'exécution de recherches entre clusters, plutôt que de vous débattre avec la construction d'une requête.

Interrogation intuitive de l'ensemble des clusters

L'autocomplétion de l'éditeur ES|QL reste supérieure, même lorsque l'on travaille avec plusieurs clusters distants avec CCS. Voici pourquoi :

L'éditeur ES|QL offre une autocomplétion transparente, même à travers les clusters

L'autocomplétion dans l'éditeur ES|QL prend en charge non seulement les noms des clusters, mais aussi les index locaux et distants. Comme indiqué ici, cela fonctionne grâce à l'architecture d'un nœud coordinateur, qui aide à valider et à générer le plan d'interrogation à envoyer aux nœuds locaux, à exécuter l'interrogation et à agréger les résultats avant de les renvoyer à l'utilisateur. Sans saisir le nom complet du cluster distant, la saisie de " :" lance le processus d'autocomplétion pour l'index distant. Et vous n'êtes pas limité au préfixe.

Il est ainsi facile de découvrir et d'interroger des ensembles de données distribués sans avoir à mémoriser des conventions de dénomination ou à changer de contexte.

Voici un exemple où l'utilisateur tape simplement "clu:g" pour localiser un index distant :

En revanche, la PPL ne fournit qu'une complétion de base pour les index locaux, avec des suggestions limitées aux correspondances de préfixes. Les clusters distants doivent être saisis manuellement, ce qui augmente la probabilité d'erreurs et ralentit la création de requêtes.

PPL ne fournit une complétion que pour les index locaux et les suggestions sont limitées au préfixe :

ES|QL va plus loin en autorisant les exclusions directement à l'aide d'un signe négatif, ce qui vous permet de contrôler finement les grappes qui participent à votre exploration. Cette fonction est particulièrement utile lorsque vous travaillez avec des environnements hybrides, où vous pouvez vouloir inclure ou omettre des ensembles de données spécifiques lors d'investigations entre clusters.

Ces améliorations reflètent l'accent mis par Elasticsearch sur la réduction des frictions dans la recherche cross-cluster. En facilitant la construction et la gestion des requêtes distribuées, ES|QL Editor permet aux analystes et aux développeurs de se concentrer sur les idées plutôt que sur la syntaxe, alors que PPL laisse une plus grande part de ce fardeau à l'utilisateur. De même que l'éditeur ES|QL simplifie la création de requêtes inter-clusters, il fournit également des outils permettant d'inspecter l'exécution de ces requêtes, garantissant ainsi la transparence et le contrôle des performances sur plusieurs clusters.

Utilisation de l'outil Inspect pour analyser les détails de la recherche transversale

L'outil Inspect, accessible à partir de l'éditeur ES|QL, est conçu pour fournir des métadonnées contenant des informations explicites sur l'exécution de la requête dans tous les clusters. Cette fonctionnalité est activée dans Kibana Discover et est accessible directement dans l'inspecteur de requête, ce qui vous permet d'analyser la progression et les détails de la recherche, ce qui est particulièrement crucial pour la recherche cross-cluster (CCS). Cette fonctionnalité vous permet de suivre l'évolution de la recherche et de comprendre comment les requêtes se déroulent dans des ensembles de données distribués.

Cette visibilité détaillée de l'exécution des requêtes, en particulier pour les recherches distribuées complexes, vous permet de garantir des performances et un dépannage optimaux.

Au-delà de la compréhension des mécanismes des requêtes individuelles, ES|QL Editor améliore encore le parcours de l'utilisateur en intégrant des fonctionnalités essentielles dans l'ensemble de la plateforme Kibana, favorisant ainsi un flux de travail transparent et ininterrompu.

Expérience des requêtes unifiées avec ES|QL et Kibana

Le changement de contexte est l'une des sources de friction les plus courantes dans l'analyse pilotée par les requêtes. Vous devez souvent vous rappeler des requêtes que vous avez déjà écrites. Chaque interruption déconcentre et ralentit les investigations. L'éditeur ES|QL y remédie en intégrant l'historique des requêtes dans Kibana.

Requêtes récentes

La fonction Requêtes récentes de l'éditeur ES|QL vous aide à rester dans le flux en rendant les travaux antérieurs instantanément accessibles. Dans l'éditeur ES|QL de Discover, vous pouvez afficher, réexécuter et enregistrer vos 20 dernières requêtes, de sorte que les requêtes complexes ou fréquemment utilisées ne sont qu'à un clic de souris. Ces requêtes enregistrées se retrouvent également dans Kibana et s'intègrent aux tableaux de bord, aux visualisations, aux alertes et aux cartes, de sorte que vous n'avez pas besoin de quitter votre écran actuel ou de retaper des commandes à partir de zéro. Cela permet de réduire le travail répétitif, d'accélérer les enquêtes et de minimiser le risque d'erreurs.

Par exemple, un utilisateur peut utiliser les requêtes récentes dans l'éditeur ES|QL dans Discover (et les mettre en vedette) :

Les requêtes récentes sont intégrées dans le tableau de bord :

PPL n'offre pas de possibilité comparable, ce qui oblige les utilisateurs à recourir au copier-coller manuel ou à des notes externes pour réutiliser les requêtes. La différence est plus qu'une question de commodité ; elle reflète la stratégie d'Elastic qui consiste à faire d'ES|QL un langage véritablement intégré à l'écosystème Kibana. Avec des fonctionnalités telles que les requêtes récentes, l'éditeur ES|QL ne se contente pas de rationaliser les flux de travail quotidiens, il pose également les bases de fonctionnalités plus avancées, actuellement en phase de prévisualisation technique, ce qui garantit une évolution constante de l'expérience.

Conclusion

ES|QL est plus qu'une syntaxe ; elle reflète la stratégie d'Elastic visant à améliorer la façon dont les utilisateurs recherchent, explorent et analysent les données. Grâce à une autocomplétion intelligente, à des requêtes recommandées en fonction du contexte, à des conseils intégrés à l'éditeur et à des outils comme Inspect, l'éditeur ES|QL accélère l'apprentissage, réduit les erreurs et simplifie les flux de travail complexes tels que l'analyse croisée des clusters. Intégré à Kibana, il relie de manière transparente les requêtes aux tableaux de bord, aux alertes et aux visualisations pour un flux de travail ininterrompu.

En résumé, ES|QL n'est pas simplement un autre langage pipé ; il s'agit d'un moteur de requêtes bien pensé associé à une interface utilisateur intuitive qui redéfinit fondamentalement la façon dont vous interagissez avec vos données, en offrant une expérience intégrée, intelligente et en constante évolution qui contraste fortement avec la nature souvent séquentielle et moins guidée d'OpenSearch PPL.

Prochaines étapes

Ce blog ne fait qu'effleurer la surface d'ES|QL. Les prochains articles approfondiront les comparaisons avec OpenSearch PPL et exploreront les fonctionnalités géospatiales, de visualisation et les futures fonctionnalités de l'éditeur telles que les contrôles (déjà disponibles dans les tableaux de bord), les onglets d'exploration multi-données, la recherche en arrière-plan, l'historique des requêtes plus riche et FUSE.

Essayez ES|QL dès aujourd'hui

Vous pouvez tester ES|QL dans des projets Serverless Elasticsearch entièrement gérés avec un essai gratuit. Il est également disponible dans les versions à partir de la 8.11, mais c'est dans les versions 8.19 et 9.1 qu'il est le plus utile.

Démarrez en quelques minutes sur votre environnement local à l'aide d'une simple commande :

Aujourd'hui, nous annonçons la disponibilité générale du nouveau mode d'indexation d'Elasticsearch, logsdb, qui réduit l'empreinte de stockage des données de log jusqu'à 65% par rapport aux versions récentes d'Elasticsearch sans logsdb. Cette amélioration spectaculaire permet aux équipes chargées de l'observabilité et de la sécurité d'accroître la visibilité sans dépasser leur budget, tout en conservant l'accès immédiat à toutes les données à des fins d'analyse.

Logsdb optimise l'ordre des données, élimine les doublons en reconstruisant à la volée les valeurs des champs non stockés grâce à la fonctionnalité synthetic _source et améliore la compression au moyen d'algorithmes et codecs avancés, tout en utilisant le stockage en colonnes dans Elasticsearch pour un stockage et une récupération efficaces des logs.

Améliorez les analyses et réduisez les coûts en améliorant l'efficacité du stockage avec le mode d'indexation logsdb

Les logs fournissent des signaux critiques pour détecter et résoudre les problèmes d'observabilité et de sécurité, et leur utilité ne fait que croître à mesure que les avancées de l'IA facilitent l'analyse des données textuelles. Un stockage efficace et un accès performant sont donc plus importants que jamais.

Malheureusement, le volume croissant de logs généré par l'infrastructure et les applications augmente les coûts, contraignant les entreprises à faire des compromis qui entravent l'analyse : limiter la collecte, réduire la conservation ou reléguer les données récentes à des niveaux d'archivage cloisonnés.

Logsdb répond directement à ces défis. Grâce à une meilleure efficacité de stockage, vous pouvez collecter davantage de données et éviter les tracas liés à un filtrage des données compliqué. Vous pouvez conserver les logs plus longtemps pour favoriser la détection des menaces, la réponse aux incidents et la conformité. Et parce que toutes les données sont toujours consultables, vous pouvez obtenir rapidement des informations, quelle que soit la taille de votre ensemble de données.

Innovation technique associée au mode d'indexation logsdb

Le mode d'indexation Logsdb réduit considérablement l'empreinte de stockage des données de log grâce à un index trié intelligent, synthetic _source et une compression avancée. La mise en œuvre de cette solution peut réduire les besoins en stockage des logs jusqu'à 65 %, par rapport aux versions récentes d'Elasticsearch sans logsdb. Bien que logsdb utilise actuellement plus de processeur lors de l'indexation, son stockage efficace réduit les coûts globaux pour la majorité des clients. Pour les clients qui nécessitent une conservation à long terme, nous anticipons des réductions du coût total de possession pouvant atteindre 50 %.

Le tri intelligent des index améliore l'efficacité du stockage jusqu'à 30% et réduit la latence des requêtes sur certains ensembles de données de journalisation en localisant les données similaires à proximité les unes des autres. Par défaut, il trie les indices par host.name et @timestamp. Si vos données comportent des champs plus appropriés, vous pouvez les spécifier à la place.

La compression avancée réduit considérablement les besoins en stockage pour les données à forte teneur en texte, comme les journaux, grâce à la compression Zstandard (Zstd), à l'encodage delta, à l'encodage run-length et à d'autres codecs intelligents qui sont automatiquement sélectionnés. Les valeurs-documents, qui sont stockées dans un format en colonnes optimisé pour la compression et les performances, permettent de stocker et d'extraire efficacement les valeurs des champs pour le tri, l'agrégation et l'écriture de scripts.

La _source synthétique permet aux entreprises de réduire leurs besoins en stockage de 20 à 40% supplémentaires en supprimant le champ _source et en le reconstruisant entièrement ou partiellement à la demande. Bien que cette fonction nécessite parfois davantage de calculs pour l'indexation et la recherche, les tests montrent qu'elle apporte des améliorations nettes mesurables en termes d'efficacité. Synthetic _source s'appuie sur près de deux ans d'utilisation en production avec les métriques, avec de nombreuses améliorations pour les journaux, y compris la prise en charge de presque tous les types de champs.

Les économies de stockage résultantes sont répercutées à travers les différentes phases du cycle de vie des index. Une réduction du stockage de 65 % dans le niveau hot entraînera la même réduction dans les niveaux warm, cold et frozen, ainsi qu'une baisse de l'empreinte de stockage des snapshots avec un stockage en buckets.

Aucun compromis sur la visibilité : conservez tous vos logs pour l'observabilité et la sécurité

Les logs sont essentiels pour garantir la visibilité sur l'infrastructure et les applications. Ils fournissent le signal le plus simple et le plus critique pour le suivi et le dépannage. Cependant, les coûts augmentent proportionnellement aux volumes de logging. Cela contraint les clients à mettre en œuvre des politiques de filtrage et de gestion complexes, à supprimer des données prématurément et à reléguer les logs pertinents dans des magasins qui nécessitent un jour ou plus pour être réhydratés avant leur analyse. Sans un ensemble de données complet, facilement interrogeable et accessible, il est beaucoup plus difficile d'identifier et de résoudre les problèmes.

Le mode index de Logsdb s'appuie sur les fonctionnalités révolutionnaires d'Elasticsearch, telles que les instantanés consultables et l'importation automatique, pour résoudre ces problèmes pour les équipes chargées des opérations et de la sécurité :

Réduire les coûts : Logsdb réduit l'empreinte de stockage des journaux jusqu'à 65%, ce qui permet aux entreprises de réduire leurs dépenses de stockage tout en conservant davantage de données. Cela se traduit par des économies sur tous les niveaux de stockage - de l'état chaud à l'état gelé - et par une productivité accrue pour les équipes chargées de l'observabilité et de la sécurité qui utilisent ces données.

Préservez vos données précieuses : Logsdb conserve toutes les données de vos journaux et améliore l'efficacité opérationnelle sans avoir recours à des outils supplémentaires ou à des filtres compliqués. Grâce à des fonctionnalités telles que la _source synthétique, la valeur des données est préservée sans que l'intégralité du document source ne soit stockée.

Élargir la visibilité : Logsdb offre un accès efficace à toutes les données sur une seule plateforme, sans silos séparés pour l'observabilité, la sécurité et les données historiques. Pour les ingénieurs de fiabilité des sites (SRE), il accélère la résolution des problèmes en permettant l'analyse des journaux avec les métriques, les traces et les données commerciales. De même, pour les équipes des centres d'opérations de sécurité (SOC), il accélère les enquêtes et les mesures correctives en éliminant les angles morts.

Rationaliser l'accès aux données : Logsdb permet aux équipes SRE de conserver efficacement les données exploitables pour le dépannage, les tendances et l'analyse. De même, les équipes SOC peuvent rapidement rechercher toutes leurs données à des fins d'investigation et de chasse aux menaces sans encourir de coûts exorbitants.

Logsdb est prêt pour votre environnement

Le mode d'indexation Elasticsearch logsdb est généralement disponible pour les clients Elastic Cloud Hosted et Self-Managed à partir de la version 8.17 et est activé par défaut pour les logs dans Elastic Cloud Serverless.

Les fonctionnalités de base de logsdb (y compris l'index trié intelligent et la compression avancée) sont disponibles pour les entreprises disposant de licences Standard, Or et Platinum. Les capacités complètes de logsdb, qui réduisent encore les besoins en stockage (y compris synthetic _source), sont disponibles pour les clients Serverless et les entreprises avec une licence Entreprise.

Elasticsearch logsdb en action

Logsdb vous permet de conserver toutes vos données de logs et d'améliorer l'efficacité opérationnelle sans restreindre la collecte ni supprimer ou cloisonner vos données. Avec des fonctionnalités telles que l'index trié intelligent, la compression avancée et synthetic _source, conservez et analysez les données dont vous avez besoin avec le budget qui vous convient.

Vous voulez en faire l'expérience ? Essayez Elastic gratuitement.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.