Was Abwärtskompatibilität für die Kibana-Dashboards API bedeutet

Während der technischen Vorschau kann sich die API-Struktur zwischen den Releases ändern.[1] Diese Zeiten sind vorbei. Allgemeine Verfügbarkeit (General Availability, GA) bedeutet:

• Vollständige Abwärtskompatibilität. Im Laufe der Zeit werden neue Felder und Paneltypen hinzugefügt, aber bestehende Felder und Verhaltensweisen bleiben unverändert. Alle zukünftigen kompatibilitätsbrechenden Änderungen würden sehr sorgfältig geprüft und nur in einer neuen Haupt-Stack-Version eingeführt.

• Produktionsbereit mit voller Unterstützung. Die API bietet die vollständigen Support-Garantien von Elastic. Sie können es bedenkenlos in Produktionsumgebungen für automatisierte Deployments, Umgebungs-Promotion und programmatisches Dashboard-Management verwenden.

Neue Kibana-API-Endpoints für die Panels „Tags“, „Markdown“ und „Links“

Elastic 9.5 führt außerdem einen neuen eigenständigen Endpoint für Tags ein, der es ermöglicht, Dashboards zu kategorisieren und zu filtern. Sie können diese nun programmatisch über dedizierte CRUD-Endpoints verwalten, was die Organisation von Dashboards in großem Umfang über verschiedene Umgebungen hinweg vereinfacht.

Neue Endpoints für die Markdown- und Links-Bedienfelder sind ab sofort in Serverless verfügbar und werden in der nächsten Stack-Version (9.6) implementiert.

Welche Panel-Typen unterstützt die Kibana-Dashboards-API?

Die Dashboards-API unterstützt alle By-Value-Panels in Version 9.5 (d. h. diejenigen, die direkt in einem Dashboard definiert wurden, im Gegensatz zu Bibliotheks-Panels, die zur Wiederverwendung gespeichert wurden). Jeder unterstützte Paneltyp verfügt über ein typisiertes, validiertes Schema.

Panel-Typ

Status

XY-Diagramme

Ja

Metriken

Ja

Kreisdiagramm

Ja

Messgerät

Ja

Heatmap

Ja

Datentabellen

Ja

Treemap

Ja

Discover Sitzungen

Ja

Steuerungen

Ja

Markdown

Ja

Links

Ja

ML-Panels

Ja

Observability-Panels

Ja

Maps

Demnächst verfügbar

Vega

Demnächst verfügbar

Wie man Kibana-Dashboards als Code verwaltet

Die Dashboards-API ermöglicht einen vollständigen „Dashboards-as-Code“-Workflow: Exportieren Sie ein Dashboard als sauberes, vergleichbares JSON, übertragen Sie es als maßgebliche Quelle in Git, überprüfen Sie Änderungen in Pull-Anfragen und stellen Sie dieselbe Definition in den Umgebungen Entwicklung, Staging und Produktion bereit. Sobald ein Dashboard als Code verwaltet wird, ist Git als einzige Quelle der Wahrheit zu behandeln: Änderungen, die direkt in der Benutzeroberfläche vorgenommen werden, werden beim nächsten Bereitstellen überschrieben.

Die größte Herausforderung beim Verschieben eines Dashboards zwischen Bereichen, Clustern oder Phasen besteht darin, dass Dashboards auf Objekte wie Datenansichten und Bibliotheksvisualisierungen anhand ihrer ID verweisen. Da diese IDs automatisch generiert werden und sich je nach Umgebung unterscheiden, kann ein aus einer Umgebung exportiertes Dashboard auf Objekte verweisen, die in einer anderen Umgebung nicht vorhanden sind. Es gibt drei Möglichkeiten, dies zu handhaben, hier aufgelistet von der am stärksten automatisierten bis zur am wenigsten automatisierten:

• Benutzen Sie Terraform. Der Elastic Stack Terraform Provider verfolgt jede Ressource und ordnet IDs pro Umgebung automatisch zu, sodass die Referenzen konsistent bleiben, wenn Sie ein Dashboard von der Entwicklung bis zur Produktion überführen.

• Nach Wert definieren Elasticsearch Abfragesprache (ES|QL)-Panels. Die portabelste Methode zum Erstellen eines Panels besteht darin, dessen Visualisierung mit ES|QL direkt im Dashboard zu definieren. Eine ES|QL-Abfrage liest aus den von Ihnen genannten Indizes, sodass das Panel keine externen Referenzen auf Data view oder Bibliotheksobjekte enthält. Das Ergebnis ist ein vollständig autarkes, portables Dashboard.

• Weisen Sie passende IDs zu. Wenn Sie auf gespeicherte Objekte wie Data View oder Bibliotheksvisualisierungen verweisen, erstellen Sie diese mit einer ausgewählten ID mittels PUT (upsert) anstatt mit POST (das automatisch eine ID generiert). Verwenden Sie für Menschen lesbare IDs, wie beispielsweise „logs-prod“, damit diese in verschiedenen Umgebungen leicht wiederverwendet und erkannt werden können.

Eine ausführliche Anleitung zu diesen Portabilitätsmustern und dem vollständigen Dashboards-as-Code-Workflow finden Sie in der Dokumentation Dashboards als Code verwalten.

Erstellen Sie ein Kibana-Dashboard mit der Dashboards-API mithilfe von PUT

Hier ein kurzes Beispiel zur Erstellung eines Dashboards mit einem Metrikbereich. Dabei wird PUT anstelle von POST verwendet, um eine benutzerdefinierte ID anhand des Dashboard-Namens (service-health-overview) zuzuweisen. Dieselbe Logik funktioniert auch für die Erstellung eigenständiger Visualisierungen, die in der Bibliothek gespeichert werden.

Kibana Dashboards API-Roadmap: Maps, Vega und eigenständige Endpoints

Wir erweitern aktiv die API-Schnittstelle. Als nächstes folgt die Unterstützung für Maps und Vega-Panels, wobei typisierte Schemas dafür hinzugefügt werden. Wir entwickeln außerdem eigenständige CRUD-Endpunkte für Discover-Sitzungen (zusätzlich zu ihrer bestehenden Unterstützung als Dashboard-Panels), Vega, Maps und Annotations, die vom Dashboard-Lebenszyklus entkoppelt sind.

Für die vollständigen Schema-Definitionen besuchen Sie die Dashboards API-Dokumentation. Für Terraform-Nutzer unterstützt der Elastic Stack Terraform-Provider die GA Dashboards API.

Anmerkung

1. Die Kern-Endpoints sind gegenüber der technischen Vorschau unverändert. Wenn Sie Integrationen für 9.4 erstellt haben, funktionieren sie in 9.5. Die einzigen kompatibilitätsbrechenden Änderungen sind zwei geringfügige, die sich auf die Formate für Dashboard-Auflistungen und Dauereinheiten auswirken und hier dokumentiert sind.

Was ist neu bei der Erstellung von KI-Dashboards in Kibana?

Funktionalität

Technische Vorschau (9.4)

GA (9.5)

Fehlerbehandlung

Kein Wiederholungsversuch bei fehlgeschlagenen ES|QL-Abfragen

Automatischer, bis zu dreimaliger erneuter Versuch mit Abfrageprüfung und Anpassung

ES|QL-Generierungskosten

Alle Abfragen werden über das primäre Modell weitergeleitet

Gestaffelte Modellrouten, bis zu fünfmal günstiger

Zeitbereich

Festgelegtes Standardfenster

Automatische Auswahl basierend auf der Daten-Zeit-Verteilung

Filtersteuerungen

Nein

Automatisch für die relevantesten Felder

Vega-Lite-Diagramme

Nein

Erstellung in natürlicher Sprache, mit Streudiagrammen, Boxplots, bedingter Formatierung und benutzerdefinierten Tooltips

Diagrammbearbeitung

Nein

Bestehende Vega-Lite-Panels können in natürlicher Sprache bearbeitet werden

Automatische Fehlerbehebung bei der KI-Dashboard-Generierung

In der technischen Vorschau wurden fehlgeschlagene ES|QL-Abfragen vom Agenten nicht wiederholt. In Version 9.5 werden Abfragefehler erkannt und die Abfrage bis zu dreimal wiederholt, wobei jeder Fehler untersucht und die Abfrage angepasst wird, bevor der Agent aufgibt. In der Praxis beseitigt dies die meisten Probleme mit leeren Panels und erzeugt Dashboards, die schon beim ersten Versuch korrekt gerendert werden.

Warum ist die Erstellung von KI-Dashboards in Elastic 9.5 günstiger?

Nicht jeder Schritt bei der Dashboard-Erstellung erfordert das gleiche Maß an Argumentation. In Version 9.5 erfolgt die ES|QL-Generierung standardmäßig über ein leichteres Modell und greift nur bei Bedarf auf das primäre Modell zurück. Wenn Ihr Connector Claude Opus 4.8 von Anthropic verwendet, bedeutet das fünfmal günstigere Kosten für die ES|QL-Generierung in allen Panels.

Automatische Zeitbereichsauswahl auf der Grundlage Ihrer Daten

Dashboards sind nur dann nützlich, wenn sie den richtigen Datenausschnitt anzeigen. Der Agent wendet nun eine verbesserte Logik an, um einen für die abgefragten Daten sinnvollen Zeitbereich auszuwählen, es sei denn, der Nutzer fragt nach einem bestimmten Zeitbereich. Er berücksichtigt die Zeitverteilung der Daten und passt sich entsprechend an, seien es die letzte Stunde für einen Live-Vorfall oder die letzten 90 Tage für eine Trendanalyse, anstatt standardmäßig auf ein festes Zeitfenster zurückzugreifen.

Automatische Filtersteuerungen auf KI-generierten Dashboards

Die Erstellung von Dashboards unterstützt nun Steuerelemente; das heißt interaktive Filter, mit denen die Betrachter ein Dashboard nach Feldwerten eingrenzen können, ohne die zugrunde liegenden Abfragen bearbeiten zu müssen. Beim Generieren eines Dashboards fügt der Agent am oberen Rand automatisch Steuerelemente für die relevantesten Filterfelder hinzu.

Vega-Lite-Diagramme aus natürlicher Sprache: Diagrammtypen und Formatierung jenseits der Standardeinstellungen

Vega und Vega-Lite unterstützen in Kibana eine breite Palette von Diagrammtypen und Anpassungen. Mit Version 9.5 können Sie sie aus einfacher Sprache erstellen und müssen den Code nicht selbst schreiben. 

Streudiagramme, Boxplots und weitere Diagrammtypen in Vega-Lite

Streudiagramme, Boxplots, facettierte Small Multiples, Blasendiagramme und Kompositionsdiagramme (z. B. Histogramme, kombiniert mit Heatmaps) sowie viele andere werden von Vega-Lite unterstützt. Ein Prompt wie Zeig mir ein Streudiagramm zu Reaktionszeit vs. Anfragegröße, farbig nach Dienstprogrammname erzeugt ein Vega-Lite-Panel mit den richtigen Datenzuordnungen. Die Diagramme verwenden die Standardfarbpaletten von Kibana, um sich harmonisch in das restliche Dashboard einzufügen.

Bedingte Formatierung, benutzerdefinierte Tooltips und Beschriftungen auf Standarddiagrammen

Selbst bei Diagrammtypen, die in einem Dashboard bereits systemeigen sind, zum Beispiel Balkendiagramme, Liniendiagramme oder Flächendiagramme, benötigen Sie manchmal mehr Kontrolle, als die Standardfunktionen bieten. Vega-Lite schließt diese Lücke über den Chat. Zu den Beispielen gehören:

• Bedingte Farbformatierung: Datenpunkte oberhalb eines Schwellenwerts können farbig anders dargestellt werden; beispielsweise werden Datenpunkte in einem Liniendiagramm oder in Balkendiagrammen rot eingefärbt, wenn eine Kennzahl über das Service Level Objective (SLO) hinausgeht. Bitten Sie den Agenten etwa: Färbe alle Punkte über 500 ms für mein Liniendiagramm rot ein.

  

• Individuelle Markierungen und Beschriftungen: Fügen Sie Emojis, Symbole oder Inline-Textbeschriftungen zu Datenpunkten hinzu, um den Status auf einen Blick zu erkennen.

  

• Individuelle Tooltips: Reichern Sie Hover-Zustände mit zusätzlichen Metriken, Kontext oder berechneten Werten an, die nicht Teil der Diagrammachsen sind. Formulieren Sie etwas wie Füge einen Tooltip hinzu, der die Gesamtzahl der Datensätze und den Prozentsatz pro Balkendiagramm anzeigt.

  

Das funktioniert auch bei der Bearbeitung vorhandener Vega-Charts. Wenn Sie ein Vega-Lite-Panel haben, das eine Anpassung wie z. B. das Ändern einer Farbskala, das Anpassen einer Achse oder ein Umschalten des Markierungstyps benötigt, beschreiben Sie die Änderung im Chat, anstatt sich in den JSON-Code einzuarbeiten.

So haben wir die Vega-Lite-Generierung in natürlicher Sprache in Kibana entwickelt

Das Generieren eines Vega-Lite-Diagramms aus einem Satz heraus ist kein einmaliger Prompt à la Bitte das Modell um JSON. Wir haben eine kleine agentenbasierte Pipeline aufgebaut, die natürliche Sprachabsicht in ein validiertes, datenbasiertes Diagramm umsetzt.

Wenn eine Anfrage eingeht, prüft der Agent zunächst, ob Vega-Lite die richtige Lösung ist. Für Vega-Lite-Anfragen verankert er die Visualisierung in einer echten ES|QL-Abfrage bei Elasticsearch und verwendet dann ein Modell, um den Vega-Lite-Code zu generieren. Vor dem Rendern durchläuft das Ergebnis eine Normalisierungsschicht, die das Schema korrigiert und die kanonische Abfrage bindet. Er wendet außerdem rendersichere Umwandlungen an.

Einige wenige Designentscheidungen machen diesen Workflow zuverlässig:

• Eingetippter Toolaufruf: Die Diagrammerstellung ist ein strukturierter Tool-Aufruf und kein Vega-Lite, das in die Konversation eingefügt wird.

• Beschränkte Generierung: Das Modell erzeugt Vega-Lite-Code innerhalb eines definierten Schemas, was die Ausgabe vorhersehbarer und leichter validierbar macht.

• Kuratierte Beispiele: Strukturelle Muster wie Facetten, geschichtete Markierungen und Heatmaps bieten Orientierung, ohne die zugrunde liegenden Daten zu kopieren.

• Ausführungs- und Verifikationsschleifen: Abfragen werden vor der Diagrammerstellung ausgeführt, und Validierungsfehler lösen Korrekturversuche für die ES|QL-Generierung aus.

Testen Sie die Erstellung von KI-Dashboards und Vega-Lite-Diagrammen in Kibana

Um die Erstellung von Dashboards mit natürlicher Sprache und Vega-Lite-Diagramme auszuprobieren, aktualisieren Sie auf Elastic 9.5 (oder starten eine kostenlose Testversion) und öffnen den Chat in Kibana. Bitten Sie das System anschließend, aus Ihren Daten ein Dashboard zu erstellen. Bei Vega-Lite können Sie versuchen, einen Diagrammtyp anzufordern, den Sie schon immer einmal erstellen wollten, zum Beispiel ein Streudiagramm oder ein Blasendiagramm. Wenn das Ergebnis nicht ganz stimmt, sagen Sie dem Agenten, was er ändern soll. Er wiederholt den Vorgang dann entsprechend.

Dafür ist eine Enterprise-Lizenz erforderlich. Erste Schritte.

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.

Jedes Jahr zwingen Naturkatastrophen Notfallmanager, militärische Befehlshaber und Verantwortliche für die öffentliche Sicherheit dazu, unter hohem Zeitdruck weitreichende Entscheidungen zu treffen. Diese Entscheidungen basieren traditionell auf Telefonketten, Tabellen und institutionellem Wissen, das über Dutzende von Personen verteilt ist. Allein der Koordinationsaufwand kostet entscheidende Zeit.

