Skip to main content

The Forrester Wave™ : Plateformes XDR, T2 2026

Accéder au rapport
À propos de nousPartenairesSupport technique|Connexion
Elastic logo
Démarrez un essai gratuitNous contacter

Guide de dépannage : résoudre 6 problèmes courants de chargement dans Kibana Discover

By
Stef Nestor

Discover est le noyau de l’interface utilisateur Kibana®d’Elastic® pour rechercher, filtrer et inspecter les données (temporelles). Les visualisations sont utilisées pour les agrégations/résumés de données. L’ interface utilisateur Discover est résiliente face aux réponses Elasticsearch® volumineuses de données, mais elle peut parfois rencontrer des problèmes en raison de la taille de la réponse (non compressée), d’une explosion du mapping et des limites du navigateur. 

Ci-dessous, nous résumerons les problèmes historiques les plus courants, notamment les longs chargements, les délais d'attente et les erreurs, et nous fournirons une procédure de dépannage séquentielle pour les résoudre. Remarque : les API de cet article sont écrites pour la version 8.6, mais le flux de dépannage général s'applique aux versions antérieures et ultérieures.

log d'événements Kibana

Après avoir établi et chargé une session utilisateur, Kibana chargera Discover via l'URI de base /application/discover (ou son URI spécifique Kibana Space associée). Pour charger cette page, la page du navigateur demandera séquentiellement trois API au serveur Kibana (et via Kibana au serveur Elasticsearch ci-dessous, si nécessaire).

Problème courant 1 : erreurs de page lors du chargement

Si la page Kibana génère une erreur lors du chargement, vous devrez ouvrir l'onglet réseau de votre navigateur pour confirmer quelle requête séquentielle échoue. Vous pouvez partager vos conclusions en exportant un log HAR.

1. Charger la Data view

La page du navigateur demandera le point de terminaison Saved Objects de Kibana pour le Data view actuellement sélectionné (le code cible toujours `type:index-pattern` car cet objet était nommé « modèle d'indexation » dans les versions précédentes, mais a été renommé dans la v8.0 pour plus de clarté).

POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]

Cette API Kibana transfère la recherche vers l’API Elasticsearch sous l’ alias .kibana qui prend en charge l’objet enregistré. Je ne suis pas certain de la conversion de la requête, mais ce serait quelque chose comme :

GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
 "match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}

