Prise en main du langage de requête d'Elasticsearch, ES|QL

ES|QL est le nouveau langage de requête canalisé innovant d'Elastic®. Il est conçu pour accélérer les processus d'analyse et d'examen de vos données grâce à des capacités puissantes de calcul et d'agrégation. 

Une attaque est en cours ? Un problème de production se présente ? Repérez-les avec facilité et efficacité. 

Non seulement ES|QL simplifie la recherche, l'agrégation et la visualisation d'ensembles de données volumineux, mais il fournit aussi aux utilisateurs des fonctionnalités avancées comme le référencement ou le traitement en temps réel, le tout à partir d'un seul et même écran dans Discover.

Nos utilisateurs ont besoin d'outils agiles qui présentent les données, mais pas seulement. Ils doivent aussi proposer des méthodes efficaces pour extraire le sens de ces données, ainsi que la possibilité d'agir en temps réel en fonction des informations révélées et après le traitement des données ingérées. 

Elastic s'est engagée à améliorer l'exploration des données pour les utilisateurs. C'est cet engagement qui nous a conduits à investir dans ES|QL. Ce langage est conçu pour être accessible pour les novices et puissant pour les utilisateurs chevronnés. Avec l'interface intuitive d'ES|QL, les utilisateurs peuvent se lancer rapidement et étudier leurs données dans les détails sans courbe d'apprentissage difficile. La saisie automatique et la documentation dans l'application contribuent à faciliter le workflow, ce qui fait que les utilisateurs peuvent élaborer des requêtes avancées en toute simplicité. 

De plus, ES|QL ne se contente pas de vous montrer de simples chiffres : il leur donne du sens. Les visualisations contextuelles optimisées par le moteur de suggestions de Lens s'adaptent automatiquement à la nature de vos requêtes. Vous disposez ainsi d'une vue claire et précise sur les informations exploitables. 

À cela s'ajoute une intégration directe dans les fonctionnalités Dashboards et Alerting, ce qui représente bien notre vision d'une expérience cohérente de bout en bout. 

En substance, notre investissement dans ES|QL est une réponse directe à l'évolution des besoins de notre communauté. Il s'agit d'un nouveau pas vers un workflow plus interconnecté, plus pertinent et plus efficace.

Vous accéderez ainsi au mode ES|QL dans Discover.

Avec ES|QL, explorez vos données sous tous les angles. Ce langage vous permet d'étudier vos données dans Discover de manière ad hoc, de créer des agrégations, de transformer vos données, d'enrichir les ensembles de données, et bien plus encore. Le tout, depuis l'outil de création des requêtes. Les résultats sont présentés sous forme de tableau ou de visualisations. Tout dépend de la requête que vous exécutez.

Vous trouverez ci-dessous des exemples de requêtes ES|QL pour l'observabilité, ainsi que la représentation des résultats associés sous forme de tableau ou de visualisation. 

Requête ES|QL avec indicateurs :

La requête ci-dessus illustre comment utiliser la commande source, les fonctions d'agrégation et les commandes de traitement indiquées ci-dessous : 

from : commande source (cf. documentation)

from metrics*: permet de lancer une requête à partir de modèles d'indexation correspondant au modèle "metrics*". L'astérisque (*) a l'effet d'un caractère générique, ce qui signifie qu'il va sélectionner les données de tous les modèles d'indexation dont les noms commencent par "metrics". 

stats…by : agrégations (cf. documentation), max (cf. documentation) et by (cf. documentation) 

Ce segment agrège les données selon des statistiques spécifiques. En voici la décomposition : 

max_cpu=max(kubernetes.pd.cpu.usage.node.pct) : pour chaque "kubernetes.pod.name", il détermine le pourcentage d'utilisation maximale de la CPU et stocke cette valeur dans une nouvelle colonne appelée "max_cpu". 

max_mem = max(kubernettes.pod.memory.usage.bytes) : pour chaque "kubernetes.pod.name", il détermine l'utilisation maximale de mémoire en octets et stocke cette valeur dans une nouvelle colonne appelée "avg_mem". 

Commandes de traitement (cf. documentation)

• sort (cf. documentation) 
• limit (cf. documentation)

sort max_cpu desc : permet de trier les lignes de données obtenues selon la colonne "max_cpu" dans l'ordre décroissant. De ce fait, la ligne ayant la valeur "max_cpu" la plus élevée apparaîtra en premier. 

limit 10 : permet de limiter la sortie aux 10 premières lignes une fois le tri effectué. 

En résumé, la requête : 