Dieser Beitrag zeigt, wie Elastic ein reaktionsschnelles, agentisches Koordinationssystem für die Katastrophenreaktion antreiben kann, das eine Bedrohung erkennt, die Logistik durchdenkt und automatisch handelt. Um dies zu veranschaulichen, haben wir eine Simulation erstellt: Ein fiktiver Hurrikan der Kategorie 4, der die Küste von Hampton Roads bedroht, löst die automatische Verlegung von über 137.000 Einsatzkräften über sieben Militäreinrichtungen hinweg aus.

Hinweis: Dies ist ein rein fiktives Szenario, das zu Demonstrationszwecken erstellt wurde. Den Hurrikan ELARA-26 gibt es nicht. Die Standorte der Einrichtungen basieren auf echten, öffentlich zugänglichen geografischen Daten (dem Datensatz „Military Installations, Ranges, and Training Areas [MIRTA]“ des US-Verteidigungsministeriums [DoD]), aber alle operativen Daten wie Personalzahlen, Unterbringungskapazitäten, Ressourcen, Kontakt-E-Mails und Missionsprofile sind frei erfunden. Nichts in dieser Demo spiegelt die tatsächliche militärische Einsatzbereitschaft, Fähigkeiten oder operative Abläufe wider.

Warum eine automatisierte Katastrophenreaktion georäumliche und agentische Koordination erfordert

Wenn eine Naturkatastrophe kritische Infrastrukturen bedroht, ist die Koordinationsherausforderung unmittelbar:

• Welche Einrichtungen befinden sich in der Gefahrenzone?

• Wie viele Einsatzkräfte müssen versetzt werden?

• Wohin können sie gehen und verfügen diese Einrichtungen über Kapazitäten?

• Wer muss jetzt benachrichtigt werden?

Diese Fragen können nicht warten. Und das sollten die Antworten auch nicht.

Pipeline bereitstellen: Voraussetzungen und Einrichtung

Befolgen Sie die Anweisungen hier im Beispiel-Repo, um über Cloud Connect einen lokalen Elastic-Cluster mit Elastic Inference Service (EIS) bereitzustellen.

Wie die agentische Katastrophenreaktions-Pipeline von Elasticsearch funktioniert

Die Pipeline hat sieben Schichten, die durchgängig zusammenarbeiten:

1. Dateningestion: Katastrophenereignisse des Global Disaster Alert and Coordination System (GDACS) werden an Elasticsearch gesendet

2. Ingest-Pipeline: GeoJSON wird eingelesen und an das Elastic Common Schema (ECS) angepasst.

3. Geodaten-Anreicherung: Das Polygon des betroffenen Bereichs des Ereignisses wird mit indexierten Grenzen von Militäreinrichtungen abgeglichen.

4. Alerting: Eine Kibana-Erkennungsregel wird ausgelöst, wenn sich eine Katastrophe mit einer Installation überschneidet.

5. Workflow-Automatisierung: Die Warnung löst einen Kibana-Workflow aus, der eine Unterhaltung mit einem KI-Agenten startet.

6. KI-Argumentation: Der Agent analysiert die betroffenen Einrichtungen, deren Assets und die nächstgelegenen unterstützenden Einrichtungen, um die Verlagerung aller Ressourcen und des Personals zu bestimmen.

7. E-Mail-Benachrichtigungen: Der Agent versendet E-Mails an alle Empfänger für ein- und ausgehendes Personal und/oder Assets.

Sehen wir uns die einzelnen Schichten einmal an.

Schritt 1: Indexieren von militärischen Einrichtungen mit Geo-Grenzen

Die Grundlage bildet der DoD-MIRTA-Datensatz von source.coop/seerai/hifld. Dieser Datensatz stellt für jede Installation eine geo_shape vom Typ Point bereit; es werden Zentroid-Koordinaten statt vollständiger Grenzpolygone verwendet.

Jedes Installationsdokument im Index „mitra-facilities“ wird mit operativen Profildaten (alle fiktiv) angereichert – über das hinaus, was MIRTA bereitstellt:

Dieser umfangreiche Index ermöglicht es dem KI-Agenten, intelligente Zuweisungsentscheidungen zu treffen; nicht nur „hier sind nahegelegene Stützpunkte“, sondern „hier sind Stützpunkte mit verfügbarer Unterbringungskapazität, kompatiblen Missionstypen und der Logistik, um eingehende Ressourcen aufzunehmen.“

Schritt 2: Ingestieren und Normalisieren von GDACS-Ereignissen

GDACS veröffentlicht Echtzeit-GeoJSON für Erdbeben, tropische Wirbelstürme, Überschwemmungen, Waldbrände, Vulkane und Dürren. Wir importieren diesen Feed in einen Datenstream (logs-gdacs.events-*) mithilfe einer benutzerdefinierten Ingest-Pipeline, die das rohe GeoJSON auf ECS-Felder normalisiert.

Die GDACS Ingest-Pipeline erledigt mehrere Dinge, die es zu beachten gilt:

Geometrieextraktion: Der Zentroid wird für die Kartenanzeige als geo_point gespeichert und das Auswirkungspolygon wird als geo_shape in gdacs.affected_area gespeichert, bei dem es sich um das Feld handelt, das später für Schnittmengenabfragen verwendet wird.

Normalisierung der Schweregrade: Jede Art von Katastrophe hat eine andere Schweregradskala. Ein tropischer Wirbelsturm wird anhand der Windgeschwindigkeit in km/h gemessen; ein Erdbeben anhand der Richter-Magnitude. Die Pipeline ordnet sie alle einem normalisierten Score von 0–100 zu:

Der normalisierte Schweregradwert wird dann einem severity_level-Label (low, medium, high, critical) zugeordnet, das für das Alert-Schweregrad-Mapping in der Erkennungsregel verwendet wird.

ECS-Ausrichtung: event.kind: alert, event.category: Bedrohung, Zeitstempel auf event.start/event.end abgebildet, und eine stabile, fingerprintbasierte _id zur Deduplizierung.

Schritt 3: Georäumliche Anreicherung: Ermitteln betroffener Einrichtungen zur Indexzeit

Die geo_match-Anreicherungsrichtlinie von Elasticsearch gleicht das Katastrophenpolygon beim Indexieren mit jeder Installationsgrenze ab, ohne dass ein Join zum Abfragezeitpunkt erforderlich ist. Anstatt zum Suchzeitpunkt eine Abfrage durchzuführen, verwenden wir einen Anreicherungsprozessor in der Ingest-Pipeline, um das Auswirkungspolygon der Katastrophe beim Indexieren des Dokuments mit jeder Installationsgrenze abzugleichen.

Die Anreicherungsrichtlinie ist eine geo_match-Richtlinie:

Der Prozessor wird am Ende der Ingest-Pipeline ausgeführt:

INTERSECTS erfasst jede Anlage, deren Begrenzung das Katastrophenpolygon berührt oder überlappt, und sogar partielle Überschneidungen. Das Ergebnis ist, dass jedes GDACS-Ereignisdokument mit einem verschachtelten affected_facilities-Array gespeichert wird, das uns genau verrät, welche Anlagen sich in der betroffenen Zone befinden. Keine Join-Abfrage erforderlich.

Schritt 4: Erkennungsregel: Alerting bei Auswirkungen auf Einrichtungen

Eine Kibana-Erkennungsregel überwacht den logs-gdacs.events-* Datenstrom und wird ausgelöst, wenn ein GDACS-Ereignis mit mindestens einer betroffenen Einrichtung angereichert wurde:

Die Regel wird stündlich ausgeführt (deckt ein Zeitfenster von jetzt-1h bis jetzt ab) und verwendet dynamisches Schweregrad-Mapping; das gdacs.severity_level- Feld, das von der Ingest-Pipeline berechnet wird, steuert den Alert-Schweregrad automatisch.

Der Alert-Schweregrad bestimmt die Risikobewertung auch über das Feld-Mapping:

Wenn die Regel ausgelöst wird, übergibt sie den vollständigen Alert-Kontext, einschließlich des angereicherten affected_facilities-Arrays mit Installationsnamen, -typen und -standorten, an einen nachgelagerten Kibana-Workflow.

Schritt 5: Workflow-Automatisierung: Verbindung von Alarm und Agent

Kibana-Workflows übernehmen die Übergabe von der Erkennung zur Reaktion. Der Workflow zur Reaktion auf Naturkatastrophen wird durch den Alarm ausgelöst:

Die gesamte Alert-Payload (Katastrophentyp, Schweregrad, betroffenes Gebiet und die Liste der betroffenen Installationen) wird als anfänglicher Kontext an den KI-Agenten weitergeleitet. Ab hier übernimmt der Agent.

Schritt 6: Der KI-Agent: Von Daten zu koordinierter Aktion

Der mitra.response-Agent übernimmt die vollständige Alert-Payload und bewertet in einer einzigen agentenbasierten Schleife den Umfang, ermittelt Aufnahmeeinrichtungen, weist Personal zu und versendet Evakuierungs- und Aufnahmebenachrichtigungen – alles ohne menschliches Eingreifen.

Dem Agenten stehen zwei Tools zur Verfügung:

• mitra.nearest_facilityfragt den Index „mitra-facilities“ mithilfe einer geo_shape-Abfrage ab, sortiert nach der Entfernung von einer angegebenen Koordinate, und gibt bis zu 50 aktive Installationen in der Nähe mit verfügbarer Kapazität zurück.

• mitra.send_email iteriert über ein JSON-Array von Einrichtungsobjekten und versendet formatierte Evakuierungs- oder Aufnahmebenachrichtigungen.

Der Anweisungssatz des Agenten definiert einen klaren Workflow:

1. Bewerten der Situation. Parsen Sie den Alert, identifizieren Sie betroffene Einrichtungen und bestimmen Sie das Ausmaß der Katastrophe.

2. Inventarisieren, was verschoben werden muss. Mitarbeiterzahlen, kritische Assets, Unterbringungsanforderungen pro Einrichtung.

3. Zieleinrichtungen ermitteln. Rufen Sie mitra.nearest_facility für jede betroffene Installation auf, wobei Einrichtungen herausgefiltert werden, die sich noch in der Gefahrenzone befinden.

4. Zuteilungsentscheidungen treffen. Wägen Sie Single- versus Multi-Facility-Lösungen, Zweigstellenkompatibilität, Unterbringungskapazität und Asset-Support ab.

5. Koordinierungs-E-Mails senden. Evakuierungsanordnungen an Ausgangseinrichtungen und Aufnahmebenachrichtigungen an Aufnahmeeinrichtungen übermitteln.

6. Einen zusammenfassenden Bericht erstellen. Erstellt eine kurze Zusammenfassung aller betroffenen Einrichtungen, des gesamten Personals, der verschobenen Assets, der Zieleinrichtungen und etwaiger Bedenken zur Überprüfung im Chat.

Die Zuweisungslogik des Agenten folgt realen Einschränkungen: Unterbringungskapazitäten nicht überschreiten, wenn möglich Versetzungen innerhalb desselben Zweigs bevorzugen, gemeinsame Stützpunkte bei zweigübergreifendem Überlauf nutzen und die Entfernung priorisieren, um die Transitzeit zu minimieren.

Das Tool für die nächstgelegene Einrichtung

Die zugrunde liegende Workflow-Abfrage verwendet geo_shape mit einem circle-Filter und einer _geo_distance-Sortierung:

Die verfügbare Kapazität wird zum Abfragezeitpunkt über ein Skriptfeld berechnet, das die Unterbringungskapazität abzüglich des aktuellen Personalbestands ermittelt. Der Agent verwendet dies, um Personal auf Zielorte zu verteilen, ohne Grenzen zu überschreiten.

Hurrikan ELARA-26: agentische Koordination von 137.000 Einsatzkräften, von Anfang bis Ende

Hurrikan ELARA-26 ist ein Sturm der Kategorie 4 (maximale Windgeschwindigkeit von 213 km/h), der laut Vorhersage im Gebiet Hampton Roads in Virginia auf Land treffen wird. Wenn das GDACS-Ereignis aufgenommen wird, schneidet das Polygon des betroffenen Gebiets sieben wichtige Militäreinrichtungen in der Region. Die Erkennungsregel wird ausgelöst. Der Workflow startet eine Agentenkonversation.

Innerhalb einer einzelnen agentischen Schleife führt der Agent Folgendes aus:

• Sieben Einrichtungen in der Einschlagszone wurden identifiziert, mit insgesamt 137.372 Einsatzkräften.

• mitra.nearest_facility wurde angerufen, um Empfangseinrichtungen außerhalb des Sturmpfads zu finden.

• Einsatzkräfte wurden basierend auf der verfügbaren Unterbringungskapazität und Entfernung auf neun Aufnahmeeinrichtungen verteilt.

• Evakuierungsanordnungen wurden für alle sieben betroffenen Anlagen erstellt und versandt.

• Aufnahmebenachrichtigungen wurden erstellt und an alle neun empfangenden Einrichtungen versandt.

• Eine vollständige Koordinationszusammenfassung wurde erstellt, ähnlich wie unten:

Evakuierte Einrichtungen:

Einrichtung

Einsatzkräfte

Naval Station Norfolk

50.000

Joint Expeditionary Base Little Creek-Fort Story

18.000

Naval Air Station Oceana

15.355

Naval Air Station Oceana Dam Neck Annex

17.509

NG State Military Reservation Camp Pendleton

9.707

Joint Base Langley-Eustis

15.000

Naval Weapons Station Yorktown

11.801

Aufnahmeeinrichtungen:

Einrichtung

Distanz

Eingehende Einsatzkräfte

Fort Gregg-Adams

97 km

~40.000

Marine Corps Base Quantico

148 km

~30.000

Naval Support Facility Indian Head

151 km

~30.000

Joint Base Andrews

180 km

~30.000

Naval Air Station Patuxent River

141 km

~10.000

NG MTA Camp Butner

174 km

~5.000

NG Bethany Beach Training Site

209 km

~4.707

Rivanna Station

140 km

~7.500

Def Gen Supply Center

22 km

~6.000

Zu den verlegten Einsatzmitteln gehören Transportfahrzeuge, Hubschrauber, Patrouillenboote, medizinische Einheiten, Pionierfahrzeuge, Generatoren, Wassertankanhänger, Notunterkunfts-Sets und Kommunikationssysteme.

Automatisierte E-Mail-Benachrichtigungen

Sobald der Agent seinen Zuweisungsplan fertiggestellt hatte, rief er mitra.send_email auf und versandte in einem einzigen Durchlauf 16 E-Mails, nämlich Evakuierungsanordnungen an alle sieben betroffenen Einrichtungen und Aufnahmebenachrichtigungen an alle neun aufnehmenden Einrichtungen. Jede Nachricht enthielt die Zieleinrichtung, die Anzahl der eintreffenden Personen, die zu verlegenden Assets und einen Ansprechpartner für die Koordination. Was andernfalls Stunden an Telefonketten erfordert hätte, wurde automatisch erledigt, sobald der Agent seine Überlegungen abgeschlossen hatte.

Erweiterung der agentischen Katastrophenreaktion mit RAG und Richtlinienverankerung

Diese Demo basiert rein auf strukturierten Daten wie Kapazitätszahlen, Entfernungen und Betriebsstatus. Die Funktionen von Elastic für semantische Suche und Retrieval-Augmented Generation (RAG) können den Agenten durch zwei Ergänzungen deutlich intelligenter machen:

Abruf historischer Reaktionen: Indexieren Sie frühere After-Action-Berichte, Vorfallszusammenfassungen der Federal Emergency Management Agency (FEMA) und Einträge zur Katastrophenreaktion als Vektoreinbettungen. Wenn ein neues Ereignis ausgelöst wird, kann der Agent semantisch abrufen, wie ähnliche Ereignisse gehandhabt wurden, und so Zuteilungsentscheidungen mit institutionellem Wissen statt reiner Kapazitätsberechnung fundieren.

Verankerung in Richtlinien und Doktrin: Indexieren Sie DoD-Richtlinien für das Notfallmanagement, Pläne zur Aufrechterhaltung des Betriebs der Einrichtung und Anweisungen des Kommandeurs. Der Agent kann die tatsächlichen Richtlinien abrufen und zitieren, die eine Reaktion regeln, und so sicherstellen, dass jede Entscheidung in der Doktrin und nicht in Schlussfolgerungen verankert ist.

Beide folgen demselben Elastic-nativen Ansatz:; Eine Inferenz-Pipeline generiert Einbettungen beim Indexieren, und dem Agenten wird ein Tool für die semantische Suche bereitgestellt. Die Koordinierungs-Pipeline bleibt unverändert. Der Agent wird einfach intelligenter.

Warum Elasticsearch die richtige Plattform für die agentische Reaktion im öffentlichen Sektor ist

Das ist kein Chatbot. Es ist kein Dashboard. Es ist ein responsives agentisches Workflow-System – eines, das eine Bedrohung erkannt, ein komplexes Logistikproblem durchdacht und die Versetzung von 137.000 Menschen ohne menschliche Beteiligung koordiniert hat. Ein solches Ergebnis ist nur möglich, weil jede Funktion, auf die es angewiesen ist, auf einer einzigen, einheitlichen Plattform liegt.

Die Geodatenunterstützung von Elasticsearch (geo_point, geo_shape, Anreicherungsrichtlinien und entfernungsbasierte Sortierung) übernimmt das räumliche Denken, das Schnittpunkterkennung und die Standortsuche im großen Maßstab möglich macht. Semantische Suche und Vektor-Einbettungen verankern Agenten in der Realität und stellen sicher, dass KI-Schlussfolgerungen auf den tatsächlichen Inhalten Ihrer Daten basieren und nicht auf halluzinierten Annahmen. Die Erkennungs-Engine, Workflows, der Agent Builder und die Agent Builder-Tools von Kibana verbinden all dies zu einer Pipeline, die vom Rohereignis bis zur koordinierten Aktion reicht – ganz ohne externen Glue-Code.

Keine andere Plattform bringt dies so zusammen wie Elastic. Die Kombination aus Echtzeit-Indexieren, georäumlicher Präzision, semantischem Abrufen und agentischer Orchestrierung in einem einzigen Stack mit integrierter Sicherheit und Beobachtbarkeit auf Enterprise-Niveau unterscheidet Elastic von Tools, die eine dieser Aufgaben zwar gut bewältigen, bei denen Sie den Rest jedoch selbst zusammenfügen müssen.

Agentische georäumliche Reaktion für Notfallmanagement, Feuerwehr, Strafverfolgung und öffentliche Gesundheit

Dieselbe Architektur gilt überall dort, wo Menschen, Einrichtungen und Echtzeitereignisse aufeinandertreffen. Die spezifischen Daten ändern sich. Die Pipeline nicht.

Katastrophenschutz: FEMA und die Katastrophenschutzbehörden der Bundesstaaten können Standorte von Notunterkünften, Bereitstellungsräume und gefährdete Bevölkerungsgruppen mit eingehenden Unwetter-Polygonen des National Weather Service (NWS) abgleichen und so die automatisierte Vorabpositionierung von Ressourcen auslösen, bevor ein Sturm das Festland erreicht.

Feuerwehr und Rettungsdienste: Feuerwehren können die Standorte von Einheiten und Reaktionszonen mit Waldbrandgrenzen oder Gebäudebrand-Clustern überlagern und Anforderungen für überörtliche Hilfe automatisch an die nächstgelegenen verfügbaren Einheiten mit der passenden Ausrüstung weiterleiten.

Strafverfolgung: Behörden können Standorte aktiver Vorfälle mit Schulzonen, kritischer Infrastruktur und den Positionen von Einsatzkräften korrelieren und so ohne Warten auf eine manuelle Triage standortbezogene Lockdown-Benachrichtigungen oder die Entsendung von Ressourcen auslösen.

Sicherheit an öffentlichen Schulen: Schulbezirke können Bedrohungsfeeds in Echtzeit im Hinblick auf Campusgrenzen überwachen. Wenn eine Bedrohung die Grenzen eines Schulgeländes überschreitet, kann ein Agent sofort die Schulleitung benachrichtigen, die Lockdown-Kommunikation einleiten und die Reaktion der Strafverfolgungsbehörden koordinieren – noch bevor ein Disponent zum Telefon greift.

Öffentliches Gesundheitswesen: Gesundheitsbehörden können Daten zur Krankheitsüberwachung oder Umweltgefahrenzonen mit Klinikstandorten, Ebenen zur Bevölkerungsdichte und Beständen in Versorgungsdepots abgleichen, um Ressourcen dorthin zu leiten, wo sie am dringendsten benötigt werden.

Sektor

Anwendungsfall

Fähigkeit von Elastic

Notfallmanagement

Standorte von Notunterkünften mit NWS-Unwetterpolygonen abgleichen

geo_shape-Anreicherung + Kibana-Workflows

Feuerwehr und Rettungsdienst

Einheitenstandorte mit Waldbrandperimetern überlagern

geodatenbasiertes Routing + Abfrage der nächstgelegenen Einrichtung

Strafverfolgung

Vorfälle mit Schulzonen und Positionen von Beamten korrelieren

standortbezogene Alert-Regeln + Agent-Dispatch

Sicherheit an öffentlichen Schulen

Überwachen von Bedrohungsfeeds im Hinblick auf Campus-Perimeter

Erkennungsregeln + automatische Benachrichtigung

Öffentliche Gesundheit

Gefahrenzonen mit Klinikstandorten und Versorgungslagern abgleichen

semantische Suche + geodatenbasierte Anreicherung

Die Daten sind in jedem Szenario unterschiedlich. Das zugrunde liegende Muster aus Ingest, Datenanreicherung zur Indexzeit, Erkennung von Schnittmengen, Auslösen einer agentischen Reaktion und Handeln ist immer dasselbe. Elastic bietet Organisationen im öffentlichen Sektor die Platform, es einmal zu entwickeln und überall anzupassen.

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.

Der Agent erstellt Dashboards von Grund auf, arbeitet aber auch damit, was Sie bereits haben. Öffnen Sie die AI Chat-Seitenleiste, während Sie ein Dashboard aufrufen, dann wird es automatisch angehängt. Fragen Sie nach den Gründen für den plötzlichen Anstieg einer Kennzahl, analysieren Sie die Ergebnisse nach Regionen oder fügen Sie ein Vergleichspanel hinzu. Ihr bestehendes Dashboard wird zum Ausgangspunkt, nicht nur zum Endprodukt.

Hinter den Kulissen: So erstellen wir Dashboards im AI Chat

Wir vermitteln den Agenten spezifische Aufgaben durch Fertigkeiten – strukturierte Beschreibungen, wie man ein bestimmtes Problem angeht. Aber eine Dashboard-Fähigkeit aufzubauen bedeutete, einem LLM beizubringen, gültige Kibana-Dashboards zu generieren, und die alte Saved Object-API gestaltete dies schwierig: Umständlich verschachteltes JSON, subtile Änderungen von Version zu Version, ungenaue Referenzen. Wir brauchten einen anderen Ansatz

Eine speziell entwickelte API für programmatische Dashboards

Die neue Dashboards-API wurde genau für dieses Szenario entwickelt. Statt den internen Rohzustand offenzulegen, bietet es typisierte, validierte Schemata für jeden Paneltyp. Die API übernimmt die Übersetzung zwischen sauberen externen Strukturen und den internen Darstellungen von Kibana, sodass sich der Agent auf den Inhalt des Dashboards konzentrieren kann, anstatt auf dessen Formatierung.

Eine Fähigkeit, ein Tool, viele Einsatzmöglichkeiten

Der dashboard-management Skill stellt ein einzelnes manage_dashboard Tool zur Verfügung, das eine geordnete Reihe von Abläufen akzeptiert. Jeder Ablauf zählt als einzelne Aktion: Metadaten festlegen, ein Markdown-Panel hinzufügen, ES|QL-basierte Visualisierungen aus natürlicher Sprache erstellen, vorhandene Panels bearbeiten, Panels in ausklappbare Abschnitte gruppieren oder Elemente im Raster neu positionieren.

Der Agent kann in einem einzigen Aufruf ein komplettes Dashboard beschreiben: Titel, Beschreibung, Abschnitte und jedes darin enthaltene Panel:

Die Abläufe werden der Reihe nach ausgeführt, sodass spätere Schritte auf frühere verweisen und darauf aufbauen können. Dieses Design lenkt den Fokus der Konversation auf die Absicht und nicht auf Details der Umsetzung.

Die Visualisierungspipeline: Natürliche Sprache zu ES|QL zu Visualisierungen

Wenn Sie nach einem Dashboard fragen, untersucht der Agent Ihre Daten – Indizes, Feld-Mappings, Typen – plant dann die Visualisierungen und ruft manage_dashboard auf.

Jedes Panel durchläuft seine eigene Pipeline: Auswahl des Diagrammtyps, ES|QL-Generierung, Visualisierungskonfiguration und Validierung. Wir haben dies vom Haupt-Agent-Thread isoliert – die Erstellung der Visualisierung erfordert mehrere Modellaufrufe pro Panel, und die Einbindung in den Hauptkontext würde das Fenster aufblähen und die Argumentation schwächen.

Im manage_dashboard werden alle Panels gleichzeitig erstellt und dann in der richtigen Reihenfolge neu zusammengesetzt. Das Ergebnis ist ein vollständiges Dashboard mit eingebetteten Panels – keine verwaisten Visualisierungen, keine Synchronisierungsprobleme.

Warum wir die Erstellung von Visualisierungen in das Dashboard-Tool verlagert haben

Bei unserem ersten Ansatz haben wir ein separates create_visualization Tool verwendet – ein Aufruf pro Panel, um dann jeden Anhang an das Dashboard-Tool zu übergeben. Es funktionierte, aber jede Visualisierung brauchte ihren eigenen Tool-Aufruf, ihren eigenen Lebenszyklus und eine explizite Übergabe. Schlimmer noch, die Bearbeitung einer Visualisierung in der Konversation aktualisierte das Dashboard-Panel nicht, was die Nutzer verwirrte.

Wir haben die Erstellung von Visualisierungen direkt in manage_dashboard integriert. Es werden die gleichen parallelen Workflows ausgeführt, Panels jedoch ohne Zwischenanhänge zur Dashboard-Struktur zusammengesetzt. Weniger Aufrufe, keine Synchronisierungsprobleme, ein Lebenszyklus.

Einzelne Visualisierungen funktionieren weiterhin – Sie können bestehende Diagramme über Anhangsreferenzen in ein Dashboard einfügen – aber für die Erstellung von Grund auf ist die Inline-Erstellung der bessere Weg.

Für Sicherheitsteams

SOC-Analysten und Detection Engineers können es sich nicht leisten, mitten in einer Untersuchung zum Dashboard-Editor zurückzukehren. Mit dem AI Chat können Sie das Alarmvolumen nach Regeltyp, Host oder MITRE-Taktik abfragen und es in etwa einer Minute in Ihrem Thread sehen. Während die Suche fortschreitet, fügen Sie Panels hinzu – Anomalien bei der Prozessausführung, Netzwerkverbindungen, Zeitachsenvergleiche – ohne den Kontext zu unterbrechen.

Speichern Sie, wenn Sie fertig sind. Das Dashboard dient als Referenz für die Überprüfung nach Vorfällen, als Ausgangspunkt für den nächsten Analysten oder als wöchentliches Briefing zu Bedrohungen – eine erneute Erklärung ist nicht erforderlich.

Erfahren Sie in diesem Blogbeitrag mehr darüber, wie Sicherheitsteams Dashboard-Erstellungen und andere kürzlich eingeführte AI Chat-Funktionen nutzen können.

Für Observability- und Site Reliability Engineers (SREs)

Wenn ein Dienst um 2:00 Uhr nachts ausfällt, haben Sie keine Zeit, Dashboards von Grund auf neu zu erstellen. Mit dem AI Chat kann ein SRE die benötigten Kennzahlen beschreiben (P99-Latenz nach Dienst, Fehlerquote bei Deployment-Ereignissen, Pod-Neustarts in der letzten Stunde) und in etwa einer Minute ein vollständiges Dashboard im Untersuchungs-Thread erhalten. Der Agent kann die Darstellung schrittweise verfeinern, sobald sich das Bild klärt: Ein Panel hinzufügen, das Zeitfenster ändern, nach Regionen aufschlüsseln.

Speichern Sie das Dashboard, dann ist es sofort für alle im Lagezentrum verfügbar (gleiche Panels, gleiches Framing), die der Incident Bridge beitreten. Nach dem Vorfall wird es zur Grundlage für die Nachbesprechung.

Was kommt als Nächstes?

Wir arbeiten an der Token-Optimierung, reichhaltigeren Vollbild-Interaktionen, breiterer Panel-Unterstützung und kontinuierlichen Qualitätsverbesserungen. Die technische Vorschau ist der richtige Zeitpunkt, um Prioritäten zu setzen – falls etwas fehlt, teilen Sie uns dies über das Symbol „Feedback einreichen“ im oberen Menü mit.

Ausprobieren

Führen Sie ein Upgrade auf Elastic 9.4 durch (oder starten Sie eine Testversion), öffnen Sie den AI Chat im Vollbildmodus und probieren Sie ihn bei einer echten Untersuchung aus. Bitten Sie den Agenten, die von Ihnen betrachteten Kennzahlen grafisch darzustellen, und um die nächste Aufschlüsselung. Wenn die Geschichte stimmt, speichern und teilen Sie sie – gleiche Panels, gleiches Framing, keine erneute Erklärung nötig. Erfordert eine Unternehmenslizenz (Jetzt loslegen). Die Entscheidung über die Veröffentlichung der in diesem Blogbeitrag 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.

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

Was ist ein Kibana-Dashboard-Builder?

Wie wäre es, wenn Sie das gewünschte Dashboard in einfachem Englisch beschreiben könnten und es dann mit interaktiven Diagrammen, einem Drag-and-Drop-Layout und einem Export nach Kibana mit einem Klick erscheinen würde?

Genau das macht example-mcp-dashbuilder. Es handelt sich um eine Open-Source-Anwendung (Modellkontextprotokoll (MCP)), die KI-Assistenten mit Elasticsearch verbindet und es Ihnen ermöglicht, vollständige Kibana-Dashboards durch Konversation zu erstellen. Kein Durchklicken durch Menüs. Kein manuelles Schreiben von Visualisierungskonfigurationen. Beschreiben Sie einfach, was Sie benötigen, und die KI untersucht Ihre Daten, schreibt die ES|QL-Abfragen (Elasticsearch Query Language), erstellt die Diagramme und liefert ein lebendiges, interaktives Dashboard – alles im Chatfenster Ihres Editors.

Vom Prompt zum Dashboard in Sekunden

So sieht das in der Praxis aus. Sie geben beispielsweise Folgendes ein:

„Erstellen Sie mir ein Web-Traffic-Dashboard aus logstash-* mit Gesamtanfragen, übertragenen Bytes im Laufe der Zeit, wichtigen geografischen Quellen und einer Aufschlüsselung der Antwortcodes.“

Die KI daraufhin:

1. Erkennt Ihre Daten: Listet Indizes auf, inspiziert Feldzuordnungen.

2. Schreibt ES|QL-Abfragen: Angepasst an Ihr Schema, mit den richtigen Aggregationen.