Remarque : les objets enregistrés sont recherchés par l'identifiant de la Data view et non par leur titre ou leur nom. Si vous exportez/importez ou copiez des objets enregistrés entre des Kibana Spaces ou des clusters Elasticsearch, vous pourriez rencontrer une erreur de visualisation/tableau de bord/Discover indiquant que votre identifiant sous-jacent a changé lors de l'importation (consultez le module d'importation des objets enregistrés pour éviter cela). Pour démontrer la différence entre ces champs :

objets sauvegardés
Problème courant 2 : Data view manquante

Si vous êtes concerné, lors du chargement de la page, vous devriez voir apparaître un module d’avertissement/erreur en bas à droite similaire à : « DATA_VIEW_ID » n’est pas un ID de Data view configuré

Cette erreur est signalée dans le contexte de l’ espace Kibana actuel et ne s’applique pas si le Data View existe ou non dans un autre espace.

2. Charger les champs

Ensuite, l’interface utilisateur de Kibana chargera une compilation des champs associés aux index de support.

API. Tout d'abord, il effectuera une requête API :

GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score

Cette API se redéclenchera chaque fois que l’utilisateur sélectionnera une Data view en haut à gauche. En arrière-plan, Kibana renvoie des index à partir de l’ API champ Caps d’Elasticsearch.

Problème courant 3 : explosion du mapping

Le temps de réponse de cette API est considérablement impacté par une explosion du mapping, qui peut être partiellement diagnostiquée par la taille de réponse compressée/non compressée de cette API. Cela est généralement lié au nombre de mappings d'index variables chargés, mais peut également résulter du dépassement des limites de mapping. Cela renvoie généralement une valeur (bien) inférieure à 3 s, mais vous devriez certainement considérer ≥ 10 s comme une valeur lente.

Problème courant n° 4 : conflits de champs

Des erreurs sont historiquement survenues en raison de conflits de noms de champs entre les index. Vous souhaiteriez corriger les mappings d'index sous-jacents, mais vous pouvez également appliquer un champ d'exécution en tant que remplacement temporaire pour corriger le type de mapping des index erronés.

JS. Une fois les résultats de l'API renvoyés, si le volet gauche (affichant « Selected Fields » et « Available Fields ») est ouvert, le JavaScript du navigateur effectuera une analyse récapitulative sur ces champs. En cas de lenteur, cela apparaîtra dans l'onglet Network du navigateur comme si la requête API était terminée, mais que la requête suivante (3) n'avait pas commencé à tenter de s'exécuter pendant plusieurs secondes. Les utilisateurs ne le remarquent généralement qu'à partir de ≥10 s.

Capture d'écran des champs

Ce temps de compilation JavaScript est diagnostiqué via l’onglet Performance des outils de développement du navigateur (par ex., Chrome, Firefox, Edge; il est également possible d’exporter un équivalent de type HAR pour le partage).

3. Charger rechercher

Enfin, la page du navigateur effectuera une requête API pour rechercher. Cette requête API pour rechercher passe par le serveur Kibana mais devrait prendre presque autant de temps que si vous effectuiez la requête d'API Elasticsearch directement.

API. Cette URI est définie par défaut sur :

POST /internal/bsearch {REQUEST_BODY_HERE}

Mais si le paramètre avancé courier:batchSearches est défini sur false (<v8.0), alors cela demandera plutôt l'API suivante :

POST /internal/_msearch {REQUEST_BODY_HERE}
(Pour faciliter la recherche rapide sur la page : #inspectViaDevTools.) Si le fait de rechercher prend du temps à traiter, nous réduisons généralement la période de rétrospection au minimum possible (par ex. 1 à 5 minutes). Ensuite, nous naviguerons vers Discover > Inspecter. Nous vérifierons rapidement le temps de chargement total (dans l'encadré vert ci-dessous) par rapport à Statistics > « Temps de requête ».
Inspecteur-1

Nous nous attendons à un écart entre le « Query Time » (temps que Elasticsearch estime nécessaire pour effectuer la recherche) et le temps rapporté par Kibana, mais nous devrons vérifier si ce dernier est d'un ordre de grandeur supérieur au premier, ce qui indiquerait, par exemple, une charge sur le serveur Kibana, une compression HTTP désactivée ou un problème de rendu général. 

Si nous souhaitons approfondir notre recherche pour isoler la charge du serveur Kibana d'un problème de rendu général, nous naviguerons vers Inspect > Request > Open in Console (aussi appelé DevTools). Visuellement :

inspecteur-2

Nous exécuterons ensuite cette requête de recherche API à la fois dans DevTools et séparément via cURL de l'API Elasticsearch, en notant les différences globales de temps de réponse entre Discover, DevTools et l'API Elasticsearch.

Problème courant n° 5 : si la requête est lente dans l'API Elasticsearch

Si Elasticsearch est tout aussi lent que les deux autres, nous pouvons suspecter une recherche ou un filtre non optimisé dans notre vue Discover initiale. Si aucun filtre ou aucune recherche n'est appliqué (ou si le problème se reproduit sans aucun filtre), nous confirmerons les performances générales d'Elasticsearch via CAT Node, CAT Threadpools (notamment les threads de recherche), et CAT Tasks (pour les tâches de longue durée). Si aucun problème à l'échelle du cluster n'est détecté, nous comparerons les durées de réponse des recherches entre les différents Data view sélectionnés dans Discover, puis nous comparerons les Query Profiling associés à ces recherches (après avoir injecté profile: true dans le corps de notre requête de recherche).

JS. Une fois les résultats de l’API renvoyés, le JavaScript du navigateur s’exécute pour charger soit 1) le résumé du tableau d’affichage (le tableau « Documents » en bas au milieu où vous pouvez activer/désactiver l’affichage des colonnes), soit 2) les « Statistiques de champ » (en version bêta, à activer dans Paramètres avancés via discover:showFieldStatistics).

Problème courant 6 : temps de rendu affecté par une explosion du mapping

Les explosions de mapping peuvent entraîner un grand jeu de résultats, ce qui a causé par le passé des régressions de performance dans le navigateur (par ex., kibana#144673). Une explosion de mapping peut faire apparaître des erreurs spécifiques au navigateur, comme l'erreur de Chrome : maximum call stack size exceeded, qui se reproduit en mode navigation privée, ne se produit pas dans Firefox/Safari, et ne se résout parfois qu'en mettant à jour Chrome. Si, toutefois, vous rencontrez un processus de rendu très lent sans erreur après le retour du résultat, il est temps d'enregistrer un profil de performance du navigateur pour analyser ce qui cause la lenteur du rendu. Notre équipe est heureuse de vous aider à examiner la sortie via Kibana GitHub, Elastic Discuss, ou en ouvrant un ticket de support!

Impact en cascade

(Pour faciliter la recherche rapide sur la page : #devToolsAuto.) Lors du dépannage d'éventuelles explosions de mapping, DevTools peut répondre plus lentement que Discover et le chargement de l'icône en haut à gauche lorsque aucune requête n'est attendue en raison de l'URI.

GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
Ceci est contrôlé via DevTools > Settings (Paramètres) > « Autocomplete » (Saisie semi-automatique) en désactivant (au moins) les champs et en augmentant la fréquence de rafraîchissement.
paramètres de la console

Ces requêtes peuvent ralentir 1) le navigateur local, provoquant des plantages de page ou des bannières « wait for page ? » (attendre la page ?), et 2) le serveur Kibana, en fonction de leur fréquence et de leur coût en ressources. Cette modification est spécifique à l'utilisateur connecté.

Conclusion

Discover est un moyen simple d'analyser les données de plusieurs index au sein de vos clusters. Certaines configurations et certains paramètres peuvent ralentir le chargement de cette interface utilisateur plus que nécessaire. Ce guide a passé en revue l'impact de ces divers pièges ; cependant, une bonne hygiène des données permet de les éviter tous. Pour plus de conseils sur l'hygiène des données, consultez notre documentation Elasticsearch.

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.

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit