Wie Kibana Daten beim Laden eines Dashboards abruft

Wenn ein Dashboard geöffnet wird, starten die meisten Panels (intern nennen wir diese Embeddables) eine oder mehrere Elasticsearch-Abfragen. Statt des einfachen Ruf-und-Antwort-Spiels einer synchronen (Sync-)Suche nutzen wir jedoch die Kraft der asynchronen (Async-)Suche (docs).

Bei asynchroner Suche werden Abfrageergebnisse in Elasticsearch außerhalb einer bestimmten HTTP-Anfrage verfügbar gehalten. Das ist wichtig, weil es

• das Laden von Daten widerstandsfähig gegen Netzwerkturbulenzen macht

• betreibt unser Hintergrundsuch-Feature, das es den Nutzern ermöglicht, an anderen Dingen in Kibana zu arbeiten, während sie auf ein länger laufendes Dashboard oder eine Discover-Sitzung warten

Nachdem die erste Abfrage abgeschickt wurde, überwacht Kibana die Suche, um festzustellen, wann sie abgeschlossen ist, und ruft dann das Ergebnis-Set ab.

Wie sich traditionelle Umfragen auf die Ladezeiten des Kibana-Dashboards auswirken

Im traditionellen Polling reicht Kibana eine Abfrage ein, schließt die Anfangsverbindung und überprüft dann regelmäßig Elasticsearch auf Abschluss.

Wir geben Elasticsearch nach dem Absenden der Abfrage eine kurze Zeitspanne, um die Suche abzuschließen und die Ergebnisse zu präsentieren. Wenn die Suche so schnell abgeschlossen ist, entspricht dies einem einfachen Aufruf und einer Reaktion. Bei längeren Suchen wird jedoch die erste Verbindung geschlossen und Kibana beginnt, die Suche regelmäßig auf Abschluss zu überprüfen. Das nennt man Polling.

Leistungsnachteile traditioneller Abfragen

Wenn Sie sich die obige Abbildung ansehen, erkennen Sie vielleicht bereits den Leistungsnachteil dieses Ansatzes: Die Suche wird höchstwahrscheinlich während eines der Ruheintervalle von Kibana abgeschlossen, was zu Zeitverlusten führt.

Im schlimmsten Fall (wenn eine Suche zu Beginn einer Schlafphase abgeschlossen ist) wird die gesamte Dauer des Abfrageintervalls verschwendet.

Die Auswirkungen einer Backoff-Strategie

Bei Umfragen ist es üblich, eine Backoff-Strategie anzuwenden. Das bedeutet, je länger die Dauer der Suche, desto seltener fragen wir ab.

Jedoch bedeutet dies auch, dass die potenzielle verlorene Zeit mit der Dauer der Suche skaliert.

Wie Abfrageintervalle sägezahnförmige Latenzmuster erzeugen

Wenn wir diese Faktoren zusammenfügen, wird unsere verlorene Zeit zu einer schrittweisen Sägezahnfunktion.

Hier sind die Spitzenwerte, die Worst-Case-Szenarien, und die Tiefstwerte, die Best-Case-Szenarien, darstellen. Dies zeigt, dass traditionelle Umfragen uns je nach Suchdauer (und Netzwerkbedingungen) zwischen nichts und der gesamten Dauer des Umfrageintervalls kosten.

Kontinuierliche Umfragen: Wie Kibana Wartezeiten eliminiert

Das Problem bei traditionellem Polling ist ein grundlegender Mangel an Koordination zwischen Kibana und Elasticsearch. Idealerweise weiß Kibana sofort, wenn Ergebnisse verfügbar sind. Was wäre also, wenn wir das Polling-Muster so umkehren würden, dass fast die gesamte Zeit mit der Überprüfung von Elasticsearch verbracht wird und keine Zeit mit Leerlauf?

Durch diese Kombination aus langer Abfragezeit und dem Wegfall von Schlafphasen werden die Ergebnisse geliefert, sobald sie vorliegen.

HTTP/1-Verschlechterung

Die Theorie ist solide. Warum sieht dieses Kibana Deployment dann so schlecht aus, wenn wir die kontinuierliche Abfrage aktivieren?

Der Schlüssel ist, dass diese Deployment über HTTP/1 läuft. Bei HTTP/1 werden HTTP-Anfragen 1:1 auf TCP-Verbindungen abgebildet. Also beanspruchen mehrere langlebige Polling-Anfragen den begrenzten Verbindungspool des Browsers und führen dazu, dass andere Anfragen in die Warteschlange gestellt werden.