3. Erstellt Visualisierungen: Balkendiagramme, Liniendiagramme, Metriken mit Sparklines, Heatmaps, Kreisdiagramme.

4. Organisiert alles: Zusammenklappbare Abschnitte, aussagekräftige Titel, ordentliches Layout.

5. Rendert eine interaktive Vorschau: Direkt im Chat, mit Tooltips, einem Zeitwähler und Drag-and-Drop.

Jedes Diagramm wird bei der Erstellung inline angezeigt, sodass Sie den Fortschritt in Echtzeit verfolgen können. Dann zeigt view_dashboard das vollständige Dashboard mit allen Panels, die im 48-spaltigen Raster von Kibana angeordnet sind.

Einzelne Inline-Diagrammvorschau.

Bereitgestellt von ES|QL

Alle Datenabrufe verwenden ES|QL, die Pipe-basierte Abfragesprache von Elasticsearch. Die KI verarbeitet nicht nur rohe Abfragen, sondern nutzt auch integrierte ES|QL-Syntax zusammen mit Informationen zur Struktur Ihrer Daten, um korrekte, effiziente Abfragen für jeden Visualisierungstyp zu schreiben.

Der Server enthält eine umfassende ES|QL-Referenz als MCP-Ressource. Bevor eine Abfrage geschrieben wird, liest die KI diese Referenz, um die verfügbaren Befehle, Funktionen und Muster zu verstehen. In Kombination mit einem Dataviz-Best-Practices-Leitfaden (der auch als Ressource diente) weiß die KI nicht nur, wie sie Abfragen gestaltet, sondern auch, was eine gute Visualisierung ausmacht:

• Verwenden Sie BUCKET(@timestamp, 1 day) für Zeitreihen; gruppieren Sie immer SORT nach dem Zeitfeld.

• Beschränken Sie Kreisdiagramme mit | SORT value DESC | LIMIT 6 auf sechs Abschnitte.

• Wählen Sie Balkendiagramme für Kategorienvergleiche, Liniendiagramme für Trends und Kennzahlen für Leistungsindikatoren (KPI).

KI-gestützte Datenexploration mit ergebnisoffener Analyse

Ein Dashboard zu erstellen, das Sie bereits in Ihrem Kopf entworfen haben, ist das eine. Die Frage lautet: „Was ist an diesem Index interessant?“ und eine brauchbare Antwort zu bekommen, ist das andere. Dafür muss die KI wissen, wie man erkundet, nicht nur, wie man zeichnet.

example-mcp-dashbuilder versendet eine analysis://guidelines-Ressource, die einen strukturierten Explorationsablauf definiert: Daten profilieren, gezielte Aggregationen ausführen, Muster aufzeigen, die es wert sind, untersucht zu werden, Diagramme für die interessantesten Ergebnisse erstellen und Drilldown-Abfragen vorschlagen, die der Nutzer als Nächstes haben könnte. Triggerphrasen wie „Analysiere meine Logs“ oder „Finde Muster in diesem Index“ veranlassen die KI, das Playbook zu lesen, bevor sie irgendetwas anderes tut. So entsteht durch einen offenen Prompt eine zusammenhängende Untersuchung und nicht ein zufälliger Haufen von Diagrammen.

Das Ergebnis: Sie können der KI einen unbekannten Index übergeben und erhalten einen Ausgangspunkt zurück: ein Dashboard sowie eine kurze Liste von Prompts, wie „Das mir aufgefallen, soll ich mir das genauer ansehen?“.

Kibana-Dashboard Export und Import: Ein vollständiger Rundgang

Der Export-/Import-Rundgang ist der Punkt, an dem example-mcp-dashbuilder für Teams, die bereits mit Kibana arbeiten, wirklich nützlich wird. example-mcp-dashbuilder ist etwas Eigenständiges, eine dialogorientierte Dashboard-Oberfläche, die in Ihren Editor integriert ist, aber Ihre Arbeit nicht dort einschließt. Hier erstellte Dashboards können bei Bedarf in Kibana übertragen werden, und bestehende Kibana-Dashboards können umgekehrt zur KI-gestützten Bearbeitung importiert werden.

Nach Kibana exportieren

Wenn Sie mit Ihrem Dashboard zufrieden sind, exportieren Sie es mit einem Befehl:

„Dieses Dashboard nach Kibana exportieren“

Jedes Panel wird als echte Kibana Lens-Visualisierung dargestellt. Die Übersetzung bewahrt:

• ES|QL-Abfragen: Direkt übertragen als Lens ES|QL-Datenquellen.

• Rasterpositionen: Das gleiche 48-Spalten-System, das Kibana verwendet, Ihr Layout sieht also identisch aus.

• Benutzerdefinierte Farben: Serienpaletten, metrische Hintergründe, Heatmap-Farbrampen.

Das Ergebnis ist ein voll funktionsfähiges Kibana-Dashboard. Kein Screenshot. Keine Einbettung. Ein echtes Dashboard, das Sie teilen und in Kibana weiter bearbeiten können.

Kibana-Dashboard und Dashboard im Cursor-Chat nebeneinander.

Aus Kibana importieren

Der Rundgang funktioniert auch in die andere Richtung:

„Importieren Sie das Kibana-Dashboard mit der ID abc-123“

Hierbei wird ein bestehendes Kibana-Dashboard abgerufen, dessen Lens-Visualisierungen in bearbeitbare Diagrammkonfigurationen übersetzt, das Rasterlayout und die Abschnitte beibehalten und alles in example-mcp-dashbuilder geladen. Von dort aus können Sie es mit natürlicher Sprache ändern und erneut exportieren.

Dadurch wird die KI zu einem Mitarbeiter in Ihrem bestehenden Kibana-Workflow, nicht zu einem Ersatz.

Benutzerdefinierte Themen und Farben

Sie wünschen sich ein Dashboard mit Ihrem Branding? Stellen Sie einfach folgende Frage:

„Erstellen Sie ein Dashboard im pinken Design mit benutzerdefinierten Farben"

Jeder Visualisierungstyp unterstützt eine benutzerdefinierte Farbkonfiguration:

• Diagramme: palette akzeptiert ein Array von Hex-Farben für Serien und Segmente.

• Metriken: color legt die Hintergrundfarbe fest.

• Heatmaps: colorRamp definiert den Verlauf von niedrigen zu hohen Werten.

Die KI erkennt Themenwünsche auf natürliche Weise. Sagen Sie „maritimes Design“ und es wählt Blau- und Türkistöne aus. Sagen Sie „Unsere Markenfarben verwenden“ und geben Sie Hexadezimalwerte an, diese werden beim Export in Kibana übernommen.

Ein thematisches Dashboard mit benutzerdefinierten Farben.

Funktionsweise von example-mcp-dashbuilder: MCP-Architektur

example-mcp-dashbuilder basiert auf MCP, dem offenen Standard zur Verbindung von KI-Assistenten mit externen Werkzeugen und Daten. Hier die Architektur im Überblick:

Der MCP-Server stellt 25 Tools bereit, die die KI direkt aufrufen kann, vom Ausführen von ES|QL-Abfragen, dem Exportieren von Dashboards sowie einige interne „App-only“-Tools, die die Inline-Vorschau nutzt, um Daten abzurufen, Layoutänderungen zu speichern und Zeitfelder zu erkennen. Er dient als Ressource für drei Bereiche: Als Leitfaden mit Best Practices für die Datenvisualisierung, als ES|QL-Referenz und als Playbook für die Tiefenanalyse, das bei offenen Prompts („Analysiere meine Logs“, „Was ist in diesem Index interessant?“) zum Einsatz kommt. Er wird entweder über stdio oder HTTP ausgeführt, der HTTP-Transport unterstützt streamfähige Antworten und Sitzungsmanagement, sodass mehrere Clients mit einem Server verbunden werden können.

Die MCP-App dient als interaktive Vorschau. Sie basiert auf React, Elastic Charts und Elastic UI, gebündelt in einer einzigen, eigenständigen HTML-Datei. Wenn die KI view_dashboard aufruft oder ein Diagramm erstellt, rendert der Host dieses HTML in einem Sandbox-iframe. Die App kommuniziert vollständig über das MCP Apps-Protokoll mit dem Server und nutzt callServerTool() über postMessage, um Daten abzurufen, Layouts zu speichern und Zeitfelder zu erkennen. Es gibt keinen lokalen Server, keinen Port zum Konfigurieren, keine externe Netzwerkabhängigkeit.

Das bedeutet, dass es mit jedem MCP-kompatiblen Client funktioniert: Cursor, Claude Desktop, Claude.ai, VS Code mit Copilot und mehr.

Welche Diagrammtypen unterstützt example-mcp-dashbuilder?

Zum Zeitpunkt der Erstellung dieses Artikels werden sechs Diagrammtypen unterstützt, die die gängigsten Dashboard-Szenarien abdecken:

Typ

Am besten für

Beispiel

Balkendiagramm

Kategorien vergleichen

Anfragen nach geografischer Quelle

Liniendiagramm

Trends im Laufe der Zeit

Pro Stunde übertragene Bytes

Bereich

Volumen im Laufe der Zeit

Volumen der Anfrage im Laufe der Zeit

Kreisdiagramm

Teil des Ganzen (maximal sechs Stücke)

Verteilung von Antwortcodes

Metrik

Einzelner KPI mit Sparkline

Gesamtzahl der Anfragen mit stündlichem Trend

Heatmap

Muster in zwei Dimensionen

Anfragen nach Wochentag und Stunde

Die Dashboards unterstützen ausklappbare Abschnitte zur besseren Übersicht, eine Zeitauswahl mit automatischer Zeitfelderkennung sowie die Möglichkeit, mehrere Dashboards zu speichern und zwischen ihnen zu wechseln. Parallele Chat-Sitzungen bleiben durch einen dashboardId-Thread, der bei jedem Tool-Aufruf durchlaufen wird, voneinander isoliert.

Installation und Ausführung von example-mcp-dashbuilder

example-mcp-dashbuilder ist Open-Source und sofort einsatzbereit. Sie benötigen Node.js 22+, eine Elasticsearch-Instanz (lokal oder Elastic Cloud) und einen MCP-kompatiblen Client.

Claude Desktop: Laden Sie die neueste .mcpb von GitHub Releases herunter und klicken Sie doppelt darauf. Claude Desktop fordert Sie zur Eingabe Ihrer Elasticsearch-Zugangsdaten auf.

Cursor / Claude Code / VS Code Copilot: Richten Sie Ihre MCP-Konfiguration auf den veröffentlichten Tarball – kein Klon, kein npm install:

Legen Sie ES_NODE, ES_API_KEY (oder ES_USERNAME / ES_PASSWORD) und KIBANA_URL als Umgebungsvariablen fest. Wenn Sie lieber von der Quelle aus arbeiten möchten, klonen Sie das Repository und führen Sie npm run setup als interaktiven Assistenten aus, der Elasticsearch lokal sowie Elastic Cloud (Cloud ID + API-Schlüssel) verwaltet.

Beginnen Sie mit der Entwicklung:

„Erkunden Sie den Log-Index und erstellen Sie mir ein möglichst aussagekräftiges Dashboard.“

Die KI übernimmt dann den Rest. 😉

Roadmap: Die Zukunft von example-mcp-dashbuilder

Dies ist eine frühe Version, die wir aktiv weiter entwickeln. Dies sind einige Bereiche, auf die wir uns konzentrieren:

• Weitere Diagrammtypen: Gauge, Donut, Treemap, Datentabelle und Tag Cloud, passend zu den vollständigen Funktionen von Lens.

• Dashboards auf Git pushen: Schreiben Sie Dashboard-Konfigurationen in ein Repository für Versionskontrolle und Code-Review-Workflows.

• Verbesserte Fehlerbehandlung: Detaillierteres Feedback, wenn ES|QL-Abfragen fehlschlagen, mit Vorschlägen für allgemeine Problemlösungen.

• Effektivere Analyseströme: Erweiterung des Deep-Analysis-Playbooks, um mehr Datenformen (Logs, Metriken, Traces) abzudecken.

Wir würden uns freuen zu erfahren, was Sie damit entwickeln. Probieren Sie es aus, melden Sie Probleme und lassen Sie uns wissen, welche Visualisierungen und Workflows für Ihr Team am nützlichsten wären.

GitHub: elastic/example-mcp-dashbuilder

Danksagungen

Vielen Dank an Walter Rafelsberger und Tim Schnell für ihren Beitrag zur Umsetzung.

FAQ

Was ist example-mcp-dashbuilder? example-mcp-dashbuilder ist eine Open-Source-MCP (Model Context Protocol) Anwendung, die KI-Assistenten mit Elasticsearch verbindet. Es ermöglicht Ihnen, ein Kibana-Dashboard in einfachem Englisch zu beschreiben und generiert automatisch ES|QL-Abfragen, erstellt Visualisierungen und liefert ein interaktives Live-Dashboard direkt im Chatfenster Ihres Editors.

Welche Abfragesprache verwendet example-mcp-dashbuilder, um Daten abzurufen? Alle Datenabrufe verwenden ES|QL, die Pipe-basierte Abfragesprache von Elasticsearch. Der MCP-Server enthält eine integrierte ES|QL-Referenz, die die KI vor dem Schreiben einer Abfrage liest, um eine korrekte Syntax und effiziente Aggregationen für jeden Visualisierungstyp zu gewährleisten.

Kann ich mit example-mcp-dashbuilder erstellte Dashboards nach Kibana exportieren? Ja. Mithilfe von „Dieses Dashboard nach Kibana exportieren“ wird jedes Panel in eine echte Kibana Lens-Visualisierung übersetzt, wobei ES|QL-Abfragen, das 48-spaltige Rasterlayout, benutzerdefinierte Farben und Serienpaletten erhalten bleiben. Das Ergebnis ist ein voll funktionsfähiges Kibana-Dashboard, kein Screenshot oder Einbettung.

Kann ich ein bestehendes Kibana-Dashboard in example-mcp-dashbuilder importieren, um eine KI-unterstützte Bearbeitung durchzuführen? Ja. Durch Angabe einer Kibana-Dashboard-ID wird das vorhandene Dashboard abgerufen, dessen Lens-Visualisierungen in bearbeitbare Diagrammkonfigurationen übersetzt und in example-mcp-dashbuilder geladen. Anschließend können Sie das Dashboard mithilfe natürlicher Sprache modifizieren und wieder nach Kibana exportieren.

Welche MCP-Clients sind mit example-mcp-dashbuilder kompatibel? example-mcp-dashbuilder funktioniert mit jedem MCP-kompatiblen Client, einschließlich Cursor, Claude Desktop, Claude.ai und VS Code mit Copilot. Es unterstützt sowohl stdio- als auch HTTP-Transport, ohne dass eine lokale Server- oder Portkonfiguration erforderlich ist.

Welche Diagrammtypen werden von example-mcp-dashbuilder unterstützt? Die aktuelle Version unterstützt sechs Diagrammtypen: Balkendiagramm, Liniendiagramm, Flächendiagramm, Kreisdiagramm, Metrik (mit Sparkline) und Heatmap. Geplante Ergänzungen umfassen Gauge, Donut, Treemap, Datentabelle und Tag Cloud, um den vollen Funktionsumfang von Kibana Lens zu erreichen.

Was benötige ich, um example-mcp-dashbuilder auszuführen? Sie benötigen Node.js 22 oder höher, eine Elasticsearch-Instanz (lokal oder Elastic Cloud) und einen MCP-kompatiblen Client. Legen Sie die Umgebungsvariablen ES_NODE, ES_API_KEY (oder ES_USERNAME/ES_PASSWORD) und KIBANA_URL fest. Für Claude Desktop laden Sie die .mcpb- Datei von GitHub Releases herunter und installieren sie per Doppelklick.

Was sind Steuerelemente für Variablen?