• regroupe les données de tous les index d'indicateurs selon un modèle d'indexation ;
• agrège les données pour déterminer le pourcentage d'utilisation maximale de la CPU et l'utilisation maximale de la mémoire pour chaque pod Kubernetes ;
• trie les données agrégées par ordre décroissant selon l'utilisation maximale de la CPU ;
• renvoie uniquement les 10 premières lignes correspondant aux valeurs les plus élevées d'utilisation de la CPU ;

Visualisations contextuelles : lorsque vous écrivez des requêtes ES|QL dans Discover, vous obtenez des représentations visuelles optimisées par le moteur de suggestions de Lens. La nature de votre requête détermine le type de visualisation renvoyé : interroger, histogramme, carte thermique, etc. 

Vous trouverez ci-dessous une représentation visuelle de la requête indiquée plus haut sous forme de graphique à barres et sous forme de tableau, avec les colonnes max_cpu, avg_mem et kubernetes.pod.name :

Exemple de requête ES|QL pour l'observabilité et les données temporelles : 

La requête ci-dessus illustre comment utiliser la commande source, les fonctions d'agrégation, les commandes de traitement et les fonctions indiquées ci-dessous : 

from : commande source (cf. documentation)

from apache-logs : permet de lancer une requête à partir d'un index appelé "apache-logs". Cet index contient des entrées de log en lien avec le trafic du serveur web Apache. 

where (cf. documentation)

where url.original==”/login” : filtre les enregistrements pour lesquels le champ "url.original" a pour valeur "/fr/login". Cela signifie que nous sommes intéressés uniquement par les entrées de log appartenant aux tentatives de connexion ou aux accès à la page de connexion. 

eval (cf. documentation) et auto_bucket (cf. documentation)

eval time_buckets =... : entraîne la création d'une nouvelle colonne appelée "time_buckets". 

La fonction "auto_bucket" crée des buckets conviviaux et renvoie une valeur d'horodatage pour chaque ligne qui correspond à un bucket créé. 

“@timestamp” est le champ qui indique l'horodatage de chaque entrée de log. 

"50" est le nombre de buckets. 

"2023-09-11T21:54:05.000Z" : horodatage de départ pour le bucket.

"2023-09-12T00:40:35.000Z" : horodatage de fin pour le bucket. 

Cela signifie que les entrées de log comprises entre les horodatages "2023-09-11T21:54:05.000Z" et "2023-09-12T00:40:35.000Z" seront réparties en 50 intervalles espacés de manière égale. Chaque entrée sera associée à un intervalle spécifique en fonction de son horodatage. 

Le but n'est pas de fournir le nombre précis de buckets, mais plutôt de sélectionner une plage avec laquelle vous vous sentez à l'aise pour travailler et qui fournit le nombre cible de buckets. Si vous demandez à avoir un plus grand nombre de buckets, alors auto_bucket peut sélectionner une plage plus petite. 

stats…by : agrégations (cf. documentation), count (cf. documentation) et by (cf. documentation) 

stats login_attempts = count(user.name) by time_buckets, user.name : permet d'agréger les données pour calculer le nombre de tentatives de connexion. Pour cela, cet élément compte les occurrences de "user.name" (représentant chaque utilisateur unique essayant de se connecter). 

Le décompte est effectué en regroupant "time_buckets" (les intervalles de temps que nous avons créés) et "user.name". Cela signifie que pour chaque bucket temporel, nous verrons le nombre de tentatives que chaque utilisateur a effectué pour se connecter. 

sort (cf. documentation) 

Sort login_attempts desc : pour finir, les résultats agrégés sont triés selon la colonne "login_attempts" dans l'ordre décroissant. Le premier résultat affiché correspondra donc au nombre de tentatives de connexion le plus élevé. 

En résumé, la requête :

• sélectionne les données dans l'index "apache-logs" ;
• filtre les entrées de log concernant la page de connexion ;
• regroupe ces entrées dans des intervalles de temps spécifiques ;
• compte le nombre de tentatives de connexion de chaque utilisateur dans ces intervalles ;
• renvoie des résultats triés en fonction du nombre de tentatives de connexion effectuées, le plus grand nombre apparaissant en premier.

Vous trouverez ci-dessous une représentation visuelle de la requête indiquée plus haut sous forme de graphique à barres et sous forme de tableau, avec les colonnes login_attempts, time_buckets et user.name.

Modifiez les visualisations d'ES|QL directement dans Discover et Dashboards. Vous n'avez pas besoin d'accéder à Lens pour effectuer des modifications rapides, vous pouvez les faire directement de façon transparente. 

