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.)