Ce que la rétrocompatibilité implique pour l'API Kibana Dashboards

Pendant la préversion technique, la forme de l'API pouvait changer d'une version à l'autre.[1] Ce n'est plus le cas. La disponibilité générale (DG) signifie :

• Rétrocompatibilité totale. De nouveaux champs et types de panneaux seront ajoutés au fil du temps, mais les champs et comportements existants demeureront inchangés. Toute modification majeure susceptible de rompre la compatibilité sera examinée avec la plus grande attention et ne sera introduite que dans une nouvelle version majeure de la pile technologique.

• Prête pour la production avec compatibilité totale. L'API bénéficie des garanties de compatibilité complète d'Elastic. Vous pouvez l'utiliser en toute sécurité dans les environnements de production pour les déploiements automatisés, la promotion de l'environnement et la gestion programmatique des tableaux de bord.

Nouveaux points de terminaison de l'API Kibana pour les panneaux Tags, Markdown et Links

Elastic 9.5 introduit également un nouveau point de terminaison autonome pour le panneau Tags, qui vous permet de catégoriser et filtrer les tableaux de bord. Vous pouvez désormais les gérer par programmation via des points de terminaison CRUD dédiés, ce qui facilite leur organisation à grande échelle dans différents environnements.

De nouveaux points de terminaison pour les panneaux Markdown et Liens sont désormais disponibles dans Serverless et seront intégrés dans la prochaine version de la pile (9.6).

Quels types de panneaux l'API Kibana Dashboards prend-elle en charge ?

L'API Dashboards prend en charge tous les panneaux par valeur de la version 9.5 (ceux définis directement dans un tableau de bord, par opposition aux panneaux de bibliothèque enregistrés pour être réutilisés). Chaque type de panneau pris en charge dispose d'un schéma typé et validé.

Type de panneau

État

Graphiques XY

Compatibles

Métriques

Compatibles

Circulaires

Compatibles

Jauge

Compatibles

Carte thermique

Compatibles

Tables de données

Compatibles

Arborescence

Compatibles

Sessions Discover

Compatibles

Contrôles

Compatibles

Markdown

Compatibles

Liens

Compatibles

Panneaux ML

Compatibles

Panneaux Observability

Compatibles

Maps

Bientôt disponible

Vega

Bientôt disponible

Comment gérer les tableaux de bord Kibana sous forme de code

L'API Dashboards permet un workflow complet de tableaux de bord sous forme de code : exportez un tableau de bord au format JSON propre et facilement comparable, validez-le dans Git comme source de référence, examinez les modifications via des requêtes pull et déployez la même définition dans les environnements de développement, de préproduction et de production. Une fois qu'un tableau de bord est géré sous forme de code, considérez Git comme source de référence unique : les modifications effectuées directement dans l'interface utilisateur seront écrasées lors du prochain déploiement.

La principale difficulté lors du transfert d'un tableau de bord entre des espaces, des clusters ou des environnements est que les tableaux de bord font référence à des objets (data views ou visualisations de bibliothèques, par exemple) au moyen d'identifiants. Comme ces identifiants sont générés automatiquement et varient d'un environnement à l'autre, un tableau de bord exporté depuis un environnement peut pointer vers des objets inexistants dans un autre. Il existe trois méthodes pour gérer cette situation, présentées ici de la plus automatisée à la moins automatisée :

• Utilisez Terraform. Le fournisseur Elastic Stack Terraform suit chaque ressource et associe automatiquement les identifiants par environnement, afin que les références restent cohérentes lorsque vous faites passer un tableau de bord de l'environnement de développement à l'environnement de production.

• Définissez par valeur les panneaux Elasticsearch Query Language (ES|QL). La méthode la plus portable pour créer un panneau consiste à définir sa visualisation à l'aide d'ES|QL directement dans le tableau de bord. Une requête ES|QL lit les données à partir des index qui y sont spécifiés ; le panneau ne contient donc aucune référence externe à des data views ou à des objets de bibliothèque. On obtient ainsi un tableau de bord entièrement autonome et portable.

• Attribuer les identifiants correspondants. Si vous référencez des objets enregistrés, tels que des data views ou des visualisations de bibliothèque, créez-les avec un identifiant spécifique en utilisant la méthode PUT (upsert) plutôt que POST (qui génère automatiquement un identifiant). Utilisez des identifiants explicites et lisibles, comme logs-prod, afin qu'ils soient faciles à reconnaître et à réutiliser d'un environnement à l'autre.

Pour une présentation détaillée de ces modèles de portabilité et du workflow complet des tableaux de bord sous forme de code, consultez la documentation Gérer les tableaux de bord sous forme de code.

Création d'un tableau de bord Kibana avec l'API Dashboards en utilisant PUT

Voici un exemple rapide de création d'un tableau de bord avec un panneau de métriques, utilisant la méthode PUT au lieu de POST pour attribuer un identifiant personnalisé basé sur le nom du tableau de bord (service-health-overview). La même logique s'applique à la création de visualisations autonomes enregistrées dans la bibliothèque.

Roadmap de l'API Kibana Dashboards : Maps, Vega et points de terminaison autonomes

Nous travaillons activement à étendre la surface de l'API. La prise en charge des panneaux Maps et Vega est la prochaine étape, avec ajout de schémas typés. Nous développons également des points de terminaison CRUD autonomes pour les sessions Discover (au-delà de leur prise en charge actuelle en tant que panneaux de tableau de bord), les panneaux Vega, Maps et les Annotations, le tout dissocié du cycle de vie des tableaux de bord.

Pour les définitions complètes des schémas, consultez la documentation de l'API Dashboards. Pour les utilisateurs de Terraform, le fournisseur Elastic Stack Terraform prend en charge l'API Dashboards en DG.

Remarque

1. Les points de terminaison principaux restent inchangés par rapport à la préversion technique. Si vous avez développé des intégrations pour la version 9.4, elles fonctionneront avec la version 9.5. Les seuls changements entraînant une rupture de compatibilité sont deux modifications mineures concernant la liste des tableaux de bord et les formats d'unité de durée ; elles sont documentées ici.

Quoi de neuf dans la création de tableaux de bord IA avec Kibana

Fonctionnalité

Préversion technique (9.4)

DG (9.5)

Gestion des erreurs

Pas de nouvelle tentative en cas d'échec des requêtes ES|QL

Jusqu'à trois tentatives automatiques avec inspection et ajustement des requêtes

Coût de génération ES|QL

Toutes les requêtes sont acheminées via le modèle principal

Modèle de routage à plusieurs niveaux, jusqu'à 5 fois moins cher

Plage temporelle

Fenêtre fixe par défaut

Sélection automatique en fonction de la distribution temporelle des données

Contrôles de filtre

Non pris en charge

Ajoutés automatiquement pour les champs les plus pertinents

Graphiques Vega-Lite

Non pris en charge

Création en langage naturel, incluant les nuages de points, les diagrammes en boîte, la mise en forme conditionnelle et les infobulles personnalisées

Modification de graphique

Non pris en charge

Modification des panneaux Vega-Lite existants en langage naturel

Récupération automatique des erreurs pour la génération de tableaux de bord par IA

Dans la préversion technique, l'agent ne relançait pas les requêtes ES|QL ayant échoué. Avec la version 9.5, il détecte les erreurs de requête et tente de les réexécuter jusqu'à trois fois ; il analyse chaque erreur et ajuste la requête avant d'abandonner. En pratique, cela élimine la majeure partie des problèmes de panneaux vides et permet d'obtenir des tableaux de bord qui s'affichent correctement dès la première tentative.

Pourquoi la création de tableaux de bord par IA est-elle moins coûteuse dans Elastic 9.5 ?

Les étapes de génération d'un tableau de bord ne nécessitent pas toutes le même niveau de raisonnement. Dans la version 9.5, la génération ES|QL passe par un modèle plus léger par défaut et revient au modèle principal uniquement en cas de besoin. Si votre connecteur utilise Claude Opus 4.8 d'Anthropic, la génération ES|QL pour tous les panneaux revient alors cinq fois moins cher.

Sélection automatique de la plage temporelle basée sur vos données

Les tableaux de bord ne sont utiles que s'ils affichent la fenêtre de données appropriée. L'agent applique désormais une logique optimisée pour sélectionner une période pertinente au regard des données interrogées, à moins que l'utilisateur ne spécifie une plage horaire particulière. Il prend en compte la répartition temporelle des données et adapte son choix en conséquence, qu'il s'agisse de la dernière heure pour un incident en cours ou des 90 derniers jours pour une analyse de tendance, plutôt que de s'en tenir systématiquement à une fenêtre temporelle fixe.

Contrôles de filtrage automatiques sur les tableaux de bord générés par IA

La création de tableaux de bord prend désormais en charge les contrôles, c'est-à-dire des filtres interactifs qui permettent aux utilisateurs d'affiner un tableau de bord en fonction des valeurs des champs sans modifier les requêtes sous-jacentes. Lors de la génération d'un tableau de bord, l'agent ajoute automatiquement des contrôles en haut pour les champs les plus pertinents à filtrer.

Graphiques Vega-Lite à partir du langage naturel : types de graphiques et mise en forme au-delà des valeurs par défaut

Vega et Vega-Lite prennent en charge une grande variété de types de graphiques et de personnalisations dans Kibana. Avec la version 9.5, vous pouvez les créer en langage clair au lieu d'écrire le code vous-même. 

Nuages de points, diagrammes en boîte et autres types de graphiques Vega-Lite