Ci-dessous, vous trouverez une vidéo présentant un workflow de bout en bout, ainsi qu'un guide détaillé :

1. Écrire une requête ES|QL

2. Obtenir une visualisation contextuelle en fonction de la nature de la requête

3. Modifier la visualisation ligne par ligne

4. L'enregistrer dans un tableau de bord

5. Être capable de modifier la visualisation depuis un tableau de bord

1^ère étape. Écrire une requête ES|QL. Exemple de requête produisant une visualisation d'indicateurs :

2^e étape. Obtenir une visualisation contextuelle (dans le cas présent, une visualisation d'indicateurs) en fonction de la nature de la requête. Vous pouvez sélectionner l'icône en forme de crayon pour accéder au mode de modification ligne par ligne.

3^e étape. Modifier la visualisation à l'aide du mode de modification ligne par ligne.

Dans le cas ci-dessus, nous souhaitons que le mode de couleur de la visualisation soit dynamique. Nous cliquons donc sur "Dynamic" (Dynamique).

Nous avons aussi la possibilité de définir la plage de couleurs que nous souhaitons utiliser :

4^e étape. Enregistrer la visualisation dans un tableau de bord.

5^e étape. Être capable de modifier la visualisation depuis un tableau de bord.

Vous pouvez utiliser ES|QL pour les alertes d'observabilité et de sécurité, en définissant des valeurs agrégées comme seuils. Améliorez la précision de la détection et recevez des notifications exploitables en mettant l'accent sur les grandes tendances plutôt que sur des incidents isolés, ce afin de réduire le nombre de faux positifs. 

À présent, nous allons voir comment créer un type de règle d'alerte ES|QL à partir de Discover. 

Le nouveau type de règle d'alerte est disponible dans le type de règle Elasticsearch existant. Ce type de règle dispose de toutes les nouvelles fonctionnalités accessibles dans ES|QL et permet de prendre en charge de nouveaux cas d'utilisation d'alerting.

Avec ce nouveau type, les utilisateurs pourront générer une alerte unique basée sur une requête ES|QL définie et en prévisualiser le résultat avant d'enregistrer la règle. Lorsque la requête renvoie un résultat vide, aucune alerte n'est générée.

Exemple de requête pour une alerte :

1^ère étape. Cliquez sur "Alerts" (Alertes), puis sur "Create search threshold rule" (Créer une règle de seuil de recherche). Vous pouvez commencer à créer votre type de règle d'alerte ES|QL soit après avoir défini votre requête ES|QL dans la barre de requête, soit avant. L'avantage de le faire après avoir défini la requête est que celle-ci est automatiquement collé dans le panneau contextuel "Create Alert" (Créer une alerte). 

2^e étape. Commencez à définir votre type de règle d'alerte ES|QL.

3^e étape. Testez une requête pour votre type de règle d'alerte. Vous pouvez itérer avec la requête ES|QL qui y a été collée et lancer le test en cliquant sur "Test query" (Tester la requête). Vous pourrez ainsi prévisualiser les résultats dans un tableau. 

4^e étape. Définissez votre connecteur et cliquez sur "Save" (Enregistrer). Vous avez désormais créé un type de règle d'alerte ES|QL !

Vous pouvez utiliser la commande ENRICH (cf. documentation) pour améliorer votre ensemble de données en y ajoutant des champs d'un autre ensemble de données et en me complétant avec des suggestions contextuelle pour la politique sélectionnée (c.-à-d., en faisant référence au champ correspondant et aux colonnes enrichies).

Exemple de requête utilisant ENRICH, dans laquelle une politique d'enrichissement "servers-to-project" est utilisée via la requête pour enrichir l'ensemble de données avec "name", "server_hostname" et "cost" :

Nous avons aussi facilité la création des politiques d'enrichissement pour les utilisateurs en mettant à leur disposition un aperçu et un assistant pour les aider. 

Pour obtenir un aperçu des politiques d'enrichissement, accédez à Stack Management (Gestion de la suite) ⇒ Index Management (Gestion des index). Vous y trouverez un onglet appelé Enrich Policies (Politiques d'enrichissement) :

Voici la politique d'enrichissement utilisée dans la requête ci-dessus, "servers-to-project" :

Pour créer une politique d'enrichissement, rien de plus simple : cliquez sur Create enrich policy (Créer une politique d'enrichissement). Dès que vous en avez créé une et que vous l'avez exécutée, vous pouvez alors l'appliquer à une requête ES|QL dans Discover.

Pour en savoir plus sur les politiques d'enrichissement, cliquez ici. Et pour en savoir plus sur la commande ENRICH dans ES|QL, cliquez ici.