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.

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.

C'est précisément pour cela que nous avons créé des tableaux de bord en lecture seule. C'est le niveau de contrôle que vous attendiez. Partagez vos tableaux de bord en toute confiance, sans craindre que la prochaine personne qui dispose d'un accès en modification ne les modifie ou ne les altère.

Remarque : les autorisations en lecture seule sont disponibles dans Elastic Cloud Serverless et à partir de la version 9.3 pour Elastic Cloud Hosted et Elastic autogéré.

Quand l'option "tout le monde peut modifier" pose problème

Dans Kibana, le partage est généralement synonyme d'autorisations au niveau de l'espace. Si quelqu'un peut créer des tableaux de bord dans un espace, il peut également modifier ou supprimer ceux des autres. C'est génial pour collaborer jusqu'à ce que ce ne soit plus le cas. Une modification accidentelle peut entraîner de mauvaises décisions, une perte de confiance et beaucoup de nettoyage.

Nous avons entendu les solutions de contournement : "On ajoute "lecture seule" dans le nom du tableau de bord et on espère que les gens le remarqueront." Ou encore : "On les étiquette et on croise les doigts." L'espoir n'est pas un modèle d'autorisations. Il vous fallait un moyen efficace de verrouiller un tableau de bord sans en interdire l'accès à tous.

Ce qui ne va pas

Deb et Kevin ont tous deux un accès en modification au tableau de bord de surveillance des logs dans l'espace Opérations. Kevin apporte quelques modifications aux graphiques. À son retour, Deb constate que les chiffres ne correspondent plus à ce qu'elle a présenté. Elle doit alors rechercher ce qui a été modifié (souvent de mémoire), le corriger et se demander combien de rapports erronés ont été diffusés.

Tableaux de bord en lecture seule : droits d'accès et contrôle adaptés

Les tableaux de bord en lecture seule résolvent ce problème en vous permettant de contrôler si d'autres utilisateurs peuvent les modifier. Lorsque vous partagez un tableau de bord, vous avez le choix entre : modifier (par défaut, comme aujourd'hui) ou afficher. En mode affichage, vous seul (et les administrateurs de Kibana) pouvez le modifier ou le supprimer. Tous les autres peuvent l'ouvrir, l'utiliser et lui faire confiance, mais ils ne peuvent pas le modifier.

Ce que vous obtenez

• Intégrité du tableau de bord : en mode affichage, les autres utilisateurs disposant d'un accès en modification dans l'espace ne peuvent ni modifier ni supprimer le tableau de bord. S'ils tentent de le faire, un message leur indique qu'il est verrouillé. Vos graphiques et votre logique restent intacts.

• Vous gardez le contrôle : vous êtes le propriétaire. Vous pouvez toujours modifier, affiner et mettre à jour. Le partage en lecture seule ne vous empêche pas d'accéder au contenu ; il verrouille la version visible par tous les autres utilisateurs.

• Cycle de vie flexible : vous pouvez à tout moment repasser un tableau de bord en mode "modifiable". Et les administrateurs Kibana peuvent toujours gérer tous les tableaux de bord (par exemple, si le propriétaire quitte l'entreprise). Il n'y a pas d'impasse.

Vous pouvez partager largement des tableaux de bord finalisés et stratégiques, en ayant l'assurance qu'ils resteront cohérents. Cette fonctionnalité est disponible dans tous les niveaux et offres Elastic, y compris Serverless.

Qui peut faire quoi ?

Référence rapide par rôle :

• Propriétaire du tableau de bord : vous l'avez créé ; vous disposez d'un accès complet en modification.

• Administrateur Kibana : peut gérer tous les tableaux de bord.

• Utilisateur avec droit de modification dans l'espace : peut créer et modifier ses tableaux de bord ; ne peut ni modifier ni supprimer les tableaux de bord en mode lecture seule.

• Utilisateur avec droit d'affichage dans l'espace : peut uniquement consulter (et afficher) les tableaux de bord.

Action

Propriétaire du tableau de bord

Administrateur Kibana

Utilisateur avec modification de l'espace

Utilisateur avec droit d'affichage dans l'espace

Afficher et consulter les tableaux de bord

✔

✔

✔

✔

Créer de nouveaux tableaux de bord

✔

✔

✔

✘

Modifier/supprimer les tableaux de bord modifiables

✔

✔

✔

✘

Modifier ou supprimer les tableaux de bord en lecture seule

✔

✔

✘

✘

Comment activer le mode lecture seule

Vous pouvez activer le mode lecture seule lors de l'enregistrement d'un nouveau tableau de bord ou ultérieurement depuis le menu Partager.

Lors de l’enregistrement d’un nouveau tableau de bord

• Créez votre tableau de bord, puis cliquez sur Enregistrer.

• Dans la fenêtre modale "Enregistrer en tant que nouveau tableau de bord", recherchez Autorisations.

• Passez de Peut modifier à Peut afficher.

• Cliquez sur Save (Enregistrer). Et le tour est joué ! C'est en lecture seule pour tous les autres utilisateurs.

Pour un tableau de bord que vous possédez déjà

• Ouvrez le tableau de bord.

• Ouvrez le menu Partager le tableau de bord.

• Dans la fenêtre de partage, recherchez Autorisations et sélectionnez Affichage uniquement. La modification s'applique immédiatement ; les autres utilisateurs dans l'espace ne peuvent plus le modifier ni le supprimer.

• Vous pouvez survoler l'action Partager avec la souris pour voir le type d'autorisations dont dispose un tableau de bord donné.

Voir quels tableaux de bord sont verrouillés

Dans la liste principale des tableaux de bord, les tableaux de bord que vous ne pouvez ni modifier ni supprimer sont signalés par une case à cocher désactivée. Cela permet de repérer facilement les tableaux de bord en lecture seule.

Sur le tableau de bord, vous constaterez également que l'action Modifier est désactivée et qu'une info-bulle apparaît, expliquant que le tableau de bord a été configuré en lecture seule.

Faites l'essai

Les tableaux de bord en lecture seule sont désormais disponibles. Créez un tableau de bord, passez-le en mode Affichage uniquement et partagez-le. Votre équipe dispose ainsi d'une source unique d'information fiable, et vous avez l'esprit tranquille. Fini les mentions "Ne pas modifier" dans le titre.

Nous aimerions savoir comment vous utilisez les tableaux de bord en lecture seule. Partagez vos commentaires sur notre forum communautaire.

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.