Les nuages de points, les diagrammes en boîte, les graphiques à facettes, les graphiques à bulles et les graphiques de composition (tels que la combinaison d'histogrammes et de cartes thermiques), entre autres, sont pris en charge par Vega-Lite. Un prompt comme Affiche-moi un nuage de points du temps de réponse en fonction de la taille de la requête, avec une coloration par nom de service génère un panneau Vega-Lite intégrant les mappings de données appropriés. Ces graphiques utilisent les palettes de couleurs par défaut de Kibana afin de s'harmoniser avec le reste du tableau de bord.

Mise en forme conditionnelle, infobulles personnalisées et étiquettes sur graphiques standard

Même pour les types de graphiques déjà intégrés dans les tableaux de bord comme les graphiques à barres, linéaires ou en aires, il est parfois nécessaire de disposer d'un contrôle plus poussé que celui offert par les fonctionnalités par défaut. Vega-Lite permet de combler cette lacune via le chat. En voici quelques exemples :

• Mise en forme conditionnelle des couleurs : appliquez une couleur différente aux points de données dépassant un certain seuil ; par exemple, colorez en rouge les points d'un graphique linéaire ou en barres lorsqu'une métrique dépasse votre objectif de niveau de service (SLO). Demandez à l'agent quelque chose comme Colore en rouge tous les points dépassant 500 ms sur mon graphique linéaire.

  

• Marqueurs et étiquettes personnalisés : ajoutez des émojis, des symboles ou des étiquettes textuelles intégrées aux points de données pour obtenir des indicateurs d'état visibles d'un seul coup d'œil.

  

• Infobulles personnalisées : enrichissez les états au survol avec des métriques supplémentaires, du contexte ou des valeurs calculées qui ne figurent pas sur les axes du graphique. Demandez par exemple Ajoute une infobulle indiquant le nombre total d'enregistrements et le pourcentage par barre.

  

Cette méthode fonctionne également pour modifier des graphiques Vega existants. Si vous avez un panneau Vega-Lite nécessitant une retouche comme modifier une échelle de couleurs, ajuster un axe ou changer le type de marqueur, décrivez la modification dans le chat plutôt que de fouiller dans le code JSON.

Comment nous avons créé la génération Vega-Lite en langage naturel dans Kibana

Générer un graphique Vega-Lite à partir d'une phrase ne se résume pas à un simple prompt unique demandant au modèle de fournir du JSON. Nous avons mis au point un petit pipeline de type agent capable de transformer une intention exprimée en langage naturel en un graphique validé et étayé par des données.

À la réception d'une requête, l'agent détermine d'abord si Vega-Lite est la solution appropriée. Pour les requêtes Vega-Lite, il ancre la visualisation sur une véritable requête ES|QL adressée à Elasticsearch, puis utilise un modèle pour générer le code Vega-Lite. Avant le rendu, le résultat passe par une couche de normalisation qui corrige le schéma et lie la requête canonique ; des transformations visant à garantir la sécurité du rendu sont également appliquées.

Quelques choix de conception rendent ce workflow fiable :

• Appel d'outil typé : la création de graphiques repose sur l'appel structuré d'un outil plutôt que sur l'insertion de code Vega-Lite en format libre dans la conversation.

• Génération contrainte : le modèle génère du code Vega-Lite selon un schéma défini, ce qui rend la sortie plus prévisible et plus facile à valider.

• Exemples sélectionnés : les schémas structurels, tels que la navigation à facettes, les marqueurs superposés et les cartes thermiques, fournissent des indications sans copier les données sous-jacentes.

• Boucles d'exécution et de vérification : les requêtes sont exécutées avant la création du graphique, et les échecs de validation déclenchent des tentatives correctives pour la génération ES|QL.

Essayez la création de tableaux de bord par IA et les graphiques Vega-Lite dans Kibana

Pour tester la création de tableaux de bord en langage naturel et les graphiques Vega-Lite, passez à Elastic 9.5 (ou commencez un essai gratuit) et ouvrez le chat dans Kibana. Demandez ensuite à l'outil de générer un tableau de bord à partir de vos données. Pour Vega-Lite, demandez un type de graphique que vous avez toujours voulu mais que vous n'avez jamais créé, comme un nuage de points ou un graphique à bulles. Si le résultat ne vous convient pas tout à fait, indiquez à l'agent ce qu'il faut modifier ; il itère avec vous.

Cela nécessite une licence Entreprise. Commencer.

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.

Chaque année, les catastrophes naturelles contraignent les responsables de la gestion des urgences, les commandants militaires et les autorités de sécurité publique à prendre des décisions aux enjeux considérables dans des délais très courts. Ces décisions reposent traditionnellement sur des chaînes d'appel, des feuilles de calcul et des connaissances institutionnelles réparties entre des dizaines de personnes. À elle seule, la surcharge liée à la coordination fait perdre un temps précieux.

Cet article montre comment Elastic permet de disposer d'un système de coordination agentique réactif et autonome pour la réponse aux catastrophes. Ce système détecte une menace, analyse les aspects logistiques et prend des mesures automatiquement. Pour illustrer ce concept, nous avons créé une simulation : un ouragan fictif de catégorie 4 menaçant le littoral de Hampton Roads déclenche le déplacement automatisé de plus de 137 000 personnes réparties sur sept installations militaires.

Avertissement : ceci est un scénario entièrement fictif élaboré à des fins de démonstration. L’ouragan ELARA-26 n’existe pas. Les emplacements des installations reposent sur des données géographiques réelles et accessibles au public issues de l'ensemble de données MIRTA (Military Installations, Ranges and Training Areas) du département de la Défense des États-Unis. Toutes les données opérationnelles, telles que les effectifs, la capacité de logement, les ressources, les adresses e-mail de contact et les profils de mission, sont entièrement fictives. Rien dans cette démonstration ne reflète la préparation opérationnelle, les capacités ou les procédures opérationnelles militaires réelles.

Pourquoi la réponse automatisée aux catastrophes nécessite une coordination géospatiale et agentique

Lorsqu'une catastrophe naturelle menace les infrastructures critiques, le défi de la coordination est immédiat :

• Quelles installations se trouvent dans la zone d'impact ?

• Combien de membres du personnel doivent être déplacés ?

• Où peuvent-ils aller, et ces installations ont-elles la capacité nécessaire ?

• Qui doit être informé immédiatement ?

Ces questions n'attendent pas. Les réponses non plus.

Déploiement du pipeline : prérequis et configuration

Suivez les instructions ici dans le dépôt d'exemples pour déployer un cluster Elastic local avec Elastic Inference Service (EIS) via Cloud Connect.

Fonctionnement du pipeline agentique de réponse aux catastrophes d'Elasticsearch

Le pipeline comporte sept couches qui fonctionnent ensemble de bout en bout :

1. Ingestion de données : les événements de catastrophe du Système mondial d'alerte et de coordination en cas de catastrophe (GDACS) sont envoyés à Elasticsearch.

2. Pipeline d'ingestion : les données GeoJSON sont ingérées et normalisées selon Elastic Common Schema (ECS).

3. Enrichissement géospatial : le polygone de la zone touchée par l'événement est confronté aux limites indexées des installations militaires.

4. Alerting : une règle de détection Kibana se déclenche lorsqu'une catastrophe recoupe une installation.

5. Automatisation du workflow : l'alerte déclenche un workflow Kibana qui lance une conversation avec un agent IA.

6. Raisonnement de l'IA : l'agent analyse les installations concernées, leurs actifs et les installations de soutien les plus proches afin de déterminer la relocalisation de l'ensemble des actifs et du personnel.

7. Notifications par e-mail: l'agent envoie des e-mails à tous les destinataires concernant le personnel et/ou les actifs entrants et sortants.

Passons en revue chaque couche.

Étape 1 : Indexation des installations militaires avec limites géographiques

La base repose sur l'ensemble de données DoD MIRTA provenant de source.coop/seerai/hifld. Cet ensemble fournit une géométrie de type Point pour chaque installation, à savoir des coordonnées de centroïde plutôt que de polygones délimitant l'intégralité du périmètre.

Chaque document d'installation dans l'index 'mitra-facilities' est enrichi de données de profil opérationnel (toutes fictives), au-delà de ce que fournit MIRTA :

C'est cet index riche qui permet à l'agent IA de prendre des décisions d'affectation intelligentes. Il ne s'agit pas simplement d'identifier des bases à proximité, mais de repérer celles qui disposent de capacités de logement disponibles, de types de missions compatibles et de la logistique nécessaire pour accueillir les ressources entrantes.

Étape 2 : Ingestion et normalisation des événements GDACS

GDACS publie des données GeoJSON en temps réel concernant les séismes, les cyclones tropicaux, les inondations, les feux de forêt, les volcans et les sécheresses. Nous intégrons ce flux dans un flux de données (logs-gdacs.events-*) à l'aide d'un pipeline d'ingestion personnalisé qui normalise les données GeoJSON brutes au format de champs ECS.

À noter que le pipeline d'ingestion GDACS effectue plusieurs opérations :

Extraction de la géométrie : le centroïde est stocké sous forme de 'geo_point' pour l'affichage cartographique, et le polygone d'impact est stocké sous forme de 'geo_shape' dans 'gdacs.affected_area', un champ qui sera utilisé ultérieurement pour les requêtes de recoupement.

Normalisation de la gravité : chaque type de catastrophe présente une échelle de gravité différente. Un cyclone tropical se mesure par la vitesse du vent en km/h, tandis qu'un séisme s'évalue selon la magnitude de Richter. Le pipeline convertit toutes ces mesures en un score normalisé allant de 0 à 100 :

Le score de gravité normalisé est ensuite associé à une étiquette de niveau de gravité (faible, moyen, élevé, critique) utilisée pour la correspondance du niveau de gravité de l'alerte dans la règle de détection.

Alignement ECS : event.kind : alerte, event.category : menace, horodatages mappés sur event.start/event.end et un _id stable basé sur une empreinte pour la déduplication.

Étape 3 : Enrichissement géospatial - identifier les installations affectées au moment de l'indexation

La politique d'enrichissement 'geo_match' d'Elasticsearch fait correspondre le polygone de la zone sinistrée à chaque périmètre d'installation lors de l'indexation, sans nécessiter de jointure au moment de la requête. Au lieu d'effectuer une requête lors de la recherche, nous utilisons un processeur d'enrichissement dans le pipeline d'ingestion pour faire correspondre le polygone d'impact de la catastrophe avec chaque limite d'installation au moment où le document est indexé.

La politique d'enrichissement est une politique 'geo_match' :

Le processeur s'exécute à la fin du pipeline d'ingestion :

INTERSECTS permet de détecter toute installation dont la limite touche ou chevauche le polygone de la catastrophe, y compris en cas d'intersection partielle. Par conséquent, chaque document d'événement GDACS est enregistré avec un tableau imbriqué 'affected_facilities' indiquant précisément quelles installations se trouvent dans la zone d'impact. Aucune requête de jointure n'est nécessaire.

Étape 4 : Règle de détection – alerting en cas d'impact sur les installations

Une règle de détection Kibana surveille le flux de données logs-gdacs.events-* et se déclenche lorsqu'un événement GDACS a été enrichi avec au moins une infrastructure affectée :

La règle s'exécute selon une planification horaire (couvrant une fenêtre allant de 'now-1h' à 'now') et utilise une correspondance dynamique de la gravité ; le champ 'gdacs.severity_level', calculé par le pipeline d'ingestion, détermine automatiquement la gravité de l'alerte.

La gravité de l'alerte détermine également le score de risque via le mapping de champs :

Lorsque la règle se déclenche, elle transmet à un workflow Kibana l'intégralité du contexte de l'alerte, y compris le tableau 'affected_facilities' enrichi contenant les noms, types et emplacements des installations.

Étape 5 : Automatisation des workflows – relier l'alerte à l'agent

Les workflows Kibana gèrent la transition entre la détection et la réponse. Le workflow de réponse aux catastrophes naturelles est déclenché par l'alerte :

L'intégralité de la charge utile de l'alerte (type de catastrophe, gravité, zone touchée et liste des installations impactées) est transmise à l'agent IA en tant que contexte initial. L'agent prend ensuite le relais.

Étape 6 : L'agent IA – des données à l'action coordonnée

L'agent mitra.response utilise l'intégralité de la charge utile d'alerte et, au cours d'une seule boucle agentique, évalue le périmètre, trouve les établissements d'accueil, affecte le personnel et envoie des notifications d'évacuation et de prise en charge, le tout sans intervention humaine.

L'agent dispose de deux outils :

• mitra.nearest_facilityinterroge l'index mitra-facilities à l'aide d'une requête geo_shape, triée par distance par rapport à une coordonnée donnée, et renvoie jusqu'à 50 installations actives à proximité disposant de capacités d'accueil.

• mitra.send_email itère sur un tableau JSON d'objets d'installation et transmet des notifications formatées d'évacuation ou de réception.

L'ensemble d'instructions de l'agent définit un workflow clair :

1. Évaluer la situation. Analyser l'alerte, identifier les installations touchées et déterminer l'ampleur de la catastrophe.

2. Faire l'inventaire de ce qui doit être déplacé. Effectifs, ressources critiques, besoins en hébergement par établissement.

3. Rechercher les installations de destination. Appeler mitra.nearest_facility pour chaque installation concernée, en excluant celles qui se trouvent encore dans la zone de danger.

4. Prendre des décisions d'allocation. Raisonner sur les solutions monosite par rapport aux solutions multisites, la compatibilité des branches, la capacité d'hébergement, le support technique des actifs.

5. Envoyer les e-mails de coordination. Transmettre les ordres d'évacuation aux établissements d'origine et les notifications d'admission aux établissements d'accueil.

6. Générer un rapport récapitulatif. Produire un court résumé, à transmettre dans le chat pour examen, de toutes les installations concernées, de l'effectif total, des actifs déplacés, des installations de destination et de toute préoccupation.

La logique d'affectation de l'agent respecte des contraintes réelles : ne pas dépasser la capacité d'hébergement, privilégier les réaffectations au sein d'une même branche lorsque c'est possible, utiliser des bases interarmées pour les excédents multibranches et prioriser la distance afin de minimiser le temps de trajet.

L'outil d'installation la plus proche

La requête de workflow sous-jacente utilise geo_shape avec un filtre de cercle et un tri _geo_distance :

La capacité disponible est calculée au moment de la requête via un champ de script qui soustrait l'effectif actuel de la capacité d'hébergement. L'agent utilise cette information pour répartir le personnel entre les différentes destinations sans dépasser les limites.

Ouragan ELARA-26 : coordination agentique de 137 000 personnes, de bout en bout

L'ouragan ELARA-26 est une tempête de catégorie 4 (vitesse maximale de 213 km/h) dont l'arrivée sur les côtes est prévue dans la région de Hampton Roads, en Virginie. Lors de l'intégration de l'événement GDACS, le polygone de la zone touchée recoupe sept installations militaires majeures de la région. La règle de détection se déclenche. Le workflow initie une conversation entre agents.

Au sein d'une seule boucle agentique, l'agent :

• a identifié sept installations dans la zone d'impact pour un total de 137 372 membres du personnel ;

• a appelé mitra.nearest_facility pour trouver des établissements d'accueil situés en dehors de la trajectoire de la tempête ;

• a réparti le personnel entre neuf établissements d'accueil en fonction de la capacité d'hébergement disponible et de la distance ;

• a généré et envoyé des ordres d'évacuation aux sept installations concernées ;

• a généré et envoyé des notifications d'admission aux neuf installations destinataires ;

• a généré un récapitulatif complet de coordination, semblable à ce qui suit :

Sites évacués :

Installation

Personnel

Base navale de Norfolk

50 000

Base expéditionnaire interarmées Little Creek-Fort Story

18 000

Base aéronavale Oceana

15 355

Annexe Dam Neck de la base aéronavale d'Oceana

17 509

Réserve militaire d'État de la Garde nationale Camp Pendleton

9 707

Base interarmées Langley-Eustis

15 000

Base d'armement naval de Yorktown

11 801

Installations d'accueil :

Installation

Distance

Personnel entrant

Fort Gregg-Adams

97 km

~40 000

Base du Corps des Marines de Quantico

148 km

~30 000

Installation de soutien naval d'Indian Head

151 km

~30 000

Base interarmées Andrews

180 km

~30 000

Base aéronavale de Patuxent River

141 km

~10 000

Camp Butner de la Garde nationale

174 km

~5 000

Site d'entraînement de la Garde nationale Bethany Beach

209 km

~4 707

Base de Rivanna

140 km

~7 500

Centre d'approvisionnement général de la Défense

22 km

~6 000

Les moyens redéployés comprennent des véhicules de transport, des hélicoptères, des patrouilleurs, des unités médicales, des engins du génie, des groupes électrogènes, des remorques-citernes, des kits d'hébergement et des systèmes de communication.

Notifications par e-mail automatisées

Une fois son plan d'affectation finalisé, l'agent a appelé mitra.send_email et a envoyé 16 e-mails en une seule opération : des ordres d'évacuation destinés aux sept installations concernées et des avis d'admission adressés aux neuf établissements d'accueil. Chaque message précisait l'établissement de destination, le nombre de personnes transférées, les ressources à déplacer ainsi qu'un contact de coordination. Ce qui aurait nécessité des heures de chaînes d'appels téléphoniques a été accompli automatiquement dès que l'agent a achevé son raisonnement.

Extension de la réponse agentique aux catastrophes avec la RAG et l'ancrage des politiques

Cette démo repose uniquement sur des données structurées, telles que les capacités, les distances et l'état opérationnel. Les fonctionnalités de recherche sémantique et de génération augmentée par récupération (RAG) d'Elastic contribuent à rendre l'agent nettement plus intelligent, grâce à deux ajouts :

Récupération des réponses historiques : indexation des anciens rapports post-intervention, des résumés d'incidents de l'Agence fédérale de gestion des urgences (FEMA) et des archives de réponse aux catastrophes sous forme d'embeddings vectoriels. Lorsqu'un nouvel événement se déclenche, l'agent peut effectuer une recherche sémantique sur la manière dont des événements similaires ont été traités, afin d'éclairer les décisions d'allocation grâce aux connaissances institutionnelles plutôt qu'aux seuls calculs de capacité.

Ancrage dans les politiques et la doctrine : indexation des directives de gestion des urgences du DoD, des plans de continuité des opérations des installations et des orientations du commandement. L'agent peut récupérer et citer les politiques réelles régissant une réponse, garantissant ainsi que chaque décision est fondée sur la doctrine plutôt que sur une inférence.

Ces deux fonctionnalités suivent la même approche Elastic native : un pipeline d'inférence génère des embeddings au moment de l'indexation, et un outil de recherche sémantique est exposé à l'agent. Le pipeline de coordination reste le même. L'agent devient simplement plus intelligent.

Pourquoi Elasticsearch est la plateforme idéale pour la réponse agentique dans le secteur public

Ce n'est pas un chatbot. Ce n'est pas un tableau de bord. C'est un système de workflow agentique réactif, lequel a détecté une menace, analysé un problème logistique complexe et coordonné le déplacement de 137 000 personnes sans intervention humaine. Ce type de résultat n'est possible que parce que chaque fonctionnalité dont il dépend repose sur une plateforme unique et unifiée.

La prise en charge géospatiale d'Elasticsearch (geo_point, geo_shape, stratégies d'enrichissement et tri basé sur la distance) gère le raisonnement spatial qui rend possibles la détection des recoupements et la recherche d'installations à grande échelle. La recherche sémantique et les embeddings vectoriels ancrent les agents dans la réalité, garantissant que le raisonnement de l'IA repose sur ce qui se trouve réellement dans vos données plutôt que sur des hypothèses hallucinées. Le moteur de détection de Kibana, Workflows, Agent Builder et les outils d'Agent Builder connectent l'ensemble au sein d'un pipeline allant de l'événement brut à l'action coordonnée, sans nécessiter le moindre code de liaison externe.

Aucune autre plateforme ne réunit ces capacités comme le fait Elastic. L'alliance de l'indexation en temps réel, de la précision géospatiale, de la recherche sémantique et de l'orchestration par agents, le tout au sein d'une même pile technologique intégrant sécurité et observabilité de niveau entreprise, distingue Elastic des outils qui excellent dans un seul de ces domaines tout en vous obligeant à assembler vous-même les autres éléments.