Wenn Sie bereits mit Kibana-Dashboards gearbeitet haben, kennen Sie wahrscheinlich unsere klassischen Dashboard-Steuerelemente – diese praktischen Dropdown-Menüs, die Werte aus Ihren Daten anzeigen, sodass Sie mit wenigen Klicks Filter setzen können.

Variable Bedienelemente sehen auf der Oberfläche ähnlich aus, haben aber eine clevere Wendung: Anstatt automatisch jedes Panel auf deinem Dashboard zu filtern, können sie direkt an ES|QL-Abfragen innerhalb einzelner Visualisierungen angeschlossen werden.

Das bedeutet, Sie können entscheiden, wo jedes Steuerelement angewendet wird. Noch besser: Sie können sie für alle möglichen kreativen Tricks verwenden – beispielsweise zum Anpassen von Zeitintervallen, zum Wechseln von Aufschlüsselungsfeldern oder zum spontanen Ändern von Visualisierungsparametern. Im Grunde genommen sorgen sie für ein wahrhaft interaktives Erlebnis auf Ihren Dashboards, sodass Sie schneller und einfacher zu Ihren Erkenntnissen gelangen.

Anwendungsfälle für Steuerelemente für Variablen

Steuerelemente für Variablen sind zwar nützlich, aber was kann man damit eigentlich machen? Hier sind einige Beispiele dafür, wie sie Ihre Dashboards verbessern:

Ausgewählte Visualisierungen filtern

Möchten Sie einige Visualisierungen filtern, aber andere unberührt lassen? Steuerelemente für Variablen ermöglichen Ihnen genau das. Wählen Sie die Panels aus, auf die Sie reagieren möchten, und verknüpfen Sie sie in den ES|QL-Abfragen hinter Ihren Visualisierungen.

Wählen Sie unterschiedliche Zeitintervalle aus

Geben Sie Ihren Nutzern die Möglichkeit, zwischen „5 Minuten“, „1 Stunde“, „1 Tag“ oder anderen sinnvollen Buckets zu wechseln. Erstellen Sie ein Steuerelement für Variablen mit vordefinierten Intervallen und verbinden Sie diese mit Ihrer Zeitreihenabfrage.

Funktionen ändern

Anstatt mehrere Diagramme für jeden Vorgang zu erstellen, können die Nutzer des Dashboards wählen, ob sie den Maximalwert, den Durchschnittswert, verschiedene Perzentile oder einen anderen Aggregator sehen möchten.

Nach verschiedenen Feldern gruppieren

Mitunter müssen Sie die Daten während einer Untersuchung nach verschiedenen Dimensionen aufschlüsseln. Mit Steuerelementen für Variablen können Sie mehrere „Gruppieren nach“-Felder festlegen und Dashboard-Nutzer so das Feld auswählen lassen, das sie bei der Gewinnung ihrer Erkenntnisse unterstützt.

Wie kann man sie erstellen?

Die einfachste (und wahrscheinlich angenehmste) Methode zur Erstellung eines Steuerelements für Variablen ist direkt über den ES|QL-Abfrage-Editor in Ihrer Visualisierung. Beginnen Sie einfach mit der Eingabe Ihrer Suchanfrage, nutzen Sie das Autovervollständigungsmenü und Kibana unterstützt Sie bei der Erstellung Ihres Steuerelements.

Wenn Sie jedoch lieber mit der Variablen selbst beginnen möchten, können Sie auch zu Panel hinzufügen → Steuerelemente → Steuerelement für Variablen gehen und die Variable nach dem Erstellen des Steuerelements zu Ihren Visualisierungen hinzufügen.

Beispiel 1: Filter-Steuerelement mit Auswahl mehrerer Werte

1. Wählen Sie eine Visualisierung aus, die auf einer ES|QL-Abfrage basiert, und klicken Sie innerhalb der WHERE-Klausel auf „Steuerelement erstellen“

2. Sie werden automatisch zum Flyout für die Erstellung von Variablen weitergeleitet, wo der Typ „Werte aus einer Abfrage“ für Sie ausgewählt ist und der Name der Variablen bereits vorausgefüllt ist. Beachten Sie, dass der Name eines Steuerelements immer mit „?...” beginnen muss, damit er in der Visualisierungsabfrage funktioniert.

In der Regel benötigen Sie eine Abfrage wie diese, um die Werte eines Feldes abzurufen und sie entsprechend dem im Dashboard ausgewählten Zeitraum zu aktualisieren:

3. Beim Speichern des Steuerelements erscheint sie oben im Dashboard, und Ihre Visualisierungsabfrage wird mit dem Namen des Steuerelements für Variablen aktualisiert.

4. Wenn Sie Mehrfachauswahl zum Steuerelement hinzufügen möchten, verwenden Sie die Funktion MV_CONTAINS in der Abfrage und wählen Sie bei der Erstellung des Steuerelements in Schritt 2 (verfügbar ab 9.3) die Option „Mehrfachauswahl zulassen“ aus.

Beispiel 2: Zeitintervallsteuerung

Bei der Erstellung einer Zeitreihe können Sie ganz einfach ein Steuerelement für Variablen für Ihr Datums-Histogramm-Intervall hinzufügen:

1. Klicken Sie beim Schreiben einer ES|QL-Abfrage für Ihre Zeitreihe auf „Steuerelement erstellen“. Bei der Erstellung einer Variablen für Intervalle ist es besser, TBUCKET anstelle von BUCKET zu verwenden, damit besser lesbare Intervalle wie „1 Stunde“, „1 Tag“ usw. akzeptiert werden. In Kürze steht auch eine automatische Option für TBUCKET zur Verfügung, sodass sich das System automatisch an Zeitbereiche anpassen kann.

2. Legen Sie die Intervalle zum Ausfüllen der Optionen im Dropdown-Menü fest.

3. Wählen Sie im Dropdown-Menü verschiedene Intervalle aus und sehen Sie, wie sich Ihre Visualisierung verändert.

Beispiel 3: Variablen für Funktionen

1. Erstellen Sie eine Variable mithilfe des Kontrolltyps „Statische Werte“ und fügen Sie Funktionsnamen zu Ihren Dropdown-Werten hinzu. Es ist wichtig, für Ihre Variable einen Namen zu verwenden, der mit „??…“ beginnt, um Funktionen zu ersetzen.

2. Fügen Sie den Variablennamen in Ihre ES|QL-Abfrage ein.

Beispiel 4: Variablen für Felder

1. Sie können den Kontrolltyp „Statische Werte“ verwenden und die Namen der gewünschten Felder eingeben. Es ist wichtig, einen Variablennamen zu verwenden, der mit „??...“ beginnt, damit er für Felder funktioniert.

2. Verweisen Sie in der Visualisierungsabfrage auf die gewünschte Variable.

Steuerelemente für Variablen in Discover

Steuerelemente für Variablen sind nicht nur eine Dashboard-Funktion, sondern auch direkt im ES|QL-Editor in Discover verfügbar. Sie können Steuerelemente für eine schnellere Datenexploration in Discover erstellen, diese in das Dashboard übertragen und umgekehrt.

Technische Details

Mittlerweile haben Sie wahrscheinlich bemerkt, dass Steuerelemente für Variablen einigen Regeln unterliegen – beispielsweise, auf welche Teile einer Abfrage sie verweisen können und welche Namenspräfixe Sie verwenden müssen („?...” für Werte und „??...” für Felder oder Funktionen). Das liegt daran, dass Variablen nicht nur einfache Zeichenfolgenersetzungen sind, die auf dem Client stattfinden. Es handelt sich dabei um erstklassige Elemente der Abfragesprache selbst (bekannt als Parameter in ES|QL).

Dieses Design bietet einige große Vorteile. Zum einen kann Kibana den Kontext jeder Variablen verstehen, wodurch wir die Konfiguration automatisch für Sie generieren und vorausfüllen können. Außerdem ist es viel sicherer: Da die Sprache Variableneingaben streng validiert, verhindert sie böswillige Injektionen und gibt bei Unstimmigkeiten eine Fehlermeldung aus. Darüber hinaus werden Leistung und Stabilität verbessert, indem komplexe Validierungen und Fehlerbehandlungen vom Client auf den Server verlagert werden. Ein Hinweis zur Leistung: Eine bewährte Vorgehensweise besteht in der Erstellung von Variablen, die schnelle Abfragen enthalten, da diese vor dem Dashboard geladen werden. Langsame Abfragen können sich daher auf die gesamte Dashboard-Leistung auswirken.

Natürlich bringt diese Architektur vorerst auch einige Einschränkungen mit sich. Variablen unterstützen noch keine „Alle“-Option für das Filtern und können derzeit nicht mit bestimmten Operatoren wie LIKEoder FROM (zum Wechseln der Datenquellen) verwendet werden. Die gute Nachricht? Wir arbeiten aktiv an der Erweiterung um diese Funktionen.

Was die Zukunft für Bedienelemente bereithält

Wir machen hier noch lange nicht Schluss! Zu den geplanten Verbesserungen gehören unter anderem:

✨ Die Möglichkeit zur beliebigen Platzierung von Steuerelementen auf dem Dashboard

✨ Verkettung Ihrer Steuerelemente – das bedeutet, der Ausgang eines Steuerelements wird zum Eingang für das nächste Steuerelement

✨ Verbesserte Auswahlmöglichkeiten wie die Option „Alle“ für Variablen

✨ Neue Kontrolltypen (Suchtyp-Steuerelement und Variablen für Ihre Datenquellen)

✨ Und weitere Verbesserungen der von Ihnen Benutzerfreundlichkeit, wie beispielsweise die Vorfilterung normaler Steuerelemente

Wir freuen uns über Ihre Ideen und Ihr Feedback.

In diesem Artikel werden wir genau das tun. Wir werden eine Anwendung erstellen, die ein Bild eines Dashboards aufnimmt, unsere Mappings analysiert und anschließend ein Dashboard generiert, ohne dass wir Kibana überhaupt berühren müssen!

Schritte:

1. Hintergrund und Anwendungsablauf

2. Daten vorbereiten

3. LLM-Konfiguration

4. Anwendungsfunktionen

Hintergrund und Anwendungsablauf

Mein erster Gedanke war, den LLM das gesamte NDJSON-Format der in Kibana gespeicherten Objekte generieren zu lassen und sie dann in Kibana zu importieren.

Wir haben eine Handvoll Modelle ausprobiert:

• Gemini 2.5 Pro

• GPT o3 / o4-mini-hoch / 4.1

• Claude 4 Sonett

• Grok 3

• Deepseek (Deepthink R1)

Und als Anregungen begannen wir mit ganz einfachen Dingen:

Trotz der Durchsicht einiger weniger Beispiele und detaillierter Erklärungen zum Aufbau der einzelnen Visualisierungen hatten wir keinen Erfolg. Wenn Sie an diesem Experiment interessiert sind, finden Sie hier weitere Informationen.

Das Ergebnis dieser Vorgehensweise war, dass beim Versuch, die vom LLM erzeugten Dateien in Kibana hochzuladen, diese Meldungen angezeigt wurden:

Das bedeutet, dass das generierte JSON ungültig oder schlecht formatiert ist. Die häufigsten Probleme waren, dass der LLM unvollständiges NDJSON erzeugte, Parameter falsch interpretierte oder normales JSON anstelle von NDJSON zurückgab, egal wie sehr wir uns bemühten, das Gegenteil zu erzwingen.

Inspiriert von diesem Artikel – in dem Suchvorlagen besser funktionierten als LLM Freestyle – entschieden wir uns, dem LLM Vorlagen zu übergeben, anstatt die vollständige NDJSON-Datei generieren zu lassen und anschließend im Code die vom LLM bereitgestellten Parameter zur Erstellung der Visualisierungen zu verwenden. Dieser Ansatz hat sich bewährt und ist vorhersehbar und erweiterbar, da nun der Code und nicht mehr das LLM die Hauptarbeit übernimmt.

Der Bewerbungsprozess wird wie folgt ablaufen:

Der Einfachheit halber lassen wir einige Codeabschnitte weg, aber den vollständigen, lauffähigen Code der Anwendung finden Sie in diesem Notebook.

Voraussetzungen

Bevor Sie mit der Entwicklung beginnen, benötigen Sie Folgendes:

1. Python 3.8 oder höher

2. Eine Venv Python-Umgebung

3. Eine laufende Elasticsearch-Instanz, zusammen mit ihrem Endpunkt und API-Schlüssel

4. Ein OpenAI-API-Schlüssel, der unter dem Umgebungsvariablennamen OPENAI_API_KEY gespeichert ist:

Daten vorbereiten

Für die Daten halten wir es einfach und verwenden Elastic-Beispiel-Weblogs. Hier erfahren Sie, wie Sie diese Daten in Ihren Cluster importieren.

Jedes Dokument enthält Angaben zum Host, der die Anfragen an die Anwendung gestellt hat, sowie Informationen zur Anfrage selbst und deren Antwortstatus. Nachfolgend finden Sie ein Beispieldokument:

Nun holen wir uns die Zuordnungen des soeben geladenen Index, kibana_sample_data_logs:

Wir werden die Zuordnungen zusammen mit dem Bild übergeben, das wir später laden werden.

LLM-Konfiguration

Konfigurieren wir das LLM so, dass es strukturierte Ausgabe verwendet, um ein Bild einzugeben und ein JSON mit den Informationen zu erhalten, die wir an unsere Funktion übergeben müssen, um die JSON-Objekte zu erzeugen.

Wir installieren die Abhängigkeiten:

Elasticsearch wird uns dabei helfen, die Indexzuordnungen abzurufen. Pydantic ermöglicht es uns, Schemata in Python zu definieren, denen der LLM dann folgen soll, und LangChain ist das Framework, das den Aufruf von LLMs und KI-Tools vereinfacht.

Wir werden ein Pydantic-Schema erstellen, um die gewünschte Ausgabe des LLM zu definieren. Aus dem Bild müssen wir den Diagrammtyp, das Feld, den Visualisierungstitel und den Dashboard-Titel ablesen:

Als Bildeingabe senden wir ein Dashboard, das ich gerade gezeichnet habe:

Nun deklarieren wir den LLM-Modellaufruf und das Laden des Bildes. Diese Funktion erhält die Zuordnungen des Elasticsearch-Index und ein Bild des Dashboards, das wir generieren möchten.

Mit with_structured_output können wir unser Pydantic Dashboard Schema als Antwortobjekt verwenden, das der LLM erzeugen wird. Mit Pydantic können wir Datenmodelle mit Validierung definieren, wodurch sichergestellt wird, dass die LLM-Ausgabe der erwarteten Struktur entspricht.

Um das Bild in Base64 zu konvertieren und als Eingabe zu senden, können Sie einen Online-Konverter verwenden oder dies im Code erledigen.

Der LLM verfügt bereits über Kontextinformationen zu Kibana-Dashboards, daher müssen wir nicht alles in der Eingabeaufforderung erklären, sondern nur einige Details, um sicherzustellen, dass er nicht vergisst, dass er mit Elasticsearch und Kibana arbeitet.

Lassen Sie uns die Aufgabenstellung aufschlüsseln:

Abschnitt

Grund

Sie sind Experte in der Analyse von Kibana-Dashboards anhand von Images für die Version 9.0.0 von Kibana.

Durch die Verstärkung dieser Funktion wird Elasticsearch und die Verwendung der Elasticsearch-Version unterstützt, wodurch die Wahrscheinlichkeit verringert wird, dass das LLM alte/ungültige Parameter fälschlicherweise annimmt.

Sie erhalten ein Dashboard-Bild und eine Elasticsearch-Indexzuordnung.

Wir erklären, dass es sich bei dem Bild um Dashboards handelt, um Fehlinterpretationen seitens des LLM zu vermeiden.

