Monitorer des vues des tableaux de bord Kibana avec Elastic Workflows

Kibana enregistre le nombre de consultations de chaque tableau de bord, mais ces données ne sont pas accessibles nativement dans les tableaux de bord intégrés. Dans cet article, nous utiliserons Elastic Workflows pour collecter automatiquement ces données toutes les 30 minutes et les indexer dans Elasticsearch, afin de pouvoir créer nos propres analyses.

Elastic Workflows est un moteur d'automatisation intégré à Kibana qui vous permet de définir des processus à plusieurs étapes à l'aide d'une configuration YAML simple. Chaque workflow peut être déclenché selon une planification ou un événement, ou en tant qu'outil dans Elastic Agent Builder, et chaque étape peut appeler les API de Kibana, interroger Elasticsearch ou transformer des données.

Nous utiliserons les compteurs de vues du tableau de bord comme exemple concret, mais le même modèle s'applique à n'importe quel indicateur exposé via l'API des objets enregistrés de Kibana.

Produits requis

• Elastic Cloud ou cluster autogéré exécutant la version 9.3
• Workflows activés (paramètres avancés)

Avant toute chose, examinons les données disponibles. Kibana stocke la majeure partie de sa configuration et de ses métadonnées sous forme d'objets enregistrés dans un index interne dédié. Parmi les éléments suivis par Kibana figurent les consultations des tableaux de bord, grâce à un type d'objet enregistré spécifique appelé "compteurs d'utilisation". Vous pouvez les interroger directement depuis les outils de développement :

La réponse se présente comme suit :

Le champ counterName est l'identifiant du tableau de bord, et count est le nombre cumulé de vues pour ce tableau de bord ce jour-là. Kibana crée un objet compteur par tableau de bord par jour ; vous pouvez voir le suffixe de date dans l'ID de l'objet (...viewed:server:20260310). Le nombre augmente tout au long de la journée lorsque les utilisateurs ouvrent le tableau de bord.

Plutôt que de reproduire ce modèle de document quotidien dans notre index, nous créerons un document par exécution de workflow. Chaque document enregistre le nombre de vues que ce tableau de bord avait accumulées pour la journée au moment de la capture.

Étape 2 : Créer l'index de destination

Nous avons besoin d'un index pour stocker les snapshots de nos vues de tableau de bord. La commande suivante le crée avec des mappings explicites afin de pouvoir les agréger et les visualiser ultérieurement. Exécutez cette commande dans les outils de développement :

L'utilisation des mappings keyword pour les ID et les noms permet des agrégations. L'utilisation de integer pour view_count est une valeur par défaut sûre, car Kibana réinitialise le compteur quotidiennement ; atteindre la limite de 32 bits (plus de 2 milliards de vues en une seule journée) n'est donc pas un problème réaliste. Il prend toujours en compte les opérations numériques, comme max, avg et min entre autres.

Étape 3 : Créer le workflow

Accédez à Stack Management > Workflows > Nouveau workflow, puis collez la configuration YAML de workflow suivante :

Dans la section suivante, nous allons détailler le workflow étape par étape.

Fonctionnement du workflow

Déclencheurs

Le workflow s'exécute sur un déclencheur planifié toutes les 30 minutes. Cela nous permet d'obtenir des données temporelles sans solliciter l'API.

récupérer les vues du tableau de bord

Utilise kibana.request pour appeler l'API des objets enregistrés de Kibana. Aucune configuration d'authentification n'est nécessaire : le moteur de workflow associe automatiquement les en-têtes corrects en fonction du contexte de l'exécution.

index_each_dashboard (foreach)

Itère sur le tableau saved_objects renvoyé par l'étape précédente. L'élément actuel de chaque itération est disponible sous la forme foreach.item. À l'intérieur de la boucle, nous exécutons deux étapes imbriquées pour chaque tableau de bord.

1. fetch_dashboard_name :

Résout le titre du tableau de bord lisible par l'utilisateur en appelant GET /api/saved_objects/dashboard/{id}. Nous ajoutons on-failure: continue: true pour que, si un tableau de bord a été supprimé mais qu'il contient encore des compteurs de vues, la boucle continue au lieu d'interrompre l'exécution.

2. index_doc :

Indexe chaque document à l'aide de POST /dashboard-views/_doc (sans identifiant explicite), ce qui permet à Elasticsearch de générer automatiquement des identifiants. Un nouveau document est ainsi créé à chaque exécution, ce qui permet d'établir un historique du nombre de vues au fil du temps plutôt que d'écraser le snapshot précédent.

Deux choses à noter :

• Le champ captured_at utilise le filtre de date pour formater l'horodatage au format ISO 8601. Sans ce filtre, la valeur apparaît sous la forme d'une chaîne de date JavaScript, comme Tue Mar 10 2026 05:03:47 GMT+0000, qu'Elasticsearch ne pourra pas interpréter comme une date.
• Le view_count utilise la syntaxe ${{ }} avec | plus: 0 pour préserver le type numérique. L'utilisation de {{ }} le rendrait sous forme de chaîne, ce qui empêcherait les opérations mathématiques dans le tableau de bord.

L'interface utilisateur vous permet de déboguer efficacement chacune des étapes du workflow.

Étape 4 : Créer le tableau de bord des statistiques

Une fois que le workflow a été exécuté plusieurs fois et que les données ont été collectées, créez un nouveau tableau de bord dans Kibana en utilisant la data view dashboard-views.

Voici quelques panneaux pour commencer :

• Principaux tableaux de bord par vues : utilisez un graphique à barres avec dashboard_name sur l'axe des X et last_value(view_count) sur l'axe des Y. Cela indique le nombre actuel de vues quotidiennes par tableau de bord.
• Vues au fil du temps : utilisez un graphique linéaire avec captured_at sur l'axe X et last_value(view_count) sur l'axe Y, décomposé par dashboard_name. Comme chaque exécution ajoute un nouveau document, utilisez la dernière valeur pour obtenir le nombre maximal par intervalle temporel au lieu d'additionner les doublons.
• Snapshot actuel : utilisez un tableau de données avec les dernières valeurs captured_at pour afficher les nombres de vues les plus récents sur tous les tableaux de bord.

Étant donné que chaque workflow crée un nouveau document, vous pouvez filtrer par plage horaire pour analyser l'activité sur des périodes spécifiques, comparer d'une semaine à l'autre ou créer des alertes lorsqu'un tableau de bord passe en dessous d'un seuil d'affichage.

Conclusion

Elastic Workflows est parfaitement adapté à ce type de collecte de données périodique, car la source (API Kibana) et la destination (Elasticsearch) sont natives, ce qui élimine toute gestion d'identifiants. Le moteur de workflow gérant automatiquement l'authentification pour les étapes kibana.request et elasticsearch.request, vous n'avez qu'à écrire la logique.

Ressources

• Elastic Workflows
• API Kibana