Réponse géospatiale agentique pour la gestion des urgences, les services d'incendie, les forces de l'ordre et la santé publique

La même architecture s'applique partout où les personnes, les installations, et les événements en temps réel se recoupent. Les données spécifiques changent. Le pipeline ne change pas.

Gestion des urgences : la FEMA et les services de gestion des urgences des États peuvent cartographier l'emplacement des abris, les zones de déploiement et les populations vulnérables en regard des polygones de conditions météorologiques extrêmes émis par le National Weather Service (NWS), déclenchant ainsi le prépositionnement automatisé des ressources avant qu'une tempête ne touche terre.

Services d'incendie et de secours d'urgence : les services d'incendie peuvent superposer l'emplacement des unités et les zones d'intervention aux périmètres des feux de forêt ou aux clusters d'incendies de structures, en acheminant automatiquement les demandes d'entraide vers les unités disponibles les plus proches dotées de l'équipement adapté.

Forces de l'ordre : les organismes peuvent corréler les lieux d'incidents en cours avec les zones scolaires, les infrastructures critiques et la position des agents, déclenchant ainsi des notifications de confinement géolocalisées ou le déploiement de ressources sans attendre un tri manuel.

Sécurité des établissements scolaires : les districts scolaires peuvent monitorer les flux de menaces en temps réel par rapport au périmètre des campus. Lorsqu'une menace franchit le périmètre d'une école, un agent peut immédiatement avertir l'administration, déclencher les communications de confinement et coordonner la réponse des forces de l'ordre, avant même qu'un coordinateur ne décroche son téléphone.

Santé publique : les services de santé peuvent comparer les données de surveillance des maladies ou les zones de risques environnementaux avec les emplacements des établissements de soin, les couches de densité de population et les inventaires des dépôts de fournitures afin d'acheminer les ressources là où elles sont le plus nécessaires.

Secteur

Cas d'utilisation

Capacité Elastic

Gestion des urgences

Croiser les emplacements des abris aux polygones de phénomènes météorologiques violents du NWS

Enrichissement geo_shape + workflows Kibana

Incendie et SMU

Superposer les emplacements des unités aux périmètres des feux de forêt

Routage géospatial + requête de recherche de l'installation la plus proche

Application de la loi

Corréler les incidents avec les zones scolaires et les positions des agents

Règles d'alerte tenant compte de la géolocalisation + répartition des agents

Sécurité des établissements scolaires

Monitorer les flux de menaces par rapport aux périmètres de campus

Règles de détection + notification automatisée

Santé publique

Croiser les zones de danger avec les emplacements des établissements de soin et les dépôts de ravitaillement

Recherche sémantique + enrichissement géospatial

Les données varient selon les scénarios, mais le schéma sous-jacent reste identique : ingestion, enrichissement lors de l'indexation, détection des recoupements, déclenchement d'une réponse agentique et exécution de l'action. Elastic fournit aux organismes du secteur public une plateforme permettant de concevoir cette solution une seule fois et de l'adapter partout.

La publication et la date de publication des fonctionnalités ou fonctions décrites 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.

L'agent crée des tableaux de bord à partir de zéro, mais il fonctionne également avec ce que vous avez déjà. Ouvrez la barre latérale AI Chat tout en affichant un tableau de bord et celui-ci se joint automatiquement. Demandez pourquoi une métrique a augmenté, ventilez-la par région ou ajoutez un panneau de comparaison. Votre tableau de bord existant devient le point de départ, et pas seulement le produit final.

Dans les coulisses : comment nous avons développé des tableaux de bord dans AI Chat

Nous enseignons à l'agent des tâches spécifiques au moyen de skills, des descriptions structurées de la manière de traiter un problème donné. Cependant, développer un skill de tableau de bord impliquait d'apprendre à un LLM à générer des tableaux de bord Kibana valides, et l'ancienne API Saved Object rendait cette tâche pénible en raison de données JSON profondément imbriquées, de modifications subtiles d'une version à l'autre et de références instables. Il nous fallait une approche différente

Une API spécialement conçue pour la création de tableaux de bord par programme

La nouvelle API Dashboards a été conçue exactement pour ce scénario. Au lieu d'exposer l'état interne brut, elle propose des schémas typés et validés pour chaque type de panneau. L'API gère la traduction entre des structures externes claires et les représentations internes de Kibana, afin que l'agent puisse se concentrer sur ce que le tableau de bord doit contenir plutôt que sur sa mise en forme.

Un seul skill, un seul outil, de nombreuses opérations

Le skill dashboard-management un seul outil manage_dashboard qui accepte un tableau ordonné d'opérations. Chaque opération est une action discrète : définir les métadonnées, ajouter un panneau Markdown, créer des visualisations basées sur ES|QL à partir du langage naturel, modifier des panneaux existants, regrouper les panneaux en sections repliables ou repositionner les éléments sur la grille.

L'agent peut décrire un tableau de bord entier : titre, description, sections et tous les panneaux qui les composent en un seul appel :

Les opérations s'exécutent dans l'ordre, de sorte que les étapes ultérieures peuvent faire référence et s'appuyer sur les précédentes. Cette conception permet de concentrer la conversation sur l'intention plutôt que sur les détails de mise en œuvre.

Pipeline de visualisation : du langage naturel à ES|QL et aux visualisations

Lorsque vous demandez un tableau de bord, l'agent explore vos données – index, mappings de champs, types – puis planifie les visualisations et appelle manage_dashboard.

Chaque panneau s'exécute via son propre pipeline : sélection du type de graphique, génération ES|QL, configuration de la visualisation et validation. Nous avons isolé ce processus du fil principal de l'agent. En effet, la création de la visualisation nécessiterait plusieurs appels au modèle par panneau, et l'intégrer au contexte principal alourdirait la fenêtre et rendrait le raisonnement moins clair.

Dans manage_dashboard, tous les panneaux sont créés simultanément, puis réassemblés dans l'ordre. Le résultat est un tableau de bord complet avec des panneaux intégrés ; pas de visualisations orphelines, pas de problèmes de synchronisation.

Pourquoi avez-vous déplacé la création de visualisations à l'intérieur de l'outil de tableau de bord ?

Dans un premier temps, nous avons utilisé un outil create_visualization distinct : un appel par panneau, puis un transfert manuel de chaque élément vers l'outil de tableau de bord. Cela fonctionnait, mais chaque visualisation nécessitait son propre appel d'outil, son propre cycle de vie et un transfert explicite. Pire encore, la modification d'une visualisation dans la conversation ne mettait pas à jour le panneau du tableau de bord, ce qui semait la confusion chez les utilisateurs.

Nous avons intégré la création de visualisations directement dans manage_dashboard. Les mêmes workflows parallèles s'exécutent, mais les panneaux s'assemblent directement dans la structure du tableau de bord sans passer par des pièces jointes intermédiaires. Moins d'appels, aucun problème de synchronisation, un seul cycle de vie.

Les visualisations autonomes fonctionnent toujours (vous pouvez ajouter des graphiques existants à un tableau de bord via des références de pièces jointes), mais pour créer du contenu à partir de zéro, la création intégrée est la solution la plus simple.

Pour les équipes de sécurité

Les analystes SOC et les ingénieurs en détection n'ont pas le temps de faire des allers-retours vers l'éditeur de tableau de bord en pleine investigation. Avec AI Chat, demandez le volume d'alertes par type de règle, par hôte ou par tactique MITRE, et consultez-le dans votre fil de discussion en une minute environ. Au fur et à mesure que l'enquête avance, ajoutez des panneaux – anomalies d'exécution des processus, connexions réseau, comparaisons chronologiques – sans perdre le contexte.

Enregistrez lorsque vous avez terminé. Le tableau de bord servira alors de référence pour l'analyse post-incident, de point de départ pour le prochain analyste ou de compte rendu hebdomadaire sur les menaces, sans qu'il soit nécessaire de tout réexpliquer.

Pour en savoir plus sur la façon dont les équipes de sécurité peuvent utiliser la création de tableaux de bord et d'autres fonctionnalités d'AI Chat récemment lancées, consultez cet article de blog.

Pour les ingénieurs en observabilité et fiabilité des sites (SRE)