Nachfolgend finden Sie die Indexzuordnungen für den Index, auf dem das Dashboard basiert. Nutzen Sie diese, um die Daten und die verfügbaren Felder besser zu verstehen. Indexzuordnungen: {index_mappings}

Es ist entscheidend, die Zuordnungen bereitzustellen, damit das LLM dynamisch gültige Felder auswählen kann. Andernfalls könnten wir die Zuordnungen hier fest codieren, was zu starr wäre, oder uns darauf verlassen, dass das Bild die richtigen Feldnamen enthält, was nicht zuverlässig ist.

Beschränken Sie sich auf die Felder, die für die jeweilige Visualisierung relevant sind, basierend auf dem, was im Bild sichtbar ist.

Wir mussten diese Verstärkung hinzufügen, weil manchmal versucht wird, Felder hinzuzufügen, die nicht zum Bild gehören.

Dies gibt ein Objekt mit einem Array von anzuzeigenden Visualisierungen zurück:

Verarbeitung der LLM-Antwort

WirWir haben ein Beispiel-Dashboard mit 2x2-Panels erstellt und es dann mithilfe der Get a dashboard API im JSON-Format exportiert. Anschließend haben wir die Panels als Visualisierungsvorlagen (Kreisdiagramm, Balkendiagramm, Metrikdiagramm) gespeichert, in denen wir einige der Parameter ersetzen können, um je nach Fragestellung neue Visualisierungen mit anderen Feldern zu erstellen.

Die JSON-Vorlagedateien können Sie hier einsehen. Beachten Sie, wie wir die Objektwerte, die wir später ersetzen möchten, durch {variable_name}ersetzt haben.

Anhand der von LLM bereitgestellten Informationen können wir entscheiden, welche Vorlage wir verwenden und welche Werte wir ersetzen.

fill_template_with_analysis empfängt die Parameter für ein einzelnes Panel, einschließlich der JSON-Vorlage der Visualisierung, eines Titels, eines Feldes und der Koordinaten der Visualisierung im Raster.

Anschließend werden die Werte der Vorlage ersetzt und die endgültige JSON-Visualisierung zurückgegeben.

Um es einfach zu halten, verwenden wir statische Koordinaten, die wir den vom LLM erstellten Panels zuweisen, und erzeugen so ein 2x2-Raster-Dashboard wie in der obigen Abbildung dargestellt.

Je nach dem vom LLM festgelegten Visualisierungstyp wählen wir eine JSON-Dateivorlage aus und ersetzen die relevanten Informationen durch fill_template_with_analysis . Anschließend fügen wir das neue Panel einem Array hinzu, das wir später zum Erstellen des Dashboards verwenden.

Sobald das Dashboard fertig ist, verwenden wir die „Create a dashboard“-API , um die neue JSON-Datei an Kibana zu übertragen und das Dashboard zu generieren:

Um das Skript auszuführen und das Dashboard zu generieren, führen Sie folgenden Befehl in der Konsole aus:

Das Endergebnis wird folgendermaßen aussehen:

Fazit

LLMs zeigen ihre ausgeprägten visuellen Fähigkeiten bei der Umwandlung von Text in Code oder der Umwandlung von Bildern in Code. Die Dashboards-API ermöglicht es auch, JSON-Dateien in Dashboards umzuwandeln, und mit einem LLM und etwas Code können wir Bilder in ein Kibana-Dashboard umwandeln.

Der nächste Schritt besteht darin, die Flexibilität der Dashboard-Visualisierungen durch die Verwendung unterschiedlicher Rastereinstellungen, Dashboard-Größen und -Positionen zu verbessern. Darüber hinaus wäre die Unterstützung komplexerer Visualisierungen und Visualisierungstypen eine sinnvolle Ergänzung dieser Anwendung.

Unterschiede zur ersten Spotify Wrapped-Analyse

Im ersten Blogbeitrag haben wir den Spotify-Export direkt verwendet und keine Normalisierungsaufgaben oder sonstige Datenverarbeitungsschritte durchgeführt. Dieses Mal verwenden wir dieselben Daten, werden sie aber aufbereiten, um sie besser nutzbar zu machen. Dies wird es uns ermöglichen, wesentlich komplexere Fragen zu beantworten, wie zum Beispiel:

• Wie lang ist ein Song in meinen Top 100 im Durchschnitt?

• Wie hoch ist die durchschnittliche Beliebtheit eines Songs in meinen Top 100?

• Wie lange wird ein Lied im Durchschnitt angehört?

• Welcher Song wird bei mir am häufigsten übersprungen?

• Wann überspringe ich gerne Musiktitel?

• Höre ich zu einer bestimmten Tageszeit mehr Musik als zu anderen?

• Höre ich an einem bestimmten Wochentag mehr Musik als an anderen?

• Ist es ein Monat von besonderem Interesse?

• Welcher Künstler hat die längste Hörerschaftszeit?

Spotify Wrapped ist jedes Jahr ein tolles Erlebnis, das dir zeigt, was du dieses Jahr gehört hast. Es werden keine Veränderungen im Jahresvergleich angezeigt, sodass Ihnen möglicherweise einige Künstler entgehen, die einst zu Ihren Top 10 gehörten, aber nun verschwunden sind.

Verarbeitung von Spotify Wrapped-Daten zur Analyse

Es gibt einen großen Unterschied in der Art und Weise, wie wir die Daten im ersten und im zweiten Beitrag verarbeiten. Wenn Sie weiterhin mit den Daten aus dem ersten Beitrag arbeiten möchten, müssen Sie einige Änderungen der Feldnamen berücksichtigen und auf ES|QL zurückgreifen, um bestimmte Extraktionen wie hour of day dynamisch durchzuführen.

Dennoch solltet ihr alle in der Lage sein, diesem Beitrag zu folgen. Die Datenverarbeitung im Spotify-zu-Elasticsearch- Repository beinhaltet das Abfragen der Spotify-API nach der Dauer des Songs, der Popularität sowie das Umbenennen und Erweitern einiger Felder. Das Feld artist im Spotify-Export ist beispielsweise lediglich ein String und repräsentiert weder Features noch Tracks mit mehreren Künstlern.

Visualisierung von Spotify Wrapped-Daten mit Dashboards

Ich habe in Kibana ein Dashboard erstellt, um die Daten zu visualisieren. Das Dashboard ist hier verfügbar und kann in Ihre Kibana-Instanz importiert werden. Das Dashboard ist sehr umfangreich und beantwortet viele der oben genannten Fragen.

Lasst uns einige der Fragen betrachten und gemeinsam überlegen, wie wir sie beantworten können!

Wie lang ist ein Song in meinen Top 100 im Durchschnitt?

Um diese Frage zu beantworten, können wir Lens oder ES|QL verwenden. Lasst uns alle drei Optionen genauer betrachten. Formulieren wir diese Frage einmal korrekt im Elasticsearch-Stil. Wir möchten die 100 beliebtesten Lieder finden und dann die durchschnittliche Dauer aller dieser Lieder zusammen berechnen. In Elasticsearch-Begriffen wären das zwei Aggregationen:

1. Finde die Top 100 Songs heraus

2. Berechne die durchschnittliche Dauer dieser 100 Lieder.

Lens

In Lens ist das ganz einfach: Man erstellt eine neue Lens, wechselt zu einer Tabelle und zieht das Feld title per Drag & Drop in die Tabelle. Klicken Sie anschließend auf das Feld title und stellen Sie die Größe auf 100 ein. Stellen Sie außerdem den Modus accuracy ein. Ziehen Sie dann das Feld duration per Drag & Drop in die Tabelle und verwenden Sie last value, da wir eigentlich nur den letzten Wert der Dauer jedes Liedes benötigen. Dasselbe Lied hat nur eine einzige Dauer. Am Ende dieser last value -Aggregation befindet sich ein Dropdown-Menü für eine Zusammenfassungszeile. Wählen Sie average aus, um sie anzuzeigen.

ES|QL

ES|QL ist im Vergleich zu DSL und Aggregationen eine recht neue Sprache, aber sie ist sehr leistungsstark und einfach zu bedienen. Um dieselbe Frage in ES|QL zu beantworten, würden Sie die folgende Abfrage schreiben:

Ich führe Sie Schritt für Schritt durch diese ES|QL-Abfrage:

1. from spotify-history - Dies ist das Indexmuster, das wir verwenden.

2. stats duration=max(duration), count=count() by title - Dies ist die erste Aggregation; wir berechnen die maximale Dauer jedes Liedes und die Anzahl der Lieder. Wir verwenden max anstelle von last value , wie es in der Lens verwendet wird, da ES|QL derzeit kein erstes oder letztes Element hat.

3. sort count desc - Wir sortieren die Lieder nach der Anzahl der Aufrufe jedes Liedes, sodass das meistgehörte Lied ganz oben steht.

4. limit 100 - Wir beschränken das Ergebnis auf die Top 100 Songs.

5. stats Average duration of the songs=avg(duration) - Wir berechnen die durchschnittliche Dauer der Lieder.

Ist ein bestimmter Monat für mich von besonderem Interesse?

Um diese Frage zu beantworten, können wir Lens mithilfe von Laufzeitfeldern und ES|QL verwenden. Was uns sofort auffällt: Es gibt kein Feld in den Daten, das die month direkt angibt; stattdessen müssen wir sie aus dem Feld @timestamp berechnen. Dafür gibt es mehrere Möglichkeiten:

1. Verwenden Sie ein Laufzeitfeld, um die Linse mit Strom zu versorgen.

2. ES|QL

Ich persönlich halte ES|QL für die elegantere und schnellere Lösung.

Das ist alles, nichts Kompliziertes ist nötig. Wir können die DATE_EXTRACT -Funktion nutzen, um den Monat aus dem @timestamp -Feld zu extrahieren und können dann darüber aggregieren. Mithilfe der ES|QL-Visualisierung können wir das auf dem Dashboard einbinden.

Wie lange höre ich im Durchschnitt pro Künstler und Jahr?

Die Idee dahinter ist, herauszufinden, ob ein Künstler nur eine einmalige Erscheinung ist oder ob es zu einer Wiederholung kommt. Wenn ich mich richtig erinnere, zeigt Spotify nur die Top 5 Künstler im Jahresrückblick an. Vielleicht bleibt dein Künstler auf Platz 6 immer derselbe, oder er wechselt ab Platz 10 stark?

Eine der einfachsten Darstellungsformen hierfür ist ein prozentuales Balkendiagramm. Wir können dafür Lens verwenden. Folgen Sie den folgenden Schritten:

Ziehen Sie das Feld listened_to_ms per Drag & Drop an die gewünschte Stelle. Dieses Feld gibt an, wie lange Sie ein Lied in Millisekunden angehört haben. Standardmäßig erstellt Lens eine median -Aggregation. Das wollen wir nicht, ändern wir das in eine sum. Wählen Sie oben für den Balkendiagrammtyp percentage anstelle von stacked aus. Für die Aufschlüsselung wählen Sie artist und geben Sie „Top 10“ ein. Vergessen Sie nicht, im Dropdown-Menü Advanced die accuracy mode auszuwählen. Jeder Farbblock repräsentiert nun, wie oft Sie diesen einzelnen Künstler gehört haben. Je nach gewähltem Zeitauswahlfeld können die Balken Werte von Tagen über Wochen und Monate bis hin zu Jahren darstellen. Wenn Sie eine wöchentliche Aufschlüsselung wünschen, wählen Sie @timestamp aus und stellen Sie mininum interval auf year ein. Was wir in meinem Fall nun sagen können, ist, dass Fred Again.. der Künstler ist, den ich am häufigsten gehört habe; fast 12 % meiner gesamten Hörzeit entfielen auf Fred Again... Wir sehen auch, dass Fred Again.. im Jahr 2024 etwas zurückging, Jamie XX aber stark zunahm. Wenn wir nur die Größe der Balken vergleichen. Wir können auch feststellen, dass während Billie Eilish im Jahr 2024 ständig gespielt wird, der Balken sich verbreitert. Das bedeutet, dass ich Billie Eilish im Jahr 2024 häufiger gehört habe als im Jahr 2023.

Wie sieht es mit den Top-Titeln pro Künstler pro Hörzeit im Vergleich zur gesamten Hörzeit aus?

Das ist eine ganz schön komplizierte Frage. Ich möchte versuchen, das zu erklären, was ich damit sagen möchte. Spotify informiert dich über den Top-Song eines einzelnen Künstlers oder über deine insgesamt 5 Top-Songs. Das ist auf jeden Fall interessant, aber wie sieht es mit dem Zusammenbruch eines Künstlers aus? Verbringe ich meine gesamte Zeit nur mit einem einzigen Lied, das ich immer und immer wieder höre, oder ist meine Zeit gleichmäßig verteilt?

Erstellen Sie eine neue Linse und wählen Sie Treemap als Typ aus. Für metric gilt dasselbe wie zuvor: Wählen Sie sum aus und verwenden Sie listened_to_ms als Feld. Für die group by benötigen wir zwei Werte. Das erste ist artist und dann füge ein zweites mit title hinzu. Das Zwischenergebnis sieht folgendermaßen aus:

Ändern wir das in Top 100 Künstler und deaktivieren wir die other im erweiterten Dropdown-Menü sowie aktivieren wir den Genauigkeitsmodus. Ändern Sie den Titel in „Top 10“ und aktivieren Sie den Genauigkeitsmodus. Das Endergebnis sieht folgendermaßen aus:

Was genau sagt uns das nun? Ohne die Zeitkomponente zu berücksichtigen, können wir sagen, dass ich in meiner gesamten Hörhistorie bei Spotify 5,67 % mit dem Hören von Fred Again.. verbracht habe. Insbesondere habe ich 1,21 % dieser Zeit mit dem Hören von Delilah (pull me out of this) verbracht. Es ist interessant zu sehen, ob es ein einzelnes Lied gibt, das einen Künstler beschäftigt, oder ob es auch andere Lieder gibt. Die Baumkarte selbst ist eine gute Darstellungsform für solche Datenverteilungen.

Höre ich zu einer bestimmten Uhrzeit und an einem bestimmten Tag?

Nun, das können wir ganz einfach mit einer Lens-Visualisierung beantworten, die die Heat Map nutzt. Erstellen Sie eine neue Linse, wählen Sie Heat Map aus. Wählen Sie für Horizontal Axis das Feld dayOfWeek aus und stellen Sie es auf Top 7 anstatt auf Top 3 ein. Für Vertical Axis wähle hourOfDay und für Cell Value einfach Count of records. Dadurch wird folgendes Panel erzeugt:

Es gibt ein paar ärgerliche Dinge an diesem Objektiv, die mich beim Interpretieren einfach stören. Lasst uns versuchen, es ein wenig aufzuräumen. Zunächst einmal ist mir die Legende nicht so wichtig, verwenden Sie das Symbol oben mit dem Dreieck, Quadrat und Kreis und deaktivieren Sie sie.

Der zweite ärgerliche Punkt ist nun die Sortierung der Tage. Es ist Montag, Mittwoch, Donnerstag oder irgendein anderer Tag, je nachdem, welche Werte Sie haben. Die hourOfDay ist korrekt sortiert. Die Art und Weise, wie die Tage sortiert werden, ist ein witziger Trick, nämlich die Verwendung von Filters anstelle von Top Values. Klicken Sie auf dayOfWeek und wählen Sie Filters aus. Es sollte nun so aussehen:

Jetzt fangen Sie einfach an, die Tage einzugeben. Ein Filter pro Tag. "dayOfWeek" : Monday und gib ihm die Bezeichnung Monday und wiederhole den Vorgang.

