Skip to main content

The Forrester Wave™: XDR Platforms, 2. Quartal 2026

Bericht holen
Über unsPartnerSupport|Anmelden
Elastic logo
Kostenlosen Test startenVertrieb kontaktieren

Troubleshooting-Leitfaden: 6 häufige Probleme beim Laden von Kibana Discover lösen

By
Stef Nestor

Discover ist die Kern-Kibana-Benutzeroberfläche von Elastic®’s® zum Suchen, Filtern und Inspizieren von (Zeitreihendaten). Visualisierungen werden für Datenaggregationen/-zusammenfassungen verwendet. Die Discover-Benutzeroberfläche ist resilient gegenüber großen Daten-Elasticsearch-Reaktionen®, kann aber manchmal aufgrund der (unkomprimierten) Reaktionsgröße, Mapping-Explosion und Browser-Limits zu Problemen führen. 

Im Folgenden fassen wir die häufigsten Probleme der Vergangenheit zusammen, einschließlich langer Ladezeiten, Timeouts und Fehler, und bieten eine schrittweise Anleitung zur Fehlerbehebung, um diese zu lösen. Hinweis: Die APIs in diesem Artikel beziehen sich auf Version 8.6, der allgemeine Ablauf zur Fehlerbehebung gilt jedoch auch für frühere und spätere Versionen.

Kibana-Ereignisprotokoll

Nachdem eine Nutzersitzung eingerichtet und geladen wurde, lädt Kibana Discover über die Basis-URI /app/discover (oder die zugehörige Kibana Space -spezifische URI). Um diese Seite zu laden, fordert die Browserseite nacheinander drei APIs vom Kibana-Server an (und bei Bedarf über Kibana an den unten stehenden Elasticsearch-Server).

Häufiges Problem 1: Seitenfehler beim Laden

Wenn die Kibana-Seite beim Laden einen Fehler ausgibt, sollten Sie den Netzwerk-Tab Ihres Browsers öffnen, um zu bestätigen, welche sequentielle Anfrage fehlschlägt. Sie können Ihre Ergebnisse teilen, indem Sie ein HAR-Log exportieren.

1. Load data view

Die Browserseite fragt den Saved Objects -Endpoint von Kibana für den aktuell ausgewählten Data View ab (der Code zielt weiterhin auf `type:index-pattern` ab, da dieses Objekt in früheren Versionen „Indexmuster“ hieß, aber zur besseren Übersichtlichkeit in v8.0 umbenannt wurde).

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

Diese Kibana-API leitet das Suchen an die Elasticsearch-API unter dem dem Saved Object zugrunde liegenden Alias .kibana weiter. Ich bin mir bei der Abfrageübersetzung nicht sicher, aber sie würde ungefähr so aussehen:

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

Hinweis: Gespeicherte Objekte werden anhand der ID des Data view gesucht und nicht anhand des Titels oder Namens. Wenn Sie exportieren/importieren oder kopieren, gespeicherte Objekte zwischen Kibana Spaces oder Elasticsearch-Clustern exportieren/importieren oder kopieren, kann ein Fehler in Visualisierung/Dashboard/Discover auftreten, da sich die zugrunde liegende ID während des Imports geändert hat (siehe das Importmodul für gespeicherte Objekte, um dies zu vermeiden). Um den Unterschied dieser Felder zu demonstrieren:

gespeicherte Objekte
Häufiges Problem 2: Fehlende Data view

Falls Sie davon betroffen sind, erscheint beim Laden der Seite unten rechts ein Warn-/Fehlermodul ähnlich wie: „DATA_VIEW_ID“ ist keine konfigurierte Data view-ID

Dieser Fehler wird im Kontext des aktuellen Kibana Space gemeldet und ist nicht relevant, wenn der Data View in einem anderen Space existiert oder nicht existiert.

2. Felder laden

Als Nächstes lädt die Kibana-Benutzeroberfläche eine Zusammenstellung der zugehörigen Felder der zugrunde liegenden Indizes.

API. Zuerst erfolgt eine API-Anfrage:

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