Bei HTTP/2+ hingegen können Netzwerkanfragen TCP-Verbindungen per Multiplexing teilen, sodass wir dieses Problem vermeiden.

Bei HTTP/2+ ist kontinuierliches Polling also ein Vorteil, bei HTTP/1 hingegen ein Nachteil.

HTTP/1

HTTP/2+

TCP-Verbindungen

Eine pro HTTP-Anfrage

Multiplexed (viele Anfragen teilen sich Verbindungen)

Kontinuierliches Abfrageverhalten

Verschlechtert die Leistung (Erschöpfung des Verbindungspools)

Voller Nutzen (Ergebnisse sofort verfügbar)

Wie Kibana das HTTP-Protokoll für optimales Polling erkennt

HTTP/2 ist das empfohlene Protokoll und seit Kibana 9.0 der Standard, daher wäre es schade, diese Leistungsverbesserung nicht auszuliefern. Andererseits ist die Benutzerfreundlichkeit von HTTP/1 so schlecht, dass es nicht vertretbar ist, dieses Risiko bei On-Prem-Deployments einzugehen, die ihr Protokoll noch nicht aktualisiert haben. Die Antwort ist klar: Wir müssen erkennen, welches Protokoll verwendet wird, und die optimale Polling-Strategie anwenden.

Es ist durchaus möglich, dass der Kibana-Server weiß, welches Protokoll er spricht. Aber es gibt einen Haken: der limitierende Faktor ist der Verbindungspool des Browsers. Das bedeutet, dass es wirklich darauf ankommt, was der Browser spricht.

Aufgrund von Proxies sind diese nicht immer identisch.

Wenn wir unsere Optimierung auf das Serverprotokoll stützen würden, könnten wir Dinge auf eine von zwei Arten falsch machen.

1. Wenden Sie kontinuierliches Polling an, wenn wir es nicht sollten, und verschlechtern Sie die Erfahrung.

2. Wenn Sie die kontinuierliche Abfrage nicht anwenden, verpassen Sie die Optimierung.

Glücklicherweise bieten moderne Browser eine Möglichkeit, das Protokoll des letzten Netzwerk-Hops einer abgeschlossenen Anfrage mithilfe von PerformanceObserver zu ermitteln. Also beobachten wir das Protokoll der ersten Abfrage und optimieren darauf basierend.

Laborergebnisse: kontinuierliches Polling vs. traditionelles Polling in Kibana

Um kontinuierliche Abfragen zu validieren, erstellten wir Dashboards mit Abfrageverzögerungen von 1–23 Sekunden und maßen Ladezeiten mit und ohne aktivierte Optimierung. Wir luden dann die Dashboards mit und ohne kontinuierliches Polling, um die Gewinne zu messen (wir hatten viel Spaß mit race-for-the-prize).

Das Muster ähnelt unserem ursprünglichen Sägezahndiagramm. Für einige Abfragedauern sind die Gewinne gering, während sie bei anderen mehrere Sekunden betragen.

Fazit

Durch diese Optimierung wird die bei herkömmlichen Abfrageverfahren übliche Latenz erfolgreich durch eine effizientere, kontinuierliche Abfragestrategie ersetzt. Die primäre Herausforderung bestand darin, diese Optimierung unter bestimmten Bedingungen umzusetzen, um eine Leistungsverschlechterung bei HTTP/1-Deployments zu verhindern. Wir lösten es mithilfe des PerformanceObserver des Browsers, um das verwendete Protokoll für den letzten Netzwerkhop zuverlässig zu erkennen.

Labortests bestätigen die Theorie und zeigen, dass kontinuierliche Abfragen Ergebnisse liefern, sobald diese verfügbar sind. Im Durchschnitt führt dies zu einer deutlichen Verbesserung des Nutzererlebnisses, wodurch das Laden von Daten um bis zu 25 % beschleunigt wird.

Diese Arbeit ist der jüngste Schritt in unserem Bestreben, die Zeit bis zum Einblick für unsere Nutzer zu verkürzen. Indem wir Kibana zu einem transparenteren Proxy für Elasticsearch-Daten machen, erweitern wir die Leistungsgrenzen innerhalb unseres Einflussbereichs. Fortsetzung folgt!

(Im Jahr 2025 gab Thomas Neirynk einen ausgezeichneten Überblick über die Methoden und die Motivation hinter der Verbesserung der Kibana-Dashboard-Leistung. Dies ist ein Update zu dieser Initiative.)