Lorsqu'un service se dégrade à 2 heures du matin, on n'a pas le temps de créer des tableaux de bord à partir de zéro. Avec AI Chat, un ingénieur SRE peut décrire les métriques dont il a besoin (latence p99 par service, taux d'erreur par rapport aux événements de déploiement, redémarrages de pods au cours de la dernière heure) et obtenir un tableau de bord complet dans le fil de discussion dédié à l'investigation en une minute environ. L'agent peut l'affiner étape par étape à mesure que la situation se précise : ajouter un panneau, modifier la fenêtre temporelle, ventiler les données par région.

Enregistrez le tableau de bord ; il sera immédiatement accessible dans la salle de crise (mêmes panneaux, même mise en page) pour tous les participants à la réunion de gestion de l'incident. Une fois l'incident terminé, il servira de base à l'analyse rétrospective.

Prochaines étapes

Nous travaillons à l'optimisation des jetons, à des interactions plein écran plus riches, à la prise en charge d'un plus grand nombre de panneaux et à l'amélioration continue de la qualité. Le préversion technique est le bon moment pour définir les priorités. S'il manque quelque chose, dites-le-nous via l'icône "Envoyer des commentaires" dans le menu supérieur.

Faites l'essai

Passez à Elastic 9.4 (ou démarrez un essai), ouvrez AI Chat en mode plein écran et essayez-le sur une enquête réelle. Demandez à l'agent de tracer les métriques que vous examinez, puis demandez la ventilation suivante. Lorsque le récit se tient, enregistrez et partagez – mêmes panneaux, même cadrage, aucune ré-explication nécessaire. Nécessite une licence d'entreprise (prise en main). La sortie et le calendrier des fonctionnalités décrites dans cet article restent à la seule discrétion d'Elastic. Toutes les caractéristiques ou fonctionnalités non disponibles actuellement peuvent ne pas être livrées à temps, voire pas du tout.

Comment Kibana récupère les données lors du chargement d'un tableau de bord

Lorsqu'un tableau de bord est ouvert, la plupart des panneaux, (en interne, nous les appelons panneaux intégrables) lancent une ou plusieurs requêtes Elasticsearch. Mais au lieu du simple échange d'appels et de réponses d'une recherche synchrone (sync), nous utilisons la puissance de la recherche asynchrone (async) (documentation).

Avec la recherche asynchrone, les résultats des requêtes restent disponibles dans Elasticsearch en dehors de toute requête HTTP particulière. Ce point est important, car il

• rend le chargement des données résistant aux perturbations du réseau.

• alimente notre fonctionnalité de recherche en arrière-plan, qui permet aux utilisateurs de travailler sur d'autres éléments dans Kibana pendant qu'ils attendent la fin d'une session de tableau de bord ou Discover de longue durée.

Une fois la requête initiale envoyée, Kibana surveille la recherche pour détecter sa fin et récupérer l'ensemble des résultats.

Comment l'interrogation classique affecte les temps de chargement du tableau de bord Kibana

Dans le système d'interrogation traditionnel, Kibana envoie une requête, ferme la connexion initiale, puis vérifie périodiquement auprès d'Elasticsearch si l'opération est terminée.

Après l'envoi d'une requête, Elasticsearch dispose d'un court laps de temps pour effectuer la recherche et renvoyer les résultats. Si la recherche s'achève rapidement, il s'agit d'un simple échange de données. En revanche, pour les recherches plus longues, la connexion initiale est fermée et Kibana vérifie régulièrement l'état d'avancement de la recherche. Ce processus est appelé interrogation.

Inconvénients de l'interrogation classique en termes de performance

Si vous observez la figure ci-dessus, vous pouvez constatez peut-être l'inconvénient de cette approche en termes de performances : la recherche a de fortes chances de se terminer pendant l'un des intervalles d'inactivité de Kibana, ce qui entraîne une perte de temps.

Dans le pire des cas (lorsqu'une recherche se termine au début d'une période d'inactivité), toute la durée de l'intervalle d'interrogation sera perdue.

L'impact d'une stratégie de temporisation

Il est d'usage, lors des interrogations, d'appliquer une stratégie de temporisation. Cela signifie que plus la durée de la recherche est longue, moins les interrogations sont fréquentes.

Toutefois, cela signifie également que le temps potentiellement perdu est proportionnel à la durée de la recherche.

Comment les intervalles d'interrogation créent des schémas de latence en dents de scie

En rassemblant ces facteurs, notre temps perdu devient une fonction en dents de scie par paliers.

Ici, les pics représentent les scénarios les plus défavorables et les creux les scénarios les plus favorables. Cela montre que le coût d'un système d'interrogation traditionnel varie de zéro à la durée totale de l'intervalle d'interrogation, selon la durée de la recherche (et les conditions du réseau).

Interrogation continue : comment Kibana élimine les temps d'attente

Le problème avec les interrogations classiques est le manque fondamental de coordination entre Kibana et Elasticsearch. Idéalement, Kibana devrait être informé immédiatement de la disponibilité des résultats. Et si l'on inversait le schéma d'interrogation pour que la quasi-totalité du temps soit consacrée à la vérification d'Elasticsearch, sans aucune interruption ?

Avec cette combinaison d'interrogations de longue durée et d'absence de périodes de veille, les résultats sont transmis dès qu'ils sont prêts.

Dégradation HTTP/1

La théorie tient la route. Alors pourquoi ce déploiement Kibana semble-t-il si dégradé lorsque nous activons l'interrogation continue ?

Le point important est que ce déploiement s'exécute sur HTTP/1. Avec HTTP/1, les requêtes HTTP sont associées une à une à des connexions TCP. Par conséquent, plusieurs requêtes d'interrogation de longue durée monopolisent le nombre limité de connexions du navigateur, ce qui entraîne la mise en file d'attente d'autres requêtes.

En revanche, avec HTTP/2+, les requêtes réseau peuvent partager des connexions TCP via le multiplexage, ce qui nous évite ce problème.

Ainsi, sur HTTP/2+, l'interrogation continue est une vertu, mais sur HTTP/1, elle devient un vice.

HTTP/1

HTTP/2+

Connexions TCP

Une par requête HTTP

Multiplexée (plusieurs requêtes partagent les mêmes connexions)

Comportement de l'interrogation continue

Dégrade les performances (saturation du pool de connexions)

Bénéfice complet (résultats immédiats)

Comment Kibana détecte le protocole HTTP pour une interrogation optimale

HTTP/2 est le protocole recommandé et celui par défaut de Kibana depuis la version 9.0 ; il serait donc dommage de ne pas intégrer cette amélioration des performances. En revanche, l'expérience utilisateur avec HTTP/1 est tellement dégradée qu'il est inacceptable de prendre le risque de l'utiliser sur les déploiements sur site dont le protocole n'a pas encore été mis à niveau. La solution est claire : nous devons détecter le protocole utilisé et appliquer la stratégie d'interrogation optimale.

Il est tout à fait possible que le serveur Kibana sache quel protocole il utilise. Cependant, il y a un hic : le facteur limitant est le pool de connexions du navigateur. Autrement dit, ce qui compte vraiment, c'est le protocole utilisé par le navigateur.

En raison des proxys, ceux-ci ne sont pas toujours identiques.

Si nous basons notre optimisation sur le protocole du serveur, nous pourrions nous tromper de deux manières.

1. Appliquer une interrogation continue à tort et dégrader l'expérience utilisateur.

2. Ne pas parvenir à appliquer une interrogation continue quand il le faudrait et passer à côté de l'optimisation.

Heureusement, les navigateurs modernes permettent de détecter le protocole du dernier saut réseau de toute requête terminée grâce à l'utilisation de PerformanceObserver. Ainsi, nous surveillons le protocole du premier envoi de requête et optimisons en conséquence.

Résultats en laboratoire : interrogation continue et interrogation classique dans Kibana

Pour valider l'interrogation continue, nous avons créé des tableaux de bord avec des délais de requête allant de 1 à 23 secondes et mesuré les temps de chargement avec et sans l'optimisation activée. Nous avons ensuite chargé les tableaux de bord avec et sans interrogation continue pour mesurer les gains (nous nous sommes bien amusés avec la course aux prix).

Ce schéma rappelle notre diagramme en dents de scie initial. Pour certaines durées de requête, les gains sont faibles, tandis que pour d'autres, ils atteignent plusieurs secondes.

Conclusion

Cette optimisation remplace efficacement la latence inhérente à l'interrogation classique par une stratégie d'interrogation continue plus performante. La principale difficulté résidait dans la mise en œuvre conditionnelle de cette optimisation afin d'éviter toute dégradation des performances sur les déploiements HTTP/1. Nous l'avons résolue en utilisant la fonction PerformanceObserver du navigateur pour détecter de manière fiable le protocole utilisé pour le dernier saut du réseau.

Des tests en laboratoire valident cette théorie, démontrant que l'interrogation continue fournit des résultats dès qu'ils sont disponibles. En moyenne, cela se traduit par une amélioration significative de l'expérience utilisateur, avec un temps de chargement des données jusqu'à 25 % plus rapide.

Ce travail représente la dernière étape de notre engagement à réduire le délai d'accès aux informations pour nos utilisateurs. En faisant de Kibana un proxy plus transparent pour les données Elasticsearch, nous optimisons les performances dans notre domaine d'expertise. À suivre !

(En 2025, Thomas Neirynk a donné un excellent aperçu des méthodes et des motivations derrière l'amélioration des performances du tableau de bord Kibana. Ceci est une mise à jour de cette initiative.)

Qu'est-ce qu'un générateur de tableaux de bord Kibana ?

Et si vous pouviez décrire le tableau de bord que vous souhaitez en langage clair et le voir apparaître, avec des graphiques interactifs, une mise en page par glisser-déposer et une exportation vers Kibana en un clic ?

C'est exactement ce que fait example-mcp-dashbuilder. Il s'agit d'une application open source (Model Context Protocol (MCP)) qui connecte les assistants IA à Elasticsearch, vous permettant de créer des tableaux de bord Kibana complets par chat. Pas besoin de cliquer dans les menus. Pas de configurations de visualisation à écrire manuellement. Il suffit de décrire ce dont vous avez besoin, et l'IA explore vos données, écrit les requêtes en langage de requête Elasticsearch (ES|QL), construit les graphiques et propose un tableau de bord interactif en direct, le tout dans la fenêtre de chat de votre éditeur.

Du prompt au tableau de bord en quelques secondes

Voici à quoi cela ressemble concrètement. Vous tapez quelque chose comme :

"Crée-moi un tableau de bord de trafic web à partir de logstash-* avec le nombre total de requêtes, les nombre d'octets transférés au fil du temps, les principales sources géographiques et une répartition des codes de réponse"

L'IA va alors :

1. Découvre vos données : liste les index, inspecte les mappings de champs.

2. Rédige des requêtes ES|QL : adaptées à votre schéma, utilisant les bonnes agrégations.

3. Crée des visualisations : graphiques à barres, graphiques linéaires, métriques avec sparklines, cartes thermiques, graphiques circulaires.

4. Organise tout : sections pliables, titres compréhensibles, mise en page adéquate.

5. Affiche un aperçu interactif : directement dans le chat, avec des infobulles, un sélecteur de temps et un système de glisser-déposer.

Chaque graphique apparaît en ligne au fur et à mesure qu'il est créé, ce qui vous permet de voir les progrès réalisés en temps réel. Ensuite, view_dashboard affiche le tableau de bord complet avec tous les panneaux disposés dans la grille à 48 colonnes de Kibana.

Aperçu du graphique unique intégré.

Propulsé par ES|QL

Toutes les recherches de données utilisent ES|QL, le langage de requête d'Elasticsearch. L'IA ne se contente pas de traiter les requêtes brutes, elle utilise aussi une connaissance intégrée d'ES|QL ainsi que des informations sur la structure de vos données pour écrire des requêtes correctes et efficaces pour chaque type de visualisation.

Le serveur inclut une référence ES|QL complète en tant que ressource MCP. Avant d'écrire une requête, l'IA lit cette référence pour comprendre les commandes, fonctions et schémas disponibles. Associée à un guide des bonnes pratiques de visualisation de données (également utilisé comme ressource), l'IA sait non seulement comment interroger, mais aussi ce qui génère une bonne visualisation :

• Utilisez BUCKET(@timestamp, 1 day) pour les séries temporelles ; toujours SORT par le champ temporel.

• Limitez les graphiques circulaires à six tranches avec | SORT value DESC | LIMIT 6.

• Choisissez des graphiques à barres pour les comparaisons de catégories, des graphiques linéaires pour les tendances, des métriques pour les indicateurs clés de performance (KPIs).

Exploration de données pilotée par l'IA avec analyse ouverte

Créer un tableau de bord que vous avez déjà imaginé est une chose. Se demander "Qu'y a-t-il d'intéressant dans cet index?" et obtenir une réponse utile est plus difficile ; cela exige que l'IA sache explorer, et pas seulement dessiner.

Example-mcp-dashbuilder propose une ressource analysis://guidelines qui définit un flux d'exploration structuré : profiler les données, effectuer des agrégations ciblées, faire apparaître des schémas dignes d'être étudiés, créer des graphiques pour les résultats les plus intéressants et proposer des requêtes d'exploration que l'utilisateur pourrait souhaiter ensuite. Des expressions déclencheurs, telles que "analyser mes logs" ou "trouver des tendances dans cet index", incitent l'IA à lire le playbook avant toute autre action. Ainsi, une requête ouverte produit une analyse cohérente plutôt qu'une multitude de graphiques aléatoires.

Résultat : vous pouvez fournir à l'IA un index inconnu et obtenir en retour un point de départ : un tableau de bord accompagné d'une courte liste de questions du type "Voici ce que j'ai remarqué, voulez-vous que j'approfondisse certains de ces points ?".

Exportation et importation du tableau de bord Kibana : le processus complet

C'est au niveau de l'exportation/importation que example-mcp-dashbuilder devient réellement utile pour les équipes qui travaillent déjà avec Kibana. example-mcp-dashbuilder est un outil à part entière, une interface de tableau de bord conversationnelle intégrée à votre éditeur, mais qui ne confine pas votre travail à cet éditeur. Les tableaux de bord créés ici peuvent être transférés vers Kibana à votre guise, et inversement, les tableaux de bord Kibana existants peuvent être importés pour une édition assistée par l'IA.

Exporter vers Kibana

Lorsque vous êtes satisfait de votre tableau de bord, une commande permet de l'exporter :

"Exporter ce tableau de bord vers Kibana"

Chaque panneau est traduit en une véritable visualisation Kibana Lens. La traduction préserve :

• Requêtes ES|QL : transférées directement en tant que sources de données Lens ES|QL.

• Positions de la grille : le même système à 48 colonnes que celui utilisé par Kibana, votre mise en page est donc identique.

• Couleurs personnalisées : Palettes de séries, arrière-plans de métriques, rampes de couleurs de carte thermique.

Le résultat est un tableau de bord Kibana entièrement fonctionnel. Pas une capture d'écran. Pas une intégration. Un vrai tableau de bord que vous pouvez partager et continuer à modifier dans Kibana.

Tableau de bord Kibana et tableau de bord dans le chat Cursor côte à côte.

Importer depuis Kibana

L'aller-retour fonctionne également dans l'autre sens :

"Importer le tableau de bord Kibana avec l'identifiant abc-123"

Cette opération récupère un tableau de bord Kibana existant, traduit ses visualisations Lens en configurations de graphiques éditables, préserve la disposition de la grille et les sections, puis charge le tout dans example-mcp-dashbuilder. À partir de là, vous pouvez le modifier en langage naturel et le réexporter.

L'IA devient ainsi un collaborateur de votre workflow Kibana existant, sans le remplacer.

Thèmes et couleurs personnalisés

Vous souhaitez un tableau de bord personnalisé ? Il suffit de demander :

"Créer un tableau de bord à thème rose avec des couleurs personnalisées"

Chaque type de visualisation prend en charge la configuration personnalisée des couleurs :

• Graphiques : palette accepte un tableau de couleurs hexadécimales pour les séries et les tranches.

• Métriques : color définit la couleur de fond.

• Cartes thermiques : colorRamp définit le gradient, des valeurs faibles aux valeurs élevées.

L'IA interprète naturellement les demandes de thème. Par exemple, si vous dites "Thème Océan", elle choisira des bleus et des turquoises. Si vous dites "Respecter les couleurs de notre marque" et fournissez les valeurs hexadécimales, elles seront automatiquement intégrées à Kibana lors de l'exportation.

Un tableau de bord thématique avec des couleurs personnalisées.

Fonctionnement de example-mcp-dashbuilder : architecture MCP

example-mcp-dashbuilder est basé sur MCP, la norme ouverte permettant de connecter les assistants IA à des outils et données externes. Voici l'architecture générale :

Le serveur MCP expose 25 outils directement accessibles à l'IA, permettant notamment l'exécution de requêtes ES|QL et l'exportation de tableaux de bord. Il propose également quelques outils internes "application uniquement", utilisés par l'aperçu intégré pour récupérer des données, enregistrer les modifications de mise en page et détecter les champs temporels. Trois ressources sont disponibles : un guide des bonnes pratiques de visualisation des données, une documentation de référence ES|QL et un playbook d'analyse approfondie, déclenché par des prompts ouverts ("analyse mes logs", "qu'y a-t-il d'intéressant dans cet index"). Le serveur fonctionne via les E/S standard (stdio) ou HTTP. Le protocole HTTP prend en charge les réponses par flux et la gestion des sessions, permettant ainsi à plusieurs clients de se connecter simultanément.

L'application MCP est l'aperçu interactif. Elle est développée avec React, Elastic Charts, et l'interface utilisateur Elastic, le tout intégré dans un seul fichier HTML autonome. Lorsque l'IA appelle view_dashboard ou crée un graphique, l'hôte affiche ce HTML dans une iframe en sandbox. L'application communique avec le serveur exclusivement via le protocole MCP Apps, en utilisant callServerTool() sur postMessage pour récupérer les données, enregistrer les mises en page et détecter les champs temporels. Il n'y a pas de serveur local, pas de port à configurer, aucune dépendance réseau externe.

Cela signifie qu'il fonctionne avec n'importe quel client compatible MCP : Cursor, Claude Desktop, Claude.ai, VS Code avec Copilot et bien d'autres.

Quels sont les types de graphiques pris en charge par example-mcp-dashbuilder ?

Au moment de la rédaction de cet article, six types de graphiques couvrant les scénarios de tableaux de bord les plus courants sont pris en charge :

Type

Idéal pour

Exemple

À barres

Comparaison des catégories

Requêtes par source géographique

Linéaire

Tendances au fil du temps

Octets transférés par heure

Zone

Volume au fil du temps

Volume de requêtes au fil du temps

Tarte

Partie du tout (six tranches maximum)

Distribution des codes de réponse

Métrique

KPI unique avec sparkline

Nombre total de requêtes avec tendance horaire

Carte thermique

Schémas en deux dimensions

Requêtes par jour de la semaine et heure

Les tableaux de bord prennent en charge les sections pliables pour l'organisation, un sélecteur temporel avec détection automatique des champs temporels, ainsi que la possibilité d'enregistrer et de basculer entre plusieurs tableaux de bord ; les sessions de chat parallèles restent isolées les unes des autres via un dashboardId intégré à chaque appel d'outil.

Comment installer et exécuter example-mcp-dashbuilder

example-mcp-dashbuilder est open source et prêt à être utilisé. Vous aurez besoin de Node.js 22+, d'une instance Elasticsearch (locale ou Elastic Cloud) et d'un client compatible MCP.

Claude Desktop : téléchargez la dernière version .mcpb depuis GitHub Releases, et double-cliquez dessus. Claude Desktop vous demandera vos identifiants Elasticsearch.

Cursor/Claude Code/VS Code Copilot : indiquez à votre configuration MCP l'emplacement de l'archive tar publiée ; pas de clone, pas de npm install :

Définissez ES_NODE, ES_API_KEY (ou ES_USERNAME / ES_PASSWORD) et KIBANA_URL comme variables d'environnement. Si vous préférez travailler à partir de la source, clonez le dépôt et exécutez npm run setup pour lancer un assistant interactif qui gère à la fois Elasticsearch local et Elastic Cloud (Cloud ID + clé API).

Et commence à créer :

"Explorer l'index des logs et me créer le tableau de bord le plus pertinent possible ?"

L'IA prend le relais. 😉

Roadmap : nouveautés à venir concernant example-mcp-dashbuilder

Il s'agit d'une version préliminaire, et nous travaillons activement à son développement. Voici quelques axes sur lesquels nous nous concentrons :

• Autres types de graphiques : jauge, diagramme en anneau, arborescence, table de données et nuage de tags pour correspondre à toutes les capacités de Lens.

• Transférez les tableaux de bord vers Git : inscrivez les configurations des tableaux de bord dans un référentiel pour le contrôle des versions et les workflows de révision du code.

• Meilleure expérience utilisateur en cas d'erreur : commentaires plus détaillés en cas d'échec des requêtes ES|QL, avec des suggestions de solutions courantes.

• Flux d'analyse plus riches : extension du playbook d'analyse approfondie pour couvrir davantage de formes de données (logs, métriques, traces).

Nous serions ravis de savoir ce que vous allez en faire. Essayez-le, signalez les problèmes et faites-nous savoir quelles visualisations et quels workflows seraient les plus utiles pour votre équipe.

GitHub : elastic/example-mcp-dashbuilder

Remerciements

Merci à Walter Rafelsberger et Tim Schnell pour leurs contributions à la mise en œuvre.

FAQ

Qu'est-ce que example-mcp-dashbuilder ? example-mcp-dashbuilder est une application MCP (Model Context Protocol) open source qui connecte les assistants IA à Elasticsearch. Il vous permet de décrire un tableau de bord Kibana en langage clair, de générer automatiquement des requêtes ES|QL, de créer des visualisations et de diffuser un tableau de bord interactif en direct dans la fenêtre de chat de votre éditeur.

Quel langage de requête example-mcp-dashbuilder utilise-t-il pour récupérer les données ? Toutes les récupérations de données utilisent ES|QL, le langage de requête canalisé d'Elasticsearch. Le serveur MCP inclut une référence ES|QL intégrée que l'IA lit avant d'écrire toute requête, garantissant une syntaxe correcte et des agrégations efficaces pour chaque type de visualisation.

Puis-je exporter vers Kibana des tableaux de bord créés avec example-mcp-dashbuilder ? Oui. L'exécution de "Exporter ce tableau de bord vers Kibana" traduit chaque panneau en une véritable visualisation Kibana Lens, préservant les requêtes ES|QL, la mise en page de la grille à 48 colonnes, les couleurs personnalisées et les palettes de séries. Le résultat est un tableau de bord Kibana entièrement fonctionnel, et non une capture d'écran ou une intégration.

Puis-je importer un tableau de bord Kibana existant dans example-mcp-dashbuilder pour une édition assistée par l'IA ? Oui. Il suffit de fournir l'identifiant du tableau de bord Kibana pour le récupérer, convertir ses visualisations Lens en configurations de graphique modifiables et les charger dans example-mcp-dashbuilder. Vous pouvez ensuite modifier le tableau de bord en langage naturel et le réexporter vers Kibana.

Quels sont les clients MCP compatibles avec example-mcp-dashbuilder ? example-mcp-dashbuilder fonctionne avec n'importe quel client compatible MCP, y compris Cursor, Claude Desktop, Claude.ai, et VS Code avec Copilot. Il prend en charge les protocoles stdio et HTTP, sans aucun serveur local ni configuration de port nécessaire.

Quels sont les types de graphiques pris en charge par example-mcp-dashbuilder ? La version actuelle prend en charge six types de graphiques : à barres, linéaire, à aires, en camembert, métriques (avec sparkline) et cartes thermiques. Les ajouts prévus incluent les graphiques à jauge, en anneau, arborescents, tables de données et nuages de tags afin de correspondre à l'ensemble des fonctionnalités de Kibana Lens.

De quoi ai-je besoin pour exécuter example-mcp-dashbuilder ? Vous avez besoin de Node.js 22 ou version ultérieur, d'une instance Elasticsearch (locale ou Elastic Cloud) et d'un client compatible MCP. Définissez les variables d'environnement ES_NODE, ES_API_KEY (ou ES_USERNAME/ES_PASSWORD) et KIBANA_URL. Pour Claude Desktop, téléchargez le fichier .mcpb depuis les versions GitHub et double-cliquez dessus pour l'installer.

Qu'est-ce que les contrôles variables ?

Si vous avez déjà travaillé avec des tableaux de bord Kibana, vous connaissez probablement nos contrôles de tableau de bord classiques : ces menus déroulants pratiques affichent des valeurs extraites de vos données pour vous permettre de les filtrer en quelques clics.

Les contrôles variables semblent similaires à première vue, mais ils comportent une particularité astucieuse : au lieu de filtrer automatiquement chaque panneau de votre tableau de bord, ils peuvent être directement intégrés dans des requêtes ES|QL au sein de visualisations individuelles.

Cela signifie que vous décidez où chaque contrôle s'applique. Mieux encore, vous pouvez les utiliser pour toutes sortes de choses, comme ajuster les intervalles de temps, changer les champs de répartition ou modifier les paramètres de visualisation à la volée. En résumé, ils offrent une expérience véritablement interactive pour vos tableaux de bord et permettent ainsi d'obtenir des informations plus rapidement et plus facilement.

Cas d'utilisation des contrôles variables

Les contrôles variables semblent utiles, mais qu'offrent-ils vraiment ? Voici quelques exemples de la manière dont ils améliorent vos tableaux de bord :

Filtrez les visualisations sélectionnées

Vous souhaitez filtrer certaines visualisations seulement ? C'est possible avec les contrôles variables. Choisissez les panneaux sur lesquels vous souhaitez agir et connectez-les dans les requêtes ES|QL à l'origine de vos visualisations.

Sélectionnez différents intervalles de temps

Donnez à vos utilisateurs la possibilité de choisir entre « 5 minutes », « 1 heure », « 1 jour », ou tout autre intervalle temporel souhaité. Créez un contrôle variable avec des intervalles prédéfinis et connectez-le à votre requête de série temporelle.

Modifier les fonctions

Au lieu de créer plusieurs graphiques pour chaque opération, les utilisateurs du tableau de bord peuvent choisir s'ils veulent voir le maximum, la moyenne, différents centiles ou tout autre agrégateur.

Grouper par différents champs

Il est parfois nécessaire de décomposer les données selon différents facteurs lors d'une enquête. Grâce aux contrôles variables, vous pouvez définir plusieurs champs « grouper par » et permettre aux utilisateurs du tableau de bord de choisir celui qui les aidera à obtenir les informations souhaitées.

Comment faire ?

Le moyen le plus simple (et probablement le plus agréable) de créer un contrôle variable est directement depuis l'éditeur de requêtes ES|QL dans votre visualisation. Commencez simplement à taper votre requête, utilisez le menu de saisie automatique et Kibana vous fournira la structure de contrôle nécessaire.

Mais si vous préférez partir de la variable elle-même, vous pouvez également aller dans : Add panel → Controls → Variable control (Ajouter un panneau → Contrôles → Contrôle de variable) et ajouter la variable à vos visualisations après avoir créé le contrôle.

Exemple 1 : Contrôle de filtrage avec sélection à valeurs multiples

1. Choisissez une visualisation alimentée par une requête ES|QL et cliquez sur « Create control » (Créer un contrôle) dans la clause WHERE

2. Vous serez automatiquement redirigé vers le menu de création de variable, où le type « Values from a query » (Valeurs d’une requête) sera sélectionné pour vous, et le nom de la variable déjà pré-rempli. N’oubliez pas que le nom d’un contrôle doit toujours commencer par « ?... » pour fonctionner dans la requête de visualisation.

Vous aurez traditionnellement besoin d'une requête comme celle-ci pour obtenir les valeurs d'un champ et les mettre à jour selon l'intervalle de temps sélectionné dans le tableau de bord :

3. Lorsque vous enregistrez le contrôle, vous le verrez apparaître en haut du tableau de bord et votre requête de visualisation sera mise à jour avec le nom du contrôle variable.

4. Si vous souhaitez ajouter une sélection à valeurs multiples au contrôle, vous devez utiliser la fonction MV_CONTAINS dans la requête et sélectionner « Allow multiple selections » (Autoriser les sélections multiples) lors de la création du contrôle à l’étape 2 (disponible à partir de la version 9.3).

Exemple 2 : contrôle de l'intervalle de temps

Si vous créez une série temporelle, vous pouvez facilement ajouter un contrôle variable pour l'intervalle de votre histogramme de dates :

1. Lors de la rédaction d'une requête ES|QL pour votre série temporelle, cliquez sur « Create control » (Créer un contrôle). Lorsque vous créez une variable pour des intervalles, il est préférable d'utiliser TBUCKET au lieu de BUCKET pour prendre en charge des intervalles plus lisibles tels que « 1 heure », « 1 jour », etc. Une option automatique sera bientôt disponible pour TBUCKET afin qu'il puisse s'adapter automatiquement aux périodes de temps.

2. Définissez les intervalles pour remplir les options dans le menu déroulant.

3. Sélectionnez différents intervalles dans le menu déroulant et observez comment votre visualisation change.

Exemple 3 : variables pour les fonctions

1. Créez une variable en utilisant le type de contrôle « Static values » (Valeurs statiques) et ajoutez des noms de fonctions à vos valeurs déroulantes. Il est important d'utiliser un nom de variable qui commence par « ??… » pour remplacer les fonctions.

2. Incluez le nom de la variable dans votre requête ES|QL.

Exemple 4 : variables pour les champs

1. Vous pouvez utiliser le type de contrôle « Static values » (Valeurs statiques) et indiquer les noms des champs que vous souhaitez. Le nom de variable doit commencer par « ??… » pour les champs.

2. Référencez la variable souhaitée dans la requête de visualisation.

Contrôles variables dans Discover

Les contrôles variables ne sont pas seulement une fonctionnalité du tableau de bord. Ils sont également disponibles directement dans l'éditeur ES|QL de Discover. Vous pouvez créer des contrôles pour accélérer l'exploration des données dans Discover, les intégrer au tableau de bord et inversement.

Détails techniques

Vous avez probablement remarqué que les contrôles de variables sont assortis de quelques règles, telles que les éléments d'une requête auxquels ils peuvent faire référence et les préfixes que vous devez utiliser (« ?... » pour les valeurs et « ??... » pour les champs ou les fonctions). En effet, les variables ne sont pas de simples remplacements de chaînes effectués sur le client. Ce sont des éléments essentiels du langage de requête (connus sous le nom de paramètres dans ES|QL).

Cette conception apporte de grands avantages. D'une part, Kibana peut comprendre le contexte de chaque variable, ce qui nous permet de générer et de pré-remplir automatiquement sa configuration pour vous. C’est aussi beaucoup plus sécurisé : le langage valide strictement les entrées variables et empêche ainsi les injections malveillantes tout en signalant toute erreur. De plus, il améliore les performances et la stabilité en transférant la validation complexe et la gestion des erreurs vers le serveur plutôt que vers le client. Une note sur les performances : une bonne pratique consiste à créer des variables qui incluent des requêtes rapides, car elles se chargent avant le tableau de bord. Ainsi, des requêtes lentes peuvent affecter les performances globales du tableau de bord.

Bien sûr, cette architecture présente aussi quelques limites, pour le moment. Les variables ne prennent pas encore en charge l'option « Tout » pour le filtrage, et elles ne peuvent actuellement pas être utilisées avec certains opérateurs tels que LIKEou FROM (pour changer de source de données). La bonne nouvelle ? Nous travaillons activement à l'ajout de ces fonctionnalités.

Ce que l'avenir réserve aux contrôles

Nous ne nous arrêtons pas là ! Parmi les améliorations que nous suivons de près, citons :

✨ La possibilité de placer des contrôles n'importe où sur le tableau de bord

✨ Chaînage de vos contrôles, ce qui signifie que la sortie d'un contrôle devient l'entrée du suivant

✨ De meilleures options de sélection comme la sélection « Tout » pour les variables

✨ Nouveaux types de contrôle (contrôle de type rechercher et variables pour vos sources de données)

✨ Et d'autres améliorations de l'expérience utilisateur que vous avez demandées, comme le pré-filtrage des contrôles normaux

Si vous avez des idées ou des commentaires, n'hésitez pas à nous en faire part.

Dans cet article, nous allons y parvenir. Nous allons créer une application qui prend une image d'un tableau de bord, analyse nos mappings et génère un tableau de bord sans que nous ayons à toucher à Kibana !

Les étapes:

1. Contexte & flux de travail de l'application

2. Préparer les données

3. Configuration LLM

4. Fonctions d'application

Contexte & flux de travail de l'application

La première idée qui m'est venue à l'esprit a été de laisser le LLM générer l'ensemble des objets sauvegardés au format NDJSON dans Kibana, puis de les importer dans Kibana.

Nous avons essayé une poignée de modèles :

• Gemini 2.5 pro

• GPT o3 / o4-mini-high / 4.1

• Sonnet de Claude 4

• Grok 3

• Deepseek (Deepthink R1)

En ce qui concerne les messages-guides, nous avons commencé par une phrase simple :

Bien que nous ayons parcouru des exemples en quelques images et des explications détaillées sur la manière de construire chaque visualisation, nous n'avons pas eu de chance. Si vous êtes intéressé par cette expérimentation, vous pouvez trouver des détails ici.

Le résultat de cette approche était l'apparition de ces messages lorsque l'on essayait de télécharger vers Kibana les fichiers produits par le LLM :

Cela signifie que le JSON généré est invalide ou mal formaté. Les problèmes les plus fréquents étaient que le LLM produisait des NDJSON incomplets, des paramètres hallucinants ou retournait du JSON normal au lieu de NDJSON, même si nous essayions de faire en sorte qu'il en soit autrement.

Inspirés par cet article - où les modèles de recherche ont mieux fonctionné que le LLM freestyle - nous avons décidé de donner des modèles au LLM au lieu de demander de générer le fichier NDJSON complet et ensuite nous, dans le code, utilisons les paramètres donnés par le LLM pour créer les visualisations appropriées.

Le processus de candidature sera le suivant :

Nous omettons une partie du code pour des raisons de simplicité, mais vous pouvez trouver le code de travail de l'application complète sur ce carnet.

Produits requis

Avant de commencer à développer, vous aurez besoin des éléments suivants :

1. Python 3.8 ou supérieur

2. Un environnement Venv Python

3. Une instance Elasticsearch en cours d'exécution, ainsi que son point d'accès et sa clé API

4. Une clé d'API OpenAI stockée dans la variable d'environnement OPENAI_API_KEY :

Préparer les données

Pour les données, nous resterons simples et utiliserons les journaux web de l'échantillon Elastic. Pour savoir comment importer ces données dans votre cluster , cliquez ici.

Chaque document contient des informations sur l'hôte qui a envoyé des demandes à l'application, ainsi que des informations sur la demande elle-même et l'état de sa réponse. Vous trouverez ci-dessous un exemple de document :

Prenons maintenant les mappings de l'index que nous venons de charger, kibana_sample_data_logs:

Nous allons transmettre les mappings avec l'image que nous chargerons plus tard.

Configuration LLM

Configurons le LLM pour qu'il utilise la sortie structurée afin d'entrer une image et de recevoir un JSON contenant les informations que nous devons transmettre à notre fonction pour produire les objets JSON.

Nous installons les dépendances :

Elasticsearch nous aidera à récupérer les mappages d'index. Pydantic nous permet de définir des schémas en Python pour demander au LLM de les suivre, et LangChain est le cadre qui facilite l'appel aux LLM et aux outils d'IA.

Nous allons créer un schéma pydantique pour définir les résultats que nous voulons obtenir du LLM. Ce que nous devons savoir à partir de l'image, c'est le type de graphique, le champ, le titre de la visualisation et le titre du tableau de bord :

Pour la saisie de l'image, nous enverrons un tableau de bord que je viens de dessiner :

Nous déclarons maintenant l'appel au modèle LLM et le chargement de l'image. Cette fonction recevra les mappings de l'index Elasticsearch et une image du tableau de bord que nous voulons générer.

Avec with_structured_output, nous pouvons utiliser notre schéma Pydantic Dashboard comme objet de réponse que le LLM produira. Avec Pydantic, nous pouvons définir des modèles de données avec validation, ce qui garantit que la sortie LLM correspond à la structure attendue.

Pour convertir l'image en base64 et l'envoyer en entrée, vous pouvez utiliser un convertisseur en ligne ou le faire en code.

Le LLM connaît déjà le contexte des tableaux de bord Kibana, nous n'avons donc pas besoin de tout expliquer dans l'invite, juste quelques détails pour s'assurer qu'il n'oublie pas qu'il travaille avec Elasticsearch et Kibana.

Décortiquons l'invitation :

Section

Raison

Vous êtes un expert en analyse de tableaux de bord Kibana à partir d'images pour la version 9.0.0 de Kibana.

En insistant sur le fait qu'il s'agit d'Elasticsearch et de la version d'Elasticsearch, nous réduisons la probabilité que le LLM hallucine des paramètres anciens/invalides.

Vous recevrez une image de tableau de bord et un mappage d'index Elasticsearch.

Nous expliquons que l'image concerne les tableaux de bord afin d'éviter toute interprétation erronée de la part du LLM.

Vous trouverez ci-dessous les correspondances d'index pour l'index sur lequel le tableau de bord est basé, ce qui vous aidera à comprendre les données et les champs disponibles. Mappages d'index : {index_mappings}

Il est essentiel de fournir les correspondances afin que le LLM puisse sélectionner les champs valides de manière dynamique. Sinon, nous pourrions coder en dur les correspondances ici, ce qui est trop rigide, ou compter sur le fait que l'image contienne les bons noms de champs, ce qui n'est pas fiable.

N'incluez que les champs pertinents pour chaque visualisation, en fonction de ce qui est visible dans l'image.

Nous avons dû ajouter ce renforcement parce qu'il arrive que l'on essaie d'ajouter des champs qui ne sont pas pertinents pour l'image.

Cela renvoie un objet contenant un tableau de visualisations à afficher :

Traitement de la réponse au mécanisme d'apprentissage tout au long de la vie

Nous avons créé un exemple de tableau de bord 2x2 panneaux à l'adresseet l'avons exporté en JSON à l'aide de l'API Get a dashboard, puis nous avons stocké les panneaux en tant que modèles de visualisation (camembert, barre, métrique) dans lesquels nous pouvons remplacer certains paramètres pour créer de nouvelles visualisations avec différents champs en fonction de la question.

Vous pouvez consulter les fichiers JSON du modèle ici. Notez que nous avons modifié les valeurs de l'objet que nous voulons remplacer plus tard par {variable_name}

Grâce aux informations fournies par le mécanisme d'apprentissage tout au long de la vie, nous pouvons décider du modèle à utiliser et des valeurs à remplacer.

fill_template_with_analysis recevra les paramètres pour un seul panneau, y compris le modèle JSON de la visualisation, un titre, un champ et les coordonnées de la visualisation sur la grille.

Ensuite, il remplacera les valeurs du modèle et renverra la visualisation JSON finale.

Pour faire simple, nous aurons des coordonnées statiques que nous assignerons aux panneaux que le LLM décidera de créer et nous produirons un tableau de bord à grille 2x2 comme l'image ci-dessus.

En fonction du type de visualisation décidé par le LLM, nous choisirons un modèle de fichier JSON et remplacerons les informations pertinentes à l'aide de fill_template_with_analysis , puis nous ajouterons le nouveau panneau à un tableau que nous utiliserons ultérieurement pour créer le tableau de bord.

Lorsque le tableau de bord est prêt, nous utilisons l'API Create a dashboard pour envoyer le nouveau fichier JSON à Kibana afin de générer le tableau de bord :

Pour exécuter le script et générer le tableau de bord, exécutez la commande suivante dans la console :

Le résultat final sera le suivant :

Conclusion

Les LLM démontrent leurs fortes capacités visuelles lorsqu'ils transforment du texte en code ou des images en code. L'API des tableaux de bord permet également de transformer des fichiers JSON en tableaux de bord, et avec un LLM et un peu de code, nous pouvons transformer des images en tableau de bord Kibana.

L'étape suivante consiste à améliorer la flexibilité des visuels des tableaux de bord en utilisant différents paramètres de grille, différentes tailles de tableau de bord et différentes positions. De plus, la prise en charge de visualisations et de types de visualisation plus complexes serait un ajout utile à cette application.

Différences par rapport à la première analyse Spotify Wrapped

Dans le premier blog, nous avons utilisé l'export Spotify directement et n'avons effectué aucune tâche de normalisation ni aucun autre traitement de données. Cette fois-ci, nous utiliserons les mêmes données, mais nous les traiterons pour les rendre plus utilisables. Cela nous permettra de répondre à des questions beaucoup plus complexes, comme par exemple :

• Quelle est la durée moyenne d'une chanson dans mon top 100 ?

• Quelle est la popularité moyenne d'une chanson dans mon top 100 ?

• Quelle est la durée médiane d'écoute d'une chanson ?

• Quelle est la piste que je saute le plus souvent ?

• Quand est-ce que j'aime sauter des pistes ?

• Suis-je plus attentif à une heure particulière de la journée qu'à d'autres ?

• Est-ce que j'écoute plus un jour de la semaine que les autres ?

• S'agit-il d'un mois particulièrement intéressant ?

• Quel est l'artiste dont la durée d'écoute est la plus longue ?

Spotify Wrapped est une expérience amusante chaque année, vous montrant ce que vous avez écouté cette année. Il n'indique pas les changements d'une année sur l'autre, et il se peut donc que vous passiez à côté d'artistes qui figuraient autrefois dans votre top 10, mais qui ont maintenant disparu.

Traitement des données Spotify Wrapped pour analyse

Il y a une grande différence dans la façon dont nous traitons les données dans le premier et le second message. Si vous souhaitez continuer à travailler avec les données du premier message, vous devrez tenir compte de certains changements de noms de champs et revenir à ES|QL pour effectuer certaines extractions comme hour of day à la volée.

Néanmoins, vous devriez tous être en mesure de suivre ce message. Le traitement des données est effectué dans le référentiel Spotify to Elasticsearch et consiste à demander à l'API Spotify la durée de la chanson, la popularité, ainsi qu'à renommer et à enrichir certains champs. Par exemple, le champ artist dans l'export Spotify n'est qu'une chaîne de caractères et ne représente pas les fonctionnalités ou les titres multi-artistes.

Visualiser les données de Spotify Wrapped avec des tableaux de bord

J'ai créé un tableau de bord dans Kibana pour visualiser les données. Le tableau de bord est disponible ici et vous pouvez l'importer dans votre instance Kibana. Le tableau de bord est très complet et répond à de nombreuses questions.

Examinons quelques-unes de ces questions et la manière d'y répondre ensemble !

Quelle est la durée moyenne d'une chanson dans mon top 100 ?

Pour répondre à cette question, nous pouvons utiliser Lens ou ES|QL. Explorons ces trois options. Formulons cette question correctement à la manière d'Elasticsearch. Nous voulons trouver les 100 chansons les plus populaires et calculer la durée moyenne de toutes ces chansons combinées. En termes d'Elasticsearch, il s'agit de deux agrégations :

1. Déterminer les 100 chansons les plus populaires

2. Calculez la durée moyenne de ces 100 chansons.

Lens

Dans Lens, c'est assez simple : créez un nouveau Lens, passez à une table et glissez-déposez le champ title dans la table. Cliquez ensuite sur le champ title et fixez la taille à 100, ainsi que le mode accuracy. Faites ensuite glisser le champ duration dans la table et utilisez last value, car nous n'avons besoin que de la dernière valeur de la durée de chaque chanson. Une même chanson n'aura qu'une seule durée. Au bas de cette agrégation last value se trouve un menu déroulant permettant d'obtenir une ligne de résumé. Sélectionnez average et vous obtiendrez le résumé.

ES|QL

ES|QL est un langage assez récent par rapport aux agrégations DSL &, mais il est très puissant et facile à utiliser. Pour répondre à la même question en ES|QL, vous devez écrire la requête suivante :

Laissez-moi vous guider pas à pas dans cette requête ES|QL :

1. from spotify-history - C'est le modèle d'index que nous utilisons.

2. stats duration=max(duration), count=count() by title - Il s'agit de la première agrégation, nous calculons la durée maximale de chaque chanson et le nombre de chansons. Nous utilisons max au lieu de last value comme dans la lentille, parce que ES|QL n'a pas de prénom ni de nom de famille.

3. sort count desc - Nous trions les chansons en fonction du nombre d'écoutes, de sorte que la chanson la plus écoutée se trouve en haut de la liste.

4. limit 100 - Nous limitons le résultat aux 100 premières chansons.

5. stats Average duration of the songs=avg(duration) - Nous calculons la durée moyenne des chansons.

Un mois présente-t-il un intérêt particulier pour moi ?

Pour répondre à cette question, nous pouvons utiliser Lens avec l'aide du champ d'exécution et ES|QL. Nous remarquons tout de suite qu'il n'y a pas de champ dans les données qui indique directement month, mais que nous devons le calculer à partir du champ @timestamp. Il y a plusieurs façons de procéder :

1. Utiliser un champ d'exécution pour alimenter la lentille

2. ES|QL

Je pense personnellement que ES|QL est la solution la plus propre et la plus rapide.

C'est tout, il n'y a rien d'extraordinaire à faire, nous pouvons utiliser la fonction DATE_EXTRACT pour extraire le mois du champ @timestamp et ensuite l'agréger. En utilisant la visualisation ES|QL, nous pouvons l'intégrer au tableau de bord.

Quelle est ma durée d'écoute par artiste et par an ?

L'idée sous-jacente est de voir si un artiste n'est qu'un phénomène ponctuel ou s'il est récurrent. Si je me souviens bien, Spotify n'affiche que les 5 premiers artistes de l'année. Peut-être que votre artiste numéro 6 reste le même tout le temps, ou qu'il change fortement après la 10e position ?

L'une des représentations les plus simples est le diagramme à barres en pourcentage. Nous pouvons utiliser Lens à cette fin. Suivez les étapes :

Faites glisser et déposez le champ listened_to_ms. Ce champ représente la durée d'écoute d'une chanson en millisecondes. Par défaut, Lens crée une agrégation median, ce que nous ne voulons pas, mais plutôt sum. Dans la partie supérieure, sélectionnez percentage au lieu de stacked pour le type de diagramme à barres. Pour la répartition, sélectionnez artist et dites top 10. Dans la liste déroulante Advanced, n'oubliez pas de sélectionner accuracy mode. Désormais, chaque bloc de couleur représente le nombre de fois où vous avez écouté cet artiste. En fonction de votre marqueur temporel, les barres peuvent représenter des valeurs de jours, de semaines, de mois ou d'années. Si vous souhaitez un décompte hebdomadaire, sélectionnez le site @timestamp et réglez le site mininum interval sur year. Dans mon cas, on peut dire que Fred Again.. est l'artiste que j'ai le plus écouté, près de 12% de mon temps d'écoute total ayant été consommé par Fred Again... Nous constatons également que Fred Again.. a légèrement diminué en 2024, mais que Jamie XX a largement progressé. Si l'on compare uniquement la taille des barres. Nous pouvons également constater que pendant que Billie Eilish est constamment joué dans 2024, le bar s'élargit. Cela signifie que j'ai écouté Billie Eilish plus en 2024 qu'en 2023.

Qu'en est-il des meilleurs titres par artiste et par durée d'écoute par rapport à la durée d'écoute totale ?

C'est une question qui a de la gueule. Permettez-moi d'essayer d'expliquer ce que je veux dire par là. Spotify vous informe sur la meilleure chanson d'un artiste, ou sur vos 5 meilleures chansons. C'est très intéressant, mais qu'en est-il de la décomposition d'un artiste ? Est-ce que tout mon temps est consommé par une seule chanson que je joue encore et encore, ou est-ce que ce temps est réparti de manière égale ?

Créez un nouvel objectif et sélectionnez Treemap comme type. Pour metric, même chose que précédemment : sélectionnez sum et utilisez listened_to_ms comme champ. Pour le site group by, nous avons besoin de deux valeurs. Le premier est artist et le second est title. Le résultat intermédiaire est le suivant :

Changeons cela pour le top 100 des artistes et désélectionnons le other dans le menu déroulant avancé, ainsi que l'activation du mode précision. Pour le titre, modifiez-le en top 10 et activez le mode précision. Le résultat final est le suivant :

Qu'est-ce que cela nous apprend exactement ? Sans tenir compte de la durée, on peut dire que sur l'ensemble de mon historique d'écoute avec Spotify, j'ai passé 5,67% à écouter Fred Again... En particulier, j'ai passé 1,21% de ce temps à écouter Delilah (pull me out of this). Il est intéressant de voir s'il y a une seule chanson qui occupe un artiste, ou s'il y a aussi d'autres chansons. La carte arborescente elle-même est une forme agréable pour représenter de telles distributions de données.

Est-ce que j'écoute à une heure et à un jour précis ?

Nous pouvons répondre à cette question de manière très simple grâce à une visualisation de la lentille qui exploite le site Heat Map. Créez un nouvel objectif, sélectionnez Heat Map. Pour le champ Horizontal Axis select dayOfWeek, définissez Top 7 au lieu de Top 3. Pour le Vertical Axis, sélectionnez le hourOfDay et pour le Cell Value, un simple Count of records. Cette opération permet d'obtenir ce panneau :

Il y a deux ou trois choses ennuyeuses autour de cette lentille, qui me dérangent lors de l'interprétation. Essayons d'y mettre un peu d'ordre. Tout d'abord, je ne me soucie pas trop de la légende, utilisez le symbole en haut avec le triangle, le carré, le cercle et désactivez-le.

La deuxième partie qui est gênante est le tri des jours. C'est lundi, mercredi, jeudi, ou autre chose, selon les valeurs que vous avez. Le site hourOfDay est correctement trié. La façon de trier les jours est une astuce amusante qui consiste à utiliser Filters au lieu de Top Values. Cliquez sur dayOfWeek et sélectionnez Filters, cela devrait ressembler à ceci :

Il ne vous reste plus qu'à taper les jours. Un filtre par jour. "dayOfWeek" : Monday et lui attribuer le label Monday, puis rincer et répéter.

Un bémol cependant : Spotify fournit les données en UTC+0 sans aucune information sur le fuseau horaire. Bien sûr, ils fournissent également l'adresse IP et le pays où vous avez écouté et nous pourrions en déduire les informations relatives au fuseau horaire, mais cela peut s'avérer bancal et pour des pays comme les États-Unis qui ont plusieurs fuseaux horaires, cela peut s'avérer trop fastidieux. C'est important car Elasticsearch et Kibana prennent en charge les fuseaux horaires et en fournissant le bon fuseau horaire dans le champ @timestamp, Kibana ajustera automatiquement l'heure à celle de votre navigateur.

Il devrait ressembler à ceci lorsqu'il sera finalisé, et on peut dire que je suis un auditeur très actif pendant les heures de travail et moins le samedi et le dimanche.

Conclusion

Dans ce blog, nous avons approfondi les subtilités des données de Spotify. Nous avons montré quelques moyens simples et rapides de mettre en place des visualisations. Il est tout simplement incroyable d'avoir autant de contrôle sur son propre historique d'écoute. Consultez les autres parties de la série :

• Partie 1 : Comment créer son propre Spotify Wrapped dans Kibana

• Partie 3 : Emplois de la population pour la détection des anomalies

• Partie 4 : Détecter les relations dans les données

• Partie 5 : Trouver son meilleur ami musical avec les vecteurs

Voici un diagramme de ce que nous allons configurer dans ce tutoriel :

Configuration de l'inférence locale avec Ollama

Ollama est une excellente façon de tester rapidement un ensemble de modèles open source pour l’inférence locale. C'est un outil très apprécié des développeurs en IA.

Lancer Ollama en natif

Une installation locale sur Mac, Linux ou Windows est le moyen le plus facile d’utiliser les capacités GPU que vous pourriez avoir localement, en particulier pour ceux qui possèdent des puces Apple de la série M. Après avoir installé Ollama, vous pouvez télécharger et exécuter Deepseek R1 avec la commande ci-dessous.

Vous pourriez avoir besoin d’ajuster la taille des paramètres pour qu’elle corresponde à votre matériel. Vous trouverez les tailles disponibles ici.

Il est possible de discuter avec le modèle dans le terminal, mais il continue de fonctionner même lorsque vous quittez la commande avec CTRL+d ou que vous tapez « /bye ». Pour voir que le modèle continue de fonctionner, entrez :

Exécution d'Ollama dans un conteneur

Sinon, la façon la plus rapide de faire fonctionner Ollama est d’utiliser un moteur de conteneurs comme Docker. Si l’utilisation du GPU de votre machine locale n’est pas toujours simple, selon l’environnement, la mise en place d'une configuration de test rapide est simple tant que votre conteneur a assez de RAM et d’espace de stockage pour les modèles de plusieurs Go.

Pour faire fonctionner Ollama dans Docker, il suffit d'exécuter :

Un répertoire « ollama » sera créé dans le dossier actuel, puis monté à l’intérieur du conteneur pour y conserver la configuration d’Ollama et les modèles. En fonction du nombre de paramètres employés, leur taille peut aller de quelques Go à plusieurs dizaines de Go, donc veillez à choisir un volume disposant d’un espace libre suffisant.

Remarque : si votre machine est équipée d'un GPU Nvidia, veillez à installer le kit d’outils de conteneur Nvidia et à ajouter « --gpus=all » à la commande « docker run » ci-dessus.

Dès que le conteneur Ollama fonctionne sur votre machine, vous pouvez télécharger un modèle comme deepseek-r1 en utilisant :

À l'instar de l'approche bare metal, il est possible que vous souhaitiez ajuster la taille des paramètres pour qu'elle corresponde à votre matériel. Les tailles disponibles sont indiquées sur le site https://ollama.com/library/deepseek-r1.

Une fois que l'extraction du modèle est terminée, il vous suffit de taper « /bye » pour quitter le prompt. Pour vérifier que le modèle est toujours en cours d’exécution :

Tester notre inférence locale avec une commande curl

Pour tester l'inférence locale avec curl, vous pouvez exécuter la commande suivante. Nous avons recours à stream:false pour faciliter la lecture de la réponse narrative au format JSON :

Test d’Ollama compatible OpenAI et d’une invite de RAG

Pour plus de commodité, Ollama offre également un point de terminaison REST qui imite l'interface d’OpenAI, ce qui le rend compatible avec un grand nombre d'outils, notamment Kibana.

Le test de cette invite plus complexe produit un contenu qui comporte une partie dans laquelle le modèle a été entraîné pour trouver la solution au problème.

Connexion d'Ollama à Kibana

Une excellente façon d’utiliser Elasticsearch est le script de développement « start-local ».

Veillez à ce que votre Kibana et votre Elasticsearch soient en mesure d'atteindre votre Ollama sur le réseau. Si vous avez un environnement Elastic en conteneur local, vous devrez peut-être remplacer « localhost » par « host.docker.internal ». ou « host.conteneurs.internal » afin d’avoir un chemin réseau jusqu'à la machine hôte.

Dans Kibana, accédez à Stack Management > Alertes et informations > Connecteurs.

Ce qu’il faut faire si cette alerte de configuration courante s'affiche

Vous devrez vous assurer que xpack.encryptedSavedObjects.encryptionKey est correctement défini. C'est une erreur courante lors de l'exécution d'une installation locale de Kibana sous Docker, c'est pourquoi je vais énumérer les étapes à suivre dans la syntaxe de Docker pour la corriger.

Pour que les modifications soient conservées à l’arrêt du conteneur, il faut que le répertoire kibana/config soit persistant. Mes volumes de conteneurs Kibana ressemblent à ceci dans docker-compose.yml :

Vous pouvez à présent créer le keystore et y attribuer une valeur afin que les clés des connecteurs ne soient plus stockées en clair.

Afin que les modifications soient appliquées, redémarrez l'ensemble de votre cluster.

Création du connecteur

Depuis l’écran de configuration du connecteur (dans Kibana, accédez à Stack Management > Alertes et informations > Connecteurs), créez un connecteur et sélectionnez le type « OpenAI ».

Configurez le connecteur avec les paramètres suivants

• Nom du connecteur : Deepseek (Ollama)

• Sélectionnez un fournisseur OpenAI : autre (service compatible OpenAI)

• URL : http://localhost:11434/v1/chat/completions

  • Modifiez pour indiquer le bon chemin d'accès à votre ollama. Pensez à remplacer par host.docker.internal ou son équivalent si vous appelez depuis un conteneur.

• Modèle par défaut : deepseek-r1:7b

• Clé API : inventez quelque chose, une entrée est nécessaire mais la valeur n'a pas d'importance

Notez que le test d'un connecteur personnalisé à Ollama dans la configuration du connecteur est actuellement défectueux dans la version 8.17, mais a été corrigé dans la future version 8.18 de Kibana.

Notre connecteur ressemble à ceci :

Intégration des données vectorielles dans Elasticsearch

Si vous connaissez déjà Playground et que vous y avez des données, vous pouvez passer à l'étape Playground ci-dessous. En revanche, si vous avez besoin de données de test rapides, assurez-vous que nos API d'inférence sont configurées. Depuis la version 8.17, les allocations de machine learning sont dynamiques. Pour télécharger et activer le vecteur dense multilingue e5, il suffit d’exécuter la commande suivante dans les Outils de développement de Kibana.

Si ce n'est pas déjà fait, cette opération lancera le téléchargement du modèle e5 depuis les dépôts de modèles d'Elastic.

Chargeons à présent un livre du domaine public comme contexte pour notre RAG. Voici où télécharger « Alice au pays des merveilles » depuis le Projet Gutenberg : lien. Enregistrez-le sous la forme d’un fichier .txt.

Accédez à Elasticsearch > Accueil > Télécharger un fichier

Sélectionnez ou glissez-déposez votre fichier texte, puis cliquez sur le bouton « Importer ».

Sur l'écran « Importer des données », sélectionnez l'onglet « Avancé », puis définissez le nom de l'index sur « book_alice ».

Sélectionnez l’option « Ajouter un champ supplémentaire », elle se trouve juste en dessous de « Champs créés automatiquement ». Sélectionnez « Ajouter un champ de texte sémantique » et changez le point de terminaison d’inférence en « .multilingual-e5-small-elasticsearch ». Sélectionnez Ajouter, puis Importer.

Une fois le chargement et l’inférence terminés, nous pouvons nous rendre sur Playground.

Test de RAG dans Playground

Accédez à Elasticsearch > Playground dans Kibana.

Sur l’écran du Playground, vous devriez voir une coche verte et le message « LLM Connected » (LLM connecté) qui indique qu’il existe un connecteur. Il s'agit du connecteur Ollama que nous venons de créer ci-dessus. Un guide plus complet pour Playground est accessible ici.

Cliquez sur le bouton bleu « Ajouter des sources de données » et sélectionnez l'index book_alice que nous avions fait, ou un autre index que vous avez préalablement configuré qui utilise les API d'inférence pour les plongements.

Deepseek est un modèle de chaîne de pensée présentant de fortes caractéristiques d'alignement. C'est à la fois un avantage et un inconvénient du point de vue de la RAG. L'entraînement de type « chaîne de pensée » peut aider Deepseek à rationaliser des énoncés qui semblent contradictoires dans les citations, mais le fort alignement avec les connaissances acquises lors de l'entraînement peut lui faire préférer sa propre version des faits plutôt que notre contexte. Bien qu'il parte d'une bonne intention, ce fort alignement rend les LLM difficiles à guider quand on aborde des sujets où nos connaissances privées sont en contradiction avec les données d'entraînement, ou n'y sont pas bien représentées.

Dans la configuration de notre Playground, nous avons saisi l'invite système « Vous êtes un assistant pour les tâches de questions-réponses en utilisant les passages pertinents du livre Alice au pays des merveilles » et accepté les autres paramètres par défaut.

À la question « Qui était au goûter ? » nous obtenons la réponse : « Réponse : le lièvre de mars, le chapelier et le loir étaient au goûter. [Citation : positions 1 et 2] », ce qui est exact.

Nous pouvons voir d'après les tags que Deepseek a clairement réfléchi au contenu des citations pour répondre aux questions.

Test des limites d'alignement

Pour tester Deepseek, créons un scénario qui soit un défi intellectuel. Nous allons créer un index de théories du complot que les données d'entraînement de Deepseek connaissent et qui ne sont pas vraies.

Dans les outils de développement de Kibana, créons l'index et les données suivants :

Ces théories du complot seront les données de base pour notre LLM. Même en utilisant une invite système agressive, Deepseek n’accepte pas notre version des faits. Si nos données privées étaient plus fiables, mieux ancrées ou mieux alignées sur les besoins de notre organisation, ce scénario ne serait pas acceptable

À la question test « Les oiseaux sont-ils réels ? » (explication : know your meme), nous obtenons la réponse suivante : « Dans le contexte fourni, les oiseaux ne sont pas considérés comme réels, mais en réalité, ce sont des animaux réels. » [Contexte : position 1]. Ce test prouve que DeepSeek R1 est puissant, même avec le niveau de paramètre 7B… mais ce n'est peut-être pas le meilleur choix pour la RAG, selon notre jeu de données.

Quels sont les enseignements à retenir ?

En résumé :

• L'exécution de modèles en local à l'aide d'outils comme Ollama est une excellente option pour avoir un aperçu de leur comportement.

• Le Deepseek R1 est un modèle de raisonnement qui comporte des avantages et des inconvénients pour les cas d'utilisation comme la RAG.

• Playground est en mesure de se connecter à des infrastructures d'hébergement d'inférence comme Ollama par le biais d'une API REST de type OpenAI, qui devient de facto un standard en cette période de lancement de l'hébergement de l'IA.

Globalement, nous sommes impressionnés par les progrès de la RAG locale, « air gapped ». Les outils d’Elasticsearch, de Kibana et des modèles de poids ouverts disponibles ont considérablement progressé depuis que nous avons écrit pour la première fois sur la recherche IA axée sur la confidentialité en 2023.

Importation de données géospatiales à l'aide de Kibana

Les données que nous avons utilisées pour les exemples du blog précédent étaient basées sur les données que nous utilisons en interne pour les tests d'intégration. Pour vous faciliter la tâche, nous l'avons inclus ici sous la forme de quelques fichiers CSV qui peuvent être facilement importés à l'aide de Kibana. Les données sont un mélange d'aéroports, de villes et de limites de villes. Vous pouvez télécharger les données à partir de :

• aéroports.csv

  • Il s'agit d'une fusion de trois ensembles de données :

    • Aéroports (noms, emplacements et données connexes) de Natural Earth

    • Localisation des villes à partir de SimpleMaps

    • Élévations des aéroports à partir de la base de données mondiale des aéroports

• limites_de_la_ville_de_l'aeroport.csv

  • Il s'agit d'une fusion des noms d'aéroports et de villes ci-dessus avec une nouvelle source :

    • Limites de la ville d'après OpenStreetMap

Comme vous pouvez le deviner, nous avons passé un certain temps à combiner ces sources de données dans les deux fichiers ci-dessus, dans le but de pouvoir tester les fonctionnalités géospatiales d'ES|QL. Il se peut que cela ne corresponde pas tout à fait à vos besoins spécifiques en matière de données, mais j'espère que cela vous donnera une idée de ce qui est possible. En particulier, nous voulons démontrer quelques points intéressants :

• Importation de données contenant des champs géospatiaux avec d'autres données indexables

• Importer les données geo_point et geo_shape et les utiliser ensemble dans les requêtes

• Importation de données dans deux index qui peuvent être reliés à l'aide d'une relation spatiale

• Création d'un pipeline d'ingestion pour faciliter les importations futures (au-delà de Kibana)

• Quelques exemples de processeurs d'acquisition, tels que csv, convert et split

Bien que nous parlions de travailler avec des données CSV dans ce blog, il est important de comprendre qu'il y a plusieurs façons d ' ajouter des données géographiques en utilisant Kibana. Dans l'application Carte, vous pouvez télécharger des données délimitées telles que CSV, GeoJSON et ESRI ShapeFiles et vous pouvez également dessiner des formes directement dans la carte. Pour ce blog, nous nous concentrerons sur l'importation de fichiers CSV à partir de la page d'accueil de Kibana.

Importation des aéroports

Le premier fichier, airports.csv, a quelques particularités intéressantes avec lesquelles nous devons composer. Tout d'abord, les colonnes sont séparées par des espaces blancs supplémentaires, ce qui n'est pas typique des fichiers CSV. Deuxièmement, le champ type est un champ à valeurs multiples, que nous devons diviser en champs distincts. Enfin, certains champs ne sont pas des chaînes de caractères et doivent être convertis dans le bon type. Tout cela peut être fait en utilisant la fonction d'importation CSV de Kibana.

Commencez par la page d'accueil de Kibana. Une section intitulée "Get started by adding integrations" contient un lien intitulé "Upload a file":

En cliquant sur ce lien, vous accéderez à la page "Upload file". Ici, vous pouvez faire glisser et déposer le fichier airports.csv, et Kibana analysera le fichier et vous présentera un aperçu des données. Il aurait dû détecter automatiquement que le délimiteur était une virgule et que la première ligne était la ligne d'en-tête. Cependant, il n'a probablement pas supprimé les espaces blancs supplémentaires entre les colonnes, ni déterminé les types de champs, en supposant que tous les champs sont soit text, soit keyword. Nous devons y remédier.

Cliquez sur Override settings et cochez les cases Should trim fields et Apply pour fermer les paramètres. Nous devons maintenant fixer les types de champs. Elle est disponible à la page suivante, alors cliquez sur Import.

Choisissez d'abord un nom d'index, puis sélectionnez Advanced pour accéder à la page des mappages de champs et du processeur d'ingestion.

Ici, nous devons apporter des modifications aux mappages de champs pour l'index, ainsi qu'au pipeline d'ingestion pour l'importation des données. Tout d'abord, alors que Kibana a probablement auto-détecté le champ scalerank comme étant long, il a perçu par erreur les champs location et city_location comme étant keyword. Modifiez-les à l'adresse geo_point, et vous obtiendrez des correspondances qui ressembleront à quelque chose de semblable :

Vous disposez d'une certaine marge de manœuvre, mais sachez que le type de champ choisi aura une incidence sur la manière dont il sera indexé et sur le type de requêtes possibles. Par exemple, si vous laissez location comme keyword, vous ne pouvez pas effectuer de recherches géospatiales sur ce site. De même, si vous laissez elevation en tant que text, vous ne pouvez pas effectuer de requêtes sur les plages numériques.

Il est maintenant temps de réparer le pipeline d'ingestion. Si Kibana a détecté automatiquement scalerank comme long ci-dessus, il aura également ajouté un processeur pour convertir le champ en long. Nous devons ajouter un processeur similaire pour le champ elevation, en le convertissant cette fois en double. Modifiez le pipeline pour vous assurer que cette conversion est en place. Avant de l'enregistrer, nous souhaitons effectuer une autre conversion, afin de diviser le champ type en plusieurs champs. Ajouter un processeur split au pipeline, avec la configuration suivante :

Le pipeline d'ingestion final devrait ressembler à ceci :

Notez que nous n'avons pas ajouté de processeur de conversion pour les champs location et city_location. Cela s'explique par le fait que le type geo_point dans la correspondance des champs comprend déjà le format WKT des données de ces champs. Le type geo_point peut comprendre une série de formats, notamment WKT, GeoJSON, etc. Si nous avions, par exemple, deux colonnes dans le fichier CSV pour latitude et longitude, nous aurions dû ajouter un processeur script ou set pour les combiner en un seul champ geo_point (par exemple. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Nous sommes maintenant prêts à importer le fichier. Cliquez sur Import et les données seront importées dans l'index avec les mappings et le pipeline d'ingestion que nous venons de définir. Si des erreurs surviennent lors de l'ingestion des données, Kibana les signale ici, afin que vous puissiez modifier les données sources ou le pipeline d'ingestion et réessayer.

Remarquez qu'une nouvelle ligne d'ingestion a été créée. Il peut être consulté en allant dans la section Stack Management de Kibana, et en sélectionnant Ingest pipelines. Ici, vous pouvez voir le pipeline que nous venons de créer et le modifier si nécessaire. En fait, la section Ingest pipelines peut être utilisée pour créer et tester des pipelines d'ingestion, une fonctionnalité très utile si vous prévoyez d'effectuer des ingérences encore plus complexes.

Si vous souhaitez explorer ces données immédiatement, passez aux sections suivantes, mais si vous souhaitez également importer les limites des villes, continuez à lire.

Importation des limites de la ville

Le fichier des limites des villes disponible à l'adresse airport_city_boundaries.csv est un peu plus simple à importer que l'exemple précédent. Il contient un champ city_boundary qui est une représentation WKT des limites de la ville sous forme de POLYGON, et un champ city_location qui est une représentation geo_point de l'emplacement de la ville. Nous pouvons importer ces données de la même manière que les données aéroportuaires, à quelques différences près :

• Nous avons dû sélectionner le paramètre d'annulation Has header row car il n'était pas détecté automatiquement.

• Nous n'avons pas eu besoin de découper les champs, car les données étaient déjà exemptes d'espaces blancs supplémentaires.

• Nous n'avons pas eu besoin de modifier le pipeline d'ingestion car tous les types étaient soit des chaînes de caractères, soit des types spatiaux.

• Nous avons toutefois dû modifier les correspondances entre les champs afin de définir le champ city_boundary comme étant geo_shape et le champ city_location comme étant geo_point

Nos mappages de champs finaux se présentaient comme suit :

Comme pour l'importation airports.csv, il suffit de cliquer sur Import pour importer les données dans l'index. Les données seront importées avec les mappings que nous avons édités et le pipeline d'ingestion défini par Kibana.

Explorer les données géospatiales avec les outils de développement

Dans Kibana, il est habituel d'explorer les données indexées avec "Discover". Cependant, si votre intention est d'écrire votre propre application en utilisant des requêtes ES|QL, il peut être plus intéressant d'essayer d'accéder à l'API Elasticsearch brute. Kibana dispose d'une console pratique pour expérimenter l'écriture de requêtes. Il s'agit de la console Dev Tools, qui se trouve dans la barre latérale de Kibana. Cette console communique directement avec le cluster Elasticsearch et peut être utilisée pour exécuter des requêtes, créer des index, etc.

Essayez ce qui suit :

Cela devrait donner les résultats suivants :

distance

abbrev

nom

Lieu

pays

ville

élévation

273418.05776847183

HAM

Hambourg

POINT (10.005647830925 53.6320011640866)

Allemagne

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

POINT (13.2903090925074 52.5544287044101)

Allemagne

Hohen Neuendorf

38.0

483713.15032266214

OSL

Oslo Gardermoen

POINT (11.0991032762581 60.1935783171386)

Norvège

Oslo

208.0

522538.03148094116

BMA

Bromma

POINT (17.9456175406145 59.3555902065112)

Suède

Stockholm

15.0

522538.03148094116

ARN

Arlanda

POINT (17.9307299016916 59.6511203397372)

Suède

Stockholm

38.0

624274.8274399083

DHS

Düsseldorf Int'l

POINT (6.76494446612174 51.2781820420774)

Allemagne

Düsseldorf

45.0

633388.6966435644

PRG

Ruzyn

POINT (14.2674849854076 50.1076511703671)

Tchécoslovaquie

Prague

381.0

635911.1873311149

AMS

Schiphol

POINT (4.76437693232812 52.3089323889822)

Pays-Bas

Hoofddorp

-3.0

670864.137958866

FRA

Francfort Int'l

POINT (8.57182286907608 50.0506770895207)

Allemagne

Francfort

111.0

683239.2529970079

WAW

Okecie Int'l

POINT (20.9727263383587 52.171026749259)

Pologne

Piaseczno

111.0

Visualiser des données géospatiales avec Kibana Maps

Kibana Maps est un outil puissant de visualisation des données géospatiales. Il peut être utilisé pour créer des cartes avec plusieurs couches, chaque couche représentant un ensemble de données différent. Les données peuvent être filtrées, agrégées et stylisées de différentes manières. Dans cette section, nous allons vous montrer comment créer une carte dans Kibana Maps en utilisant les données que nous avons importées dans la section précédente.

Dans le menu Kibana, naviguez vers Analytics->Maps pour ouvrir une nouvelle vue de la carte. Cliquez sur Add Layer et sélectionnez Documents, choisissez la vue de données airports et modifiez le style de la couche pour colorer les marqueurs à l'aide du champ elevation, de sorte que nous puissions facilement voir à quelle hauteur se trouve chaque aéroport.

Cliquez sur "Conserver les modifications" pour enregistrer la carte :

Ajoutez maintenant une deuxième couche, en sélectionnant cette fois la vue de données airport_city_boundaries. Cette fois-ci, nous utiliserons le champ city_boundary pour styliser le calque et définir la couleur de remplissage sur un bleu clair. Les limites de la ville apparaissent alors sur la carte. Veillez à réorganiser les couches de manière à ce que les marqueurs d'aéroport soient placés en haut.

Jointures spatiales

ES|QL ne prend pas en charge les commandes JOIN, mais vous pouvez réaliser un cas spécial de jointure à l'aide de la commande ENRICH. Cette commande s'apparente à une "jointure gauche" en SQL, vous permettant d'enrichir les résultats d'un index avec des données d'un autre index sur la base d'une relation spatiale entre les deux ensembles de données.

Par exemple, enrichissons les résultats d'un tableau d'aéroports avec des informations supplémentaires sur la ville qu'ils desservent en trouvant la limite de la ville qui contient l'emplacement de l'aéroport, puis effectuons quelques statistiques sur les résultats :

Si vous exécutez cette requête sans avoir au préalable préparé l'index enrichi, vous obtiendrez un message d'erreur du type

En effet, comme nous l'avons déjà mentionné, ES|QL ne prend pas en charge les véritables commandes JOIN. L'une des raisons principales est qu'Elasticsearch est un système distribué et que les jointures sont des opérations coûteuses qu'il peut être difficile de faire évoluer. Cependant, la commande ENRICH peut être très efficace, car elle utilise des index enrichis spécialement préparés qui sont dupliqués sur l'ensemble du cluster, ce qui permet d'effectuer des jointures locales sur chaque nœud.

Pour mieux comprendre, concentrons-nous sur la commande ENRICH dans la requête ci-dessus :

Cette commande demande à Elasticsearch d'enrichir les résultats extraits de l'index airports et d'effectuer une jointure intersects entre le champ city_location de l'index original et le champ city_boundary de l'index airport_city_boundaries, que nous avons utilisé dans quelques exemples plus tôt. Mais certaines de ces informations ne sont pas clairement visibles dans cette requête. Ce que nous voyons, c'est le nom d'une politique d'enrichissement city_boundaries, et l'information manquante est encapsulée dans cette définition de politique.

Ici, nous pouvons voir qu'il effectuera une requête geo_match (intersects est la valeur par défaut), que le champ à comparer est city_boundary et que les champs enrich_fields sont les champs que nous voulons ajouter au document d'origine. L'un de ces champs, le region, a été utilisé comme clé de regroupement pour la commande STATS, ce que nous n'aurions pas pu faire sans cette capacité de "jointure à gauche". Pour plus d'informations sur les politiques d'enrichissement, voir la documentation d'enrichissement.

Les index et politiques d'enrichissement d'Elasticsearch ont été conçus à l'origine pour enrichir les données au moment de l'indexation, en utilisant les données d'un autre index d'enrichissement préparé. Dans ES|QL, cependant, la commande ENRICH fonctionne au moment de la requête et ne nécessite pas l'utilisation de pipelines d'ingestion. Cela le rend assez similaire à un SQL LEFT JOIN, sauf que vous ne pouvez pas joindre deux index, mais seulement un index normal à gauche avec un index enrichi spécialement préparé à droite.

Dans les deux cas, que ce soit pour les pipelines d'ingestion ou pour l'utilisation dans ES|QL, il est nécessaire d'effectuer quelques étapes préparatoires pour mettre en place l'index et la politique d'enrichissement. Nous avons déjà importé l'index airport_city_boundaries ci-dessus, mais il n'est pas directement utilisable comme index d'enrichissement dans la commande ENRICH. Nous devons d'abord effectuer deux démarches :

• Créez la politique d'enrichissement décrite ci-dessus pour définir l'index source, le champ de l'index source à comparer et les champs à renvoyer une fois la correspondance établie.

• Exécutez cette politique pour créer l'index d'enrichissement. Cela permet de construire un index interne spécial, en lisant l'index source d'origine dans une structure de données plus efficace qui est copiée à travers le cluster.

La politique d'enrichissement peut être créée à l'aide de la commande suivante :

La politique peut être exécutée à l'aide de la commande suivante :

Notez que si vous modifiez le contenu de l'index airport_city_boundaries, vous devrez réexécuter cette politique pour que les changements soient reflétés dans l'index enrichi. Exécutons à nouveau la requête ES|QL d'origine :

Cette méthode permet d'obtenir les 5 régions qui comptent le plus d'aéroports, ainsi que le centroïde de tous les aéroports qui ont des régions correspondantes et la longueur de la représentation WKT des limites des villes à l'intérieur de ces régions :

centroïde

Compte

région

POINT (-12.139086859300733 31.024386116624648)

126

nul

POINT (-83.10398317873478 42.300230911932886)

3

Détroit

POINT (39.74537850357592 47.21613017376512)

3

городской округ Батайск

POINT (-156.80986787192523 20.476673701778054)

3

Hawaï

POINT (-73.94515332765877 40.70366442203522)

3

Ville de New York

POINT (-83.10398317873478 42.300230911932886)

3

Détroit

POINT (-76.66873019188643 24.306286952923983)

2

New Providence

POINT (-3.0252167768776417 51.39245774131268)

2

Cardiff

POINT (-115.40993484668434 32.73126147687435)

2

Municipalité de Mexicali

POINT (41.790108773857355 50.302146775648)

2

Центральный район

POINT (-73.88902732171118 45.57078813901171)

2

Montréal

Vous pouvez également remarquer que la région la plus fréquemment trouvée est null. Qu'est-ce que cela peut signifier ? Rappelez-vous que j'ai comparé cette commande à une "jointure gauche" en SQL, ce qui signifie que si aucune limite de ville correspondante n'est trouvée pour un aéroport, l'aéroport est toujours renvoyé, mais avec les valeurs null pour les champs de l'index airport_city_boundaries. Il s'avère que 125 aéroports n'ont pas trouvé de correspondance avec city_boundary, et un aéroport avec une correspondance où le champ region était null. Cela a conduit à un décompte de 126 aéroports sans region dans les résultats. Si votre cas d'utilisation exige que tous les aéroports puissent être mis en correspondance avec les limites d'une ville, il faudra trouver des données supplémentaires pour combler les lacunes. Il serait nécessaire de déterminer deux choses :

• les enregistrements de l'index airport_city_boundaries qui n'ont pas de champs city_boundary

• les enregistrements de l'index airports qui ne correspondent pas à l'aide de la commande ENRICH (c'est-à-dire. ne se croisent pas)

Utilisation de ES|QL pour les données géospatiales dans Kibana Maps

Kibana a ajouté la prise en charge de Spatial ES|QL dans l'application Maps. Cela signifie que vous pouvez désormais utiliser ES|QL pour rechercher des données géospatiales dans Elasticsearch et visualiser les résultats sur une carte.

Il existe une nouvelle option de couche dans le menu d'ajout de couches, appelée "ES|QL". Comme toutes les fonctions géospatiales décrites jusqu'à présent, il s'agit d'un aperçu technique "" . Cette option permet d'ajouter une couche à la carte en fonction des résultats d'une requête ES|QL. Par exemple, vous pouvez ajouter une couche à la carte qui montre tous les aéroports du monde.

Vous pouvez également ajouter une couche qui montre les polygones de l'index airport_city_boundaries ou, mieux encore, la requête complexe ENRICH ci-dessus qui génère des statistiques sur le nombre d'aéroports dans chaque région.

Et ensuite ?

Le précédent blog sur la recherche géospatiale s'est concentré sur l'utilisation de fonctions telles que ST_INTERSECTS pour effectuer des recherches, disponibles dans Elasticsearch depuis la version 8.14. Ce blog vous montre comment importer les données que nous avons utilisées pour ces recherches. Cependant, Elasticsearch 8.15 a été doté d'une fonction particulièrement intéressante : ST_DISTANCE qui peut être utilisée pour effectuer des recherches de distance spatiale efficaces, et ce sera le sujet du prochain blog !