Diese API wird jedes Mal neu ausgelöst, wenn der Nutzer oben links eine Data view auswählt. Im Backend gibt Kibana Indizes von der Feld Caps API von Elasticsearch zurück.

Häufiges Problem 3: Mapping-Explosion

Die Reaktionszeit dieser API wird drastisch durch Mapping-Explosion beeinträchtigt, was teilweise durch die unkomprimierte/komprimierte Antwortgröße dieser API diagnostiziert werden kann. Normalerweise hängt dies damit zusammen, wie viele verschiedene Index-Mappings geladen sind, kann aber auch durch das Überschreiten von Mapping-Limits entstehen. Dies ergibt normalerweise (weit) unter 3 s, aber bei ≥10 s sollten Sie definitiv von einer langsamen Antwort ausgehen.

Häufiges Problem 4: Feldkonflikte

In der Vergangenheit traten Fehler aufgrund von Konflikten bei Feldnamen zwischen Indizes auf. Sie würden zwar gerne die zugrunde liegenden Index-Mappings korrigieren, aber Sie können auch ein Laufzeitfeld anwenden, um als temporäre Überschreibung den Mapping-Typ der fehlerhaften Indizes zu korrigieren.

JS. Sobald die API-Ergebnisse zurückgegeben werden und die linke Schublade (mit „Selected Fields“ und „Available Fields“) geöffnet ist, führt das Browser-JavaScript eine zusammenfassende Analytik für diese Felder durch. Bei Langsamkeit erscheint dies im Netzwerk-Tab des Browsers so, dass die API-Anfrage beendet wurde, die folgende (3) Anfrage jedoch für mehrere Sekunden keine Startversuche unternahm. Nutzer bemerken dies normalerweise erst ab ≥10 s.

Screenshot der Felder

Diese JavaScript-Kompilierungszeit wird über den Performance-Tab der Browser-DevTools einer Diagnose unterzogen (z. B. Chrome, Firefox, Edge; ein HAR-ähnliches Äquivalent kann ebenfalls zum Teilen exportiert werden).

3. suchen laden

Zuletzt stellt die Browser-Seite eine API-Suchanfrage. Diese API-Suchanfrage läuft über den Kibana-Server, sollte aber nahezu genauso viel Zeit in Anspruch nehmen wie eine direkte Elasticsearch-API-Anfrage.

API. Diese URI ist standardmäßig:

POST /internal/bsearch {REQUEST_BODY_HERE}

Wenn jedoch die Advanced Setting(Erweiterte Einstellung) courier:batchSearches auf false gesetzt ist (<v8.0), dann wird stattdessen die folgende API angefordert:

POST /internal/_msearch {REQUEST_BODY_HERE}
(Zur Unterstützung der schnellen Seitensuche: #inspectViaDevTools.) Wenn die Verarbeitung dieses Suchens eine Weile dauert, reduzieren wir die Rückschauzeit normalerweise auf ein Minimum (z. B. 1–5 Minuten). Anschließend navigieren wir zu Discover > inspizieren. Wir überprüfen kurz die Gesamtladezeit (im grünen Kasten unten) im Vergleich zu Statistics > „Query time“.
inspector-1

Wir erwarten eine Differenz zwischen der „Query Time“ (Zeit, die Elasticsearch zum Suchen veranschlagt) und der von Kibana gemeldeten Zeit. Wir sollten jedoch prüfen, ob Letztere um Größenordnungen von Ersterer abweicht, was beispielsweise auf eine Auslastung des Kibana-Servers, eine deaktivierte HTTP-Komprimierung oder ein allgemeines Rendering-Problem hindeuten würde. 

Wenn wir weiter suchen möchten, um zwischen der Last des Kibana-Servers und einem allgemeinen Rendering-Problem zu unterscheiden, navigieren wir weiter zu inspizieren > Request > Open in Console (auch bekannt als DevTools). Visuell:

Inspector-2

Wir werden diese API-Suchanfrage anschließend sowohl in DevTools als auch separat über einen Elasticsearch-API-cURL ausführen und dabei die Unterschiede bei der gesamten Reaktionszeit zwischen Discover, DevTools und der Elasticsearch-API notieren.

Häufiges Problem 5: Wenn die Abfrage in der Elasticsearch-API langsam ist

Wenn Elasticsearch ebenfalls genauso langsam ist wie die anderen beiden, vermuten wir möglicherweise eine nicht optimierte Suche/einen nicht optimierten Filter in unserer ursprünglichen Discover-Ansicht. Wenn keine Filter/Suchen angewendet werden (oder das Problem auch ohne angewendete Filter auftritt), bestätigen wir die allgemeine Elasticsearch-Performance über CAT Nodes, CAT Threadpools (insb. Such-Threads) und CAT Tasks (für lang laufende Tasks). Wenn kein clusterweites Problem gefunden wird, vergleichen wir die Suchreaktionszeiten zwischen den verschiedenen in Discover ausgewählten Data view und vergleichen dann die zugehörigen Query Profiling (nachdem wir profile: true in unseren Suchanfrage-Body eingefügt haben).

JS. Nachdem die API-Ergebnisse zurückgegeben wurden, lädt das JavaScript des Browsers entweder 1) die Zusammenfassung der Anzeigetabelle (die „Documents“-Tabelle in der Mitte unten, in der Sie die Spaltenansicht ein-/ausschalten können) oder 2) die „Feld Statistics“ (in Beta, umschaltbar in Advanced Settings über Discover:showFieldStatistics).