Allerdings gibt es dabei einen Haken: Spotify stellt die Daten in UTC+0 ohne Zeitzoneninformationen bereit. Natürlich liefern sie auch die IP-Adresse und das Land, in dem Sie zugehört haben, und wir könnten daraus die Zeitzoneninformationen ableiten, aber das kann ungenau sein, und für Länder wie die USA, die mehrere Zeitzonen haben, kann es zu umständlich sein. Dies ist wichtig, da Elasticsearch und Kibana Zeitzonen unterstützen. Durch die Angabe der korrekten Zeitzone im Feld @timestamp passt Kibana die Zeit automatisch an die Zeit Ihres Browsers an.

So sollte es nach der Fertigstellung aussehen, und man kann erkennen, dass ich während der Arbeitszeit sehr aktiv zuhöre, samstags und sonntags hingegen weniger.

Fazit

In diesem Blogbeitrag sind wir etwas tiefer in die Feinheiten der Spotify-Daten eingetaucht. Wir haben einige einfache und schnelle Wege aufgezeigt, wie man Visualisierungen erstellen und ausführen kann. Es ist einfach fantastisch, so viel Kontrolle über den eigenen Hörverlauf zu haben. Schaut euch auch die anderen Teile der Serie an:

• Teil 1: So erstellen Sie Ihr eigenes Spotify Wrapped in Kibana

• Teil 3: Populationsjobs zur Anomalieerkennung

• Teil 4: Beziehungen in Daten erkennen

• Teil 5: Finde deinen besten Musikfreund mit Vektoren

Hier ist ein Diagramm, das zeigt, was wir in diesem Tutorial konfigurieren werden:

Einrichten der lokalen Inferenz mit Ollama

Ollama ist eine hervorragende Möglichkeit, schnell eine kuratierte Auswahl an Open-Source-Modellen für lokale Inferenztests auszuprobieren, und ein beliebtes Werkzeug für KI-Entwickler.

Ausführen von Ollama bare metal

Eine lokale Installation auf Mac, Linux oder Windows ist der einfachste Weg, um lokale GPU-Funktionen zu nutzen, insbesondere für Nutzer mit Apple-Chips der M-Serie. Sobald Sie Ollama installiert haben, können Sie DeepSeek R1 mit dem folgenden Befehl herunterladen und ausführen.

Vielleicht möchten Sie die Parametergröße an Ihre Hardware anpassen. Verfügbare Größen finden Sie hier.

Sie können im Terminal mit dem Modell chatten, aber das Modell läuft auch dann weiter, wenn Sie den Befehl mit Strg+d verlassen oder „/bye“ eingeben. Um zu sehen, ob das Modell noch läuft, geben Sie Folgendes ein:

Ollama in einem Container ausführen

Der schnellste alternative Weg zum Ausführen von Ollama ist die Nutzung einer Container-Engine wie Docker. Die Nutzung der GPU Ihres lokalen Rechners ist je nach Umgebung nicht immer einfach, aber eine schnelle Testeinrichtung ist nicht schwer, solange Ihr Container über genügend RAM und Speicherplatz für die Multi-GB-Modelle verfügt.

Das Einrichten und Ausführen von Ollama in Docker ist so einfach wie der Befehl:

Dies erstellt ein Verzeichnis namens „Ollama“ im aktuellen Verzeichnis und verankert es im Container, um die Ollama-Konfiguration sowie die Modelle zu speichern. Je nach Anzahl der verwendeten Parameter können diese eine Größe von einigen GB bis zu Dutzenden von GB haben, daher sollten Sie ein Laufwerk mit ausreichend freiem Speicherplatz wählen.

Hinweis: Wenn Sie eine Nvidia-GPU in Ihrem Computer haben, installieren Sie unbedingt das Nvidia Container-Toolkit und fügen Sie dem obigen Befehl zum Ausführen von Docker „--gpus=all“ hinzu.

Sobald der Ollama-Container auf Ihrem Rechner läuft, können Sie ein Modell wie DeepSeek R1 mit folgendem Befehl abrufen:

Ähnlich wie beim Bare-Metal-Ansatz möchten Sie möglicherweise die Parametergröße ändern, um sie an Ihre Hardware anzupassen. Verfügbare Größen finden Sie unter https://ollama.com/library/deepseek-r1.

Sobald das Herunterladen des Modells abgeschlossen ist, können Sie „/bye“ eingeben, um die Eingabeaufforderung zu beenden. So überprüfen Sie, ob das Modell noch ausgeführt wird:

Testen unserer lokalen Inferenz mit einem Curl

Um die lokale Inferenz mit cURL zu testen, können Sie den folgenden Befehl ausführen. Wir verwenden stream:false, damit wir die narrative JSON-Reaktion leicht lesen können:

Testen von „OpenAI-kompatiblem“ Ollama und einer RAG-Eingabeaufforderung

Praktischerweise bietet Ollama auch einen REST-Endpoint, der das Verhalten von OpenAI nachahmt, um die Kompatibilität mit einer Vielzahl von Tools, einschließlich Kibana, zu gewährleisten.

Das Testen dieser komplexeren Eingabeaufforderung führt zu Inhalten, die einen <think>-Abschnitt enthalten, in dem das Modell darauf trainiert wurde, das Problem zu durchdenken.

Ollama mit Kibana verbinden

Eine großartige Möglichkeit, Elasticsearch zu nutzen, ist das „start-local“-Entwicklungsskript.

Stellen Sie sicher, dass Kibana und Elasticsearch Ihr Ollama im Netzwerk erreichen können. Wenn Sie ein lokales Container-Setup des Elastic Stack verwenden, bedeutet dies möglicherweise, dass Sie „localhost“ durch „host.docker.internal“ oder „host.containers.internal“ ersetzen müssen, um einen Netzwerkpfad zum gehosteten Computer zu erhalten.

Navigieren Sie in Kibana zu Stack Management > Alerts and Insights > Connectors.

Was tun, wenn Sie diese allgemeine Setup-Warnung sehen?

Sie müssen sicherstellen, dass der xpack.encryptedSavedObjects.encryptionKey korrekt eingestellt ist. Dies ist ein häufig übersehener Schritt bei der lokalen Docker-Installation von Kibana, daher liste ich die Schritte zur Behebung in der Docker-Syntax auf.

Stellen Sie sicher, dass Sie Ihr Kibana/Konfig-Verzeichnis dauerhaft speichern, damit Änderungen erhalten bleiben, wenn der Container heruntergefahren wird. Meine Kibana-Container-Laufwerke sehen in der docker-compose.yml folgendermaßen aus:

Jetzt können Sie den Keystore erstellen und einen Wert eingeben, damit die Verbindungsschlüssel nicht im Klartext gespeichert werden.

Starten Sie Ihren gesamten Cluster vollständig neu, um sicherzustellen, dass die Änderungen wirksam werden.

Erstellen des Connectors

Erstellen Sie auf dem Connector-Konfigurationsbildschirm (navigieren Sie in Kibana zu Stack Management > Alerts and Insights > Connectors) einen Connector und wählen Sie den Typ „OpenAI“ aus.

Konfigurieren Sie den Connector mit den folgenden Einstellungen:

• Name des Connectors: Deepseek (Ollama)

• Wählen Sie einen OpenAI-Anbieter aus: andere (OpenAI-kompatibler Dienst)

• URL: http://localhost:11434/v1/chat/completions

  • Passen Sie den richtigen Pfad zu Ihrem Ollama an. Denken Sie daran, host.docker.internal oder ein Äquivalent zu ersetzen, wenn Sie aus einem Container heraus aufrufen.

• Standardmodell: deepseek-r1:7b

• API-Schlüssel: Denken Sie sich etwas aus, ein Eintrag ist erforderlich, aber der Wert spielt keine Rolle

Beachten Sie, dass das Testen eines benutzerdefinierten Connectors zu Ollama im Connector-Setup derzeit in 8.17 nicht funktioniert, aber in der nachfolgenden Kibana-Version 8.18 behoben wurde.

Unser Connector sieht so aus:

Vektoreingebettete Daten in Elasticsearch einlesen

Wenn Sie bereits mit Playground vertraut sind und Daten eingerichtet haben, können Sie zum nächsten Playground-Schritt übergehen. Wenn Sie jedoch einige schnelle Testdaten benötigen, müssen wir sicherstellen, dass unsere _inference-APIs eingerichtet sind. Ab Version 8.17 sind die Zuweisungen für Machine Learning dynamisch, sodass wir zum Herunterladen und Aktivieren des mehrsprachigen e5-Vektors nur Folgendes in den Kibana Dev-Tools ausführen müssen.

Wenn Sie dies noch nicht getan haben, wird das Herunterladen des e5-Modells aus den Modell-Repositorys von Elastic ausgelöst.

Als Nächstes laden wir ein gemeinfreies Buch als unseren RAG-Kontext hoch. Hier können Sie „Alice im Wunderland“ von Project Gutenberg herunterladen: Link. Speichern Sie es als .txt-Datei.

Navigieren Sie zu Elasticsearch > Home > Datei hochladen

Wählen Sie Ihre Textdatei aus oder ziehen Sie sie per Drag & Drop und klicken Sie dann auf die Schaltfläche „Importieren“.

Wählen Sie auf dem Bildschirm „Daten importieren“ die Registerkarte „Erweitert“ und setzen Sie den Indexnamen auf „book_alice“.

Wählen Sie die Option „Zusätzliches Feld hinzufügen“, sie befindet sich klein direkt unter „Automatisch erstellte Felder“. Wählen Sie „Semantisches Textfeld hinzufügen“ und ändern Sie den Inferenz-Endpoint in „.multilingual-e5-small-elasticsearch“. Wählen Sie „Hinzufügen“ und dann „Importieren“.

Wenn das Laden und die Inferenz abgeschlossen sind, können wir zu Playground gehen.

RAG im Playground testen

Navigieren Sie in Kibana zu Elasticsearch > Playground.

Auf dem Playground-Bildschirm sollten Sie ein grünes Häkchen und „LLM Connected“ sehen, das anzeigt, dass ein Connector vorhanden ist. Dies ist der Ollama-Connector, den wir gerade oben erstellt haben. Eine ausführlichere Anleitung für Playground finden Sie hier.

Klicken Sie auf das blaue Symbol „Datenquellen hinzufügen“ und wählen Sie den „book_alice“-Index aus, den wir zuvor erstellt haben, oder einen anderen Index, den Sie zuvor konfiguriert haben und der Inferenz-APIs für Einbettungen verwendet.

DeepSeek ist ein Gedankenkettenmodell mit starken Ausrichtungsmerkmalen. Aus der RAG-Perspektive heraus ist dies sowohl gut als auch schlecht. Das Gedankenkettentraining kann DeepSeek dabei helfen, scheinbar widersprüchliche Aussagen in Zitaten zu rationalisieren, aber die starke Ausrichtung auf Trainingswissen kann auch dazu führen, dass es seine eigene Version der Weltfakten unserer Kontextgrundlage vorzieht. Diese starke Ausrichtung ist zwar gut gemeint, erschwert jedoch bekanntermaßen die Unterweisung von LLMs bei der Erörterung von Themen, bei denen unser privates Wissen im Trainingsdatensatz eingeschränkt oder nicht gut repräsentiert ist.

In unserem Playground-Setup haben wir folgende Systemvorgabe eingetragen: „Sie sind ein Assistent für Frage-Antwort-Aufgaben anhand relevanter Textstellen aus dem Buch „Alice im Wunderland““ und die anderen Vorgaben übernommen.

Auf die Frage „Wer war bei der Teeparty?“ erhalten wir die Antwort: „Der Märzhase, der Hutmacher und die Haselmaus waren bei der Teeparty. [Zitat: Position 1 und 2]“, was korrekt ist.

Anhand der <think>-Tags können wir erkennen, dass DeepSeek bei der Beantwortung der Fragen definitiv über den Inhalt der Zitate nachgedacht hat.

Testen von Ausrichtungsbeschränkungen

Lassen Sie uns als Test ein intellektuell anspruchsvolles Szenario für DeepSeek erstellen. Wir erstellen einen Index von Verschwörungstheorien, von denen die Trainingsdaten von DeepSeek wissen, dass sie nicht wahr sind.

In den Kibana-Entwicklungstools erstellen wir den folgenden Index und die folgenden Daten:

Diese Verschwörungstheorien werden die Grundlage für unser LLM bilden. Trotz einer aggressiven Systemaufforderung akzeptiert DeepSeek unsere Version der Fakten nicht. Wären wir in einer Situation, in der wir wüssten, dass unsere privaten Daten vertrauenswürdiger, fundierter oder auf die Bedürfnisse unserer Organisation abgestimmt sind, wäre dies nicht akzeptabel:

Zur Testfrage „Sind Vögel echt?“ (Erklärung kenne dein Meme) erhalten wir die Antwort: „Im angegebenen Kontext werden Vögel nicht als real angesehen, aber in Wirklichkeit sind sie echte Tiere. [Kontext: Position 1]“. Dieser Test beweist, dass DeepSeek R1 auch auf der 7B-Parameterebene leistungsstark ist … je nach unserem Datensatz ist es jedoch möglicherweise nicht die beste Wahl für RAG.

Was haben wir also gelernt?

Zusammenfassend:

• Das lokale Ausführen von Modellen in Tools wie Ollama ist eine großartige Möglichkeit, einen Blick auf das Modellverhalten zu werfen.

• DeepSeek R1 ist ein Schlussfolgerungsmodell, was bedeutet, dass es für Anwendungsfälle wie RAG Vor- und Nachteile hat.

• Playground ist in der Lage, sich über eine OpenAI-ähnliche REST-API mit Inferenz-Hosting-Frameworks wie Ollama zu verbinden, was in dieser frühen Ära des KI-Hostings zu einem De-facto-Standard wird.

Insgesamt sind wir beeindruckt, wie weit die lokale, „air-gapped“-RAG gekommen ist. Die Tools in Elasticsearch, Kibana und die verfügbaren Open-Weight-Modelle haben sich erheblich weiterentwickelt, seit wir 2023 zum ersten Mal über die datenschutzfreundliche KI-Suche geschrieben haben.

Importieren von Geodaten mit Kibana

Die Daten, die wir für die Beispiele im vorherigen Blog verwendet haben, basierten auf Daten, die wir intern für Integrationstests verwenden. Zu Ihrer Bequemlichkeit haben wir es hier in Form einiger CSV-Dateien beigefügt, die Sie problemlos mit Kibana importieren können. Die Daten setzen sich aus Flughäfen, Städten und Stadtgrenzen zusammen. Sie können die Daten hier herunterladen:

• airports.csv

  • Dies beinhaltet die Zusammenführung von drei Datensätzen:

    • Flughäfen (Namen, Standorte und zugehörige Daten) von Natural Earth

    • Stadtstandorte von SimpleMaps

    • Flughafenhöhen aus der globalen Flughafendatenbank

• airport_city_boundaries.csv

  • Dies beinhaltet eine Zusammenführung der oben genannten Flughafen- und Städtenamen mit einer neuen Quelle:

    • Stadtgrenzen aus OpenStreetMap

Wie Sie sich vorstellen können, haben wir einige Zeit damit verbracht, diese Datenquellen in den beiden oben genannten Dateien zusammenzuführen, mit dem Ziel, die Geodatenfunktionen von ES|QL testen zu können. Dies entspricht möglicherweise nicht ganz Ihren spezifischen Datenanforderungen, aber hoffentlich gibt Ihnen dies eine Vorstellung davon, was möglich ist. Insbesondere möchten wir einige interessante Dinge demonstrieren:

• Importieren von Daten mit Geodatenfeldern zusammen mit anderen indexierbaren Daten

• Importieren von geo_point und geo_shape -Daten und deren gemeinsame Verwendung in Abfragen

• Importieren von Daten in zwei Indizes, die über eine räumliche Beziehung verknüpft werden können

• Erstellung einer Ingest-Pipeline zur Erleichterung zukünftiger Importe (über Kibana hinaus)

• Einige Beispiele für Ingest-Prozessoren, wie csv, convert und split