Häufiges Problem 6: Rendering-Zeit durch Mapping-Explosion beeinträchtigt

Mapping-Explosionen können zu einem großen Ergebnissatz führen, was in der Vergangenheit zu Performance-Regressionen im Browser geführt hat (z. B. kibana#144673). Mapping-Explosionen können browserspezifische Fehler verursachen, wie z. B. den Chrome-Fehler „maximum call stack size exceeded“, der im Inkognito-Modus reproduzierbar ist, in Firefox/Safari nicht auftritt und manchmal nur durch ein Upgrade von Chrome behoben wird. Wenn Sie jedoch nach der Rückgabe des Ergebnisses einen sehr langsamen Rendering-Prozess ohne Fehler feststellen, ist es an der Zeit, ein Browser-Performance-Profil aufzuzeichnen, um die Ursache für das langsame Rendering zu untersuchen. Unser Team hilft Ihnen gerne bei der Überprüfung des Ausgangs über Kibana GitHub, Elastic Discuss oder durch das Eröffnen eines Support-Tickets!

Kaskadierende Auswirkungen

(Zur Unterstützung der schnellen Seitensuche: #devToolsAuto.) Bei der Fehlerbehebung potenzieller Mapping-Explosionen DevTools reagieren möglicherweise langsamer als Discover und das Symbol oben links wird geladen, wenn aufgrund des URI keine Anfragen erwartet werden.

GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
Dies wird über DevTools > Settings > „Autocomplete“ gesteuert, indem (zumindest) Fields deaktiviert und die Refresh Frequency erhöht wird.
Konsoleneinstellungen

Diese Anfragen können 1) den lokalen Browser verlangsamen, was zu Seitenabstürzen oder „Warten auf Seite?“-Bannern führt, und 2) den Kibana-Server, abhängig von Häufigkeit und Rechenaufwand, belasten. Diese Änderung ist spezifisch für den angemeldeten Nutzer.

Fazit

Discover ist eine einfache Möglichkeit, Daten aus mehreren Indizes innerhalb Ihrer Cluster zu untersuchen. Es gibt einige Konfigurationen und Einstellungen, die dazu führen können, dass diese Benutzeroberfläche langsamer lädt als nötig. Dieser Leitfaden hat die Auswirkungen dieser verschiedenen Fallstricke erläutert; eine gute Datenhygiene kann jedoch alle vermeiden. Weitere Tipps zur Datenhygiene finden Sie in unserer Elasticsearch-Dokumentation.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

Elastic Cloud kostenlos ausprobieren

Richten Sie ein Deployment mit vollem Funktionsumfang beim Cloud-Anbieter Ihrer Wahl ein. Als das Unternehmen hinter Elasticsearch stellen wir unsere Features und unseren Support für Ihre Elastic-Cluster in der Cloud bereit.

Kostenlosen Test starten