In diesem Blogbeitrag geht es zwar um die Arbeit mit CSV-Daten, aber es ist wichtig zu verstehen, dass es mehrere Möglichkeiten  gibt, Geodaten mit Kibana hinzuzufügen . Innerhalb der Kartenanwendung können Sie durch Trennzeichen getrennte Daten wie CSV, GeoJSON und ESRI ShapeFiles hochladen und auch direkt in der Karte Formen zeichnen. In diesem Blogbeitrag konzentrieren wir uns auf den Import von CSV-Dateien von der Kibana-Startseite.

Import der Flughäfen

Die erste Datei, airports.csv, hat einige interessante Eigenheiten, mit denen wir uns auseinandersetzen müssen. Erstens weisen die Spalten zusätzliche Leerzeichen als Trennzeichen auf, was für CSV-Dateien untypisch ist. Zweitens handelt es sich bei dem Feld type um ein Mehrwertfeld, das wir in separate Felder aufteilen müssen. Schließlich handelt es sich bei einigen Feldern nicht um Zeichenketten, sondern um Felder, die in den richtigen Datentyp konvertiert werden müssen. All dies kann mithilfe der CSV-Importfunktion von Kibana erfolgen.

Beginnen Sie auf der Kibana-Startseite. Es gibt einen Abschnitt mit dem Titel „Erste Schritte durch Hinzufügen von Integrationen“, der einen Link mit der Bezeichnung „Datei hochladen“ enthält:

Klicken Sie auf diesen Link, und Sie gelangen zur Seite „Datei hochladen“. Hier können Sie die airports.csv -Datei per Drag & Drop einfügen. Kibana analysiert die Datei und zeigt Ihnen eine Vorschau der Daten an. Das System hätte das Trennzeichen automatisch als Komma und die erste Zeile als Kopfzeile erkennen sollen. Allerdings wurden vermutlich weder die zusätzlichen Leerzeichen zwischen den Spalten entfernt, noch wurden die Typen der Felder bestimmt, da angenommen wurde, dass alle Felder entweder text oder keyword sind. Das müssen wir beheben.

Klicken Sie auf Override settings und aktivieren Sie das Kontrollkästchen für Should trim fields, und anschließend Apply um die Einstellungen zu schließen. Nun müssen wir die Datentypen der Felder korrigieren. Dies ist auf der nächsten Seite verfügbar, also klicken Sie bitte auf Import.

Wählen Sie zuerst einen Indexnamen aus und anschließend Advanced , um zur Seite für Feldzuordnungen und Datenverarbeitung zu gelangen.

Hier müssen wir sowohl die Feldzuordnungen für den Index als auch die Datenaufnahmepipeline anpassen. Erstens hat Kibana wahrscheinlich das Feld scalerank automatisch als long erkannt, aber die Felder location und city_location fälschlicherweise als keyword interpretiert. Ändern Sie sie in geo_point, sodass die Zuordnungen am Ende etwa so aussehen:

Sie haben hier eine gewisse Flexibilität, aber beachten Sie, dass die Wahl des Typs Einfluss darauf hat, wie das Feld indiziert wird und welche Art von Abfragen möglich ist. Wenn Sie beispielsweise location auf keyword belassen, können Sie keine Geodaten-Suchanfragen darauf durchführen. Wenn Sie elevation als text belassen, können Sie keine numerischen Bereichsabfragen darauf durchführen.

Jetzt ist es an der Zeit, die Datenaufnahmepipeline zu reparieren. Falls Kibana scalerank automatisch als long erkannt hat, wurde außerdem ein Prozessor hinzugefügt, um das Feld in long umzuwandeln. Wir müssen einen ähnlichen Prozessor für das Feld elevation hinzufügen, der es diesmal in double umwandelt. Bearbeiten Sie die Pipeline, um sicherzustellen, dass diese Konvertierung vorhanden ist. Bevor wir dies speichern, möchten wir noch eine weitere Konvertierung durchführen, um das Feld type in mehrere Felder aufzuteilen. Fügen Sie der Pipeline einen split -Prozessor mit folgender Konfiguration hinzu:

Die finale Datenaufnahmepipeline sollte wie folgt aussehen:

Beachten Sie, dass wir keinen Konvertierungsprozessor für die Felder location und city_location hinzugefügt haben. Dies liegt daran, dass der Typ geo_point in der Feldzuordnung das WKT- Format der Daten in diesen Feldern bereits versteht. Der Typ geo_point versteht eine Reihe von Formaten, darunter WKT, GeoJSON und mehr. Wenn wir beispielsweise zwei Spalten in der CSV-Datei für latitude und longitude hätten, hätten wir entweder einen script oder einen set Prozessor hinzufügen müssen, um diese zu einem einzigen geo_point Feld zu kombinieren (z. B. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Wir sind nun bereit, die Datei zu importieren. Klicken Sie auf Import , und die Daten werden mit den soeben definierten Mappings und der Ingest-Pipeline in den Index importiert. Sollten beim Einlesen der Daten Fehler auftreten, werden diese von Kibana hier gemeldet, sodass Sie entweder die Quelldaten oder die Einlesepipeline bearbeiten und es erneut versuchen können.

Beachten Sie, dass eine neue Aufnahmepipeline erstellt wurde. Dies kann angezeigt werden, indem man im Kibana-Bereich Stack Management auf die Option Ingest pipelines klickt. Hier können Sie die soeben erstellte Pipeline sehen und sie bei Bedarf bearbeiten. Tatsächlich kann der Abschnitt Ingest pipelines zum Erstellen und Testen von Ingest-Pipelines verwendet werden, eine sehr nützliche Funktion, wenn Sie noch komplexere Ingests planen.

Wenn Sie diese Daten sofort erkunden möchten, springen Sie zu den späteren Abschnitten. Wenn Sie aber auch die Stadtgrenzen importieren möchten, lesen Sie weiter.

Importieren der Stadtgrenzen

Die unter airport_city_boundaries.csv verfügbare Datei mit den Stadtgrenzen ist etwas einfacher zu importieren als das vorherige Beispiel. Es enthält ein city_boundary Feld, das eine WKT-Darstellung der Stadtgrenze als POLYGON ist, und ein city_location Feld, das eine geo_point Darstellung des Stadtstandorts ist. Wir können diese Daten auf ähnliche Weise wie die Flughafendaten importieren, allerdings mit einigen Unterschieden:

• Wir mussten die Überschreibungseinstellung Has header row auswählen, da diese nicht automatisch erkannt wurde.

• Wir mussten keine Felder kürzen, da die Daten bereits frei von überflüssigen Leerzeichen waren.

• Wir mussten die Datenaufnahmepipeline nicht bearbeiten, da alle Datentypen entweder Zeichenketten oder räumliche Datentypen waren.

• Wir mussten jedoch die Feldzuordnungen bearbeiten, um das Feld city_boundary auf geo_shape und das Feld city_location auf zu setzen. geo_point

Unsere endgültigen Feldzuordnungen sahen wie folgt aus:

Wie beim Import mit airports.csv zuvor, klicken Sie einfach auf Import , um die Daten in den Index zu importieren. Die Daten werden mit den von uns bearbeiteten Mappings und der von Kibana definierten Ingest-Pipeline importiert.

Erkundung von Geodaten mit Entwicklerwerkzeugen

In Kibana ist es üblich, die indizierten Daten mit dem Befehl „Discover“ zu erkunden. Wenn Sie jedoch Ihre eigene Anwendung mit ES|QL-Abfragen schreiben möchten, könnte es interessanter sein, auf die reine Elasticsearch-API zuzugreifen. Kibana verfügt über eine komfortable Konsole zum Experimentieren mit dem Schreiben von Abfragen. Dies wird als Dev Tools -Konsole bezeichnet und befindet sich in der Kibana-Seitenleiste. Diese Konsole kommuniziert direkt mit dem Elasticsearch-Cluster und kann zum Ausführen von Abfragen, Erstellen von Indizes und vielem mehr verwendet werden.

Versuchen Sie Folgendes:

Dies sollte folgende Ergebnisse liefern:

Distanz

Abkürzung

Name

Ort

Land

Stadt

Elevation

273418.05776847183

SCHINKEN

Hamburg

PUNKT (10.005647830925 53.6320011640866)

Deutschland

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

PUNKT (13.2903090925074 52.5544287044101)

Deutschland

Hohen Neuendorf

38,0

483713.15032266214

OSL

Oslo Gardermoen

Punkt (11.0991032762581 60.1935783171386)

Norwegen

Oslo

208.0

522538.03148094116

BMA

Bromma

PUNKT (17.9456175406145 59.3555902065112)

Schweden

Stockholm

15.0

522538.03148094116

ARN

Arlanda

Punkt (17.9307299016916 59.6511203397372)

Schweden

Stockholm

38,0

624274.8274399083

DUS

Düsseldorf Int'l

PUNKT (6,76494446612174 51,2781820420774)

Deutschland

Düsseldorf

45,0

633388.6966435644

PRG

Ruzyn

PUNKT (14.2674849854076 50.1076511703671)

Tschechien

Prag

381,0

635911.1873311149

AMS

Schiphol

Punkt (4,76437693232812 52,3089323889822)

Niederlande

Hoofddorp

-3.0

670864.137958866

FRA

Frankfurt International

PUNKT (8.57182286907608 50.0506770895207)

Deutschland

Frankfurt

111,0

683239.2529970079

WAW

Okecie Int'l

Punkt (20.9727263383587 52.171026749259)

Polen

Piaseczno

111,0

Visualisierung von Geodaten mit Kibana Maps

Kibana Maps ist ein leistungsstarkes Werkzeug zur Visualisierung von Geodaten. Es kann verwendet werden, um Karten mit mehreren Ebenen zu erstellen, wobei jede Ebene einen anderen Datensatz darstellt. Die Daten können auf verschiedene Weise gefiltert, aggregiert und formatiert werden. In diesem Abschnitt zeigen wir Ihnen, wie Sie in Kibana Maps eine Karte mit den Daten erstellen, die wir im vorherigen Abschnitt importiert haben.

Navigieren Sie im Kibana-Menü zu Analytics->Maps , um eine neue Kartenansicht zu öffnen. Klicken Sie auf Add Layer und wählen Sie Documents aus, wählen Sie die Datenansicht airports und bearbeiten Sie dann den Ebenenstil, um die Markierungen mithilfe des Feldes elevation einzufärben, damit wir leicht erkennen können, wie hoch jeder Flughafen liegt.

Klicken Sie auf „Änderungen beibehalten“, um die Karte zu speichern:

Fügen Sie nun eine zweite Ebene hinzu und wählen Sie diesmal die Datenansicht airport_city_boundaries aus. Dieses Mal verwenden wir das Feld city_boundary , um die Ebene zu gestalten, und stellen die Füllfarbe auf ein helles Blau ein. Dadurch werden die Stadtgrenzen auf der Karte angezeigt. Achten Sie darauf, die Ebenen neu anzuordnen, damit die Flughafenmarkierungen ganz oben liegen.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber mit dem ENRICH -Befehl lässt sich ein Sonderfall eines Joins realisieren. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

Wenn Sie diese Abfrage ausführen, ohne vorher den Anreicherungsindex vorzubereiten, erhalten Sie eine Fehlermeldung wie:

Dies liegt daran, dass ES|QL, wie bereits erwähnt, keine echten JOIN -Befehle unterstützt. Ein wichtiger Grund dafür ist, dass Elasticsearch ein verteiltes System ist und Joins aufwändige Operationen sind, die schwer zu skalieren sind. Der Befehl ENRICH kann jedoch sehr effizient sein, da er speziell vorbereitete Anreicherungsindizes nutzt, die im gesamten Cluster dupliziert werden, wodurch lokale Joins auf jedem Knoten durchgeführt werden können.

Um dies besser zu verstehen, konzentrieren wir uns auf den Befehl ENRICH in der obigen Abfrage:

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation.

Die Anreicherungsindizes und -richtlinien in Elasticsearch wurden ursprünglich für die Anreicherung von Daten während der Indexierung entwickelt, wobei Daten aus einem anderen vorbereiteten Anreicherungsindex verwendet wurden. In ES|QL hingegen funktioniert der Befehl ENRICH zur Abfragezeit und erfordert keine Verwendung von Ingest-Pipelines. Dadurch ähnelt es im Prinzip einem SQL LEFT JOIN, nur dass man nicht beliebige zwei Indizes verknüpfen kann, sondern nur einen normalen Index auf der linken Seite mit einem speziell vorbereiteten Anreicherungsindex auf der rechten Seite.

In beiden Fällen, ob für Ingest-Pipelines oder die Verwendung in ES|QL, müssen einige vorbereitende Schritte durchgeführt werden, um den Anreicherungsindex und die Richtlinie einzurichten. Wir haben den Index airport_city_boundaries bereits oben importiert, dieser kann jedoch nicht direkt als Anreicherungsindex im Befehl ENRICH verwendet werden. Zunächst müssen wir zwei Schritte durchführen:

• Erstellen Sie die oben beschriebene Anreicherungsrichtlinie, um den Quellindex, das Feld im Quellindex, mit dem abgeglichen werden soll, und die Felder, die nach dem Abgleich zurückgegeben werden sollen, zu definieren.

• Führen Sie diese Richtlinie aus, um den Anreicherungsindex zu erstellen. Dabei wird ein spezieller interner Index erstellt, indem der ursprüngliche Quellindex in eine effizientere Datenstruktur eingelesen und anschließend im gesamten Cluster kopiert wird.

Die Anreicherungsrichtlinie kann mit folgendem Befehl erstellt werden:

Die Richtlinie kann mit folgendem Befehl ausgeführt werden:

Beachten Sie, dass Sie diese Richtlinie erneut ausführen müssen, wenn Sie den Inhalt des Index airport_city_boundaries ändern, damit die Änderungen im Anreicherungsindex sichtbar werden. Führen wir nun die ursprüngliche ES|QL-Abfrage erneut aus:

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

Region

PUNKT (-12.139086859300733 31.024386116624648)

126

null

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

Punkt (39.74537850357592 47.21613017376512)

3

городской округ Батайск

PUNKT (-156.80986787192523 20,476673701778054)

3

Hawaii

PUNKT (-73.94515332765877 40.70366442203522)

3

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

PUNKT (-76.66873019188643 24.306286952923983)

2

New Providence

PUNKT (-3,0252167768776417 51,39245774131268)

2

Cardiff

PUNKT (-115.40993484668434 32,73126147687435)

2

Municipio de Mexicali

Punkt (41.790108773857355 50.302146775648)

2

Zentralbezirk

PUNKT (-73.88902732171118 45.57078813901171)

2

Montréal

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 125 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 126 Flughäfen ohne region in den Ergebnissen. Falls Ihr Anwendungsfall erfordert, dass alle Flughäfen einer Stadtgrenze zugeordnet werden können, müssten zusätzliche Daten beschafft werden, um die Lücken zu schließen. Es wäre notwendig, zwei Dinge zu ermitteln:

• Welche Datensätze im Index airport_city_boundaries haben keine city_boundary Felder?

• welche Datensätze im Index airports nicht mit dem Befehl ENRICH übereinstimmen (d.h. (überschneiden sich nicht)

Verwendung von ES|QL für Geodaten in Kibana Maps

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Der vorherige Blogbeitrag zum Thema Geodaten-Suche konzentrierte sich auf die Verwendung von Funktionen wie ST_INTERSECTS zur Durchführung von Suchvorgängen, die in Elasticsearch seit Version 8.14 verfügbar sind. Und in diesem Blog erfahren Sie, wie Sie die Daten importieren können, die wir für diese Suchvorgänge verwendet haben. Elasticsearch 8.15 brachte jedoch eine besonders interessante Funktion mit sich: ST_DISTANCE , mit der sich effiziente räumliche Distanzsuchen durchführen lassen, und dies wird das Thema des nächsten Blogbeitrags sein!