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.

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.

Genau aus diesem Grund haben wir schreibgeschützte Dashboards entwickelt. Das ist die Kontrolle, die Sie sich gewünscht haben. Geben Sie Dashboards vertrauensvoll weiter, ohne befürchten zu müssen, dass die nächste Person mit Bearbeitungsrechten sie verändert oder zerstört.

Hinweis: Schreibgeschützte Berechtigungen sind in Elastic Cloud Serverless und ab Version 9.3 für Elastic Cloud Hosted und Elastic Self-Managed verfügbar.

Wenn die Option „Jeder kann bearbeiten“ Probleme bereitet

In Kibana hat das Teilen in der Regel Berechtigungen auf Space-Ebene bedeutet. Wenn jemand Dashboards in einem Bereich erstellen kann, kann er auch die Dashboards anderer Personen bearbeiten oder löschen. Das ist großartig für die Zusammenarbeit – bis es das nicht mehr ist. Eine einzige versehentliche Änderung kann zu Fehlentscheidungen, Vertrauensverlust und viel Aufräumarbeit führen.

Wir haben die Workarounds gehört: „Wir haben ‚read-only‘ in den Dashboard-Namen gesetzt und hoffen, dass die Leute es bemerken.“ Oder: „Wir markieren sie und drücken die Daumen.“ Hoffnung ist kein Genehmigungsmodell. Sie brauchten eine echte Möglichkeit, ein Dashboard zu sperren, ohne alle aus dem Bereich auszusperren.

Was tatsächlich schiefgeht

Deb und Kevin haben beide Bearbeitungszugriff auf das Log-Monitoring-Dashboard im Operationsbereich. Kevin nimmt einige Änderungen an den Charts vor. Als Deb zurückkommt, stimmen die Zahlen nicht mit den von ihr präsentierten überein. Sie muss herausfinden, was sich geändert hat (oft aus dem Gedächtnis), es beheben und sich fragen, wie viele Berichte mit falschen Daten verschickt wurden.

Schreibgeschützte Dashboards: Verantwortung und Kontrolle, die sinnvoll sind

Schreibgeschützte Dashboards lösen dieses Problem, indem sie Ihnen die Kontrolle darüber geben, ob andere Nutzer das Dashboard bearbeiten können. Wenn Sie ein Dashboard teilen, wählen Sie: Bearbeiten (Standard, wie heute) oder Ansehen. Im Ansichtsmodus können nur Sie (und die Kibana-Administratoren) es ändern oder löschen. Alle anderen können es öffnen, verwenden und darauf vertrauen, aber sie können es nicht verändern.

Was Sie erhalten

• Dashboard-Integrität: Im Ansichtsmodus können andere Nutzer mit Bearbeitungszugriff das Dashboard nicht ändern oder löschen. Wenn sie es versuchen, wird ihnen mitgeteilt, dass es gesperrt ist. Ihre Diagramme und Logik bleiben so, wie Sie sie verlassen haben.

• Sie behalten die Kontrolle: Sie sind der Besitzer. Sie können jederzeit bearbeiten, verfeinern und aktualisieren. Das Teilen als Nur-Ansicht sperrt Sie nicht aus; es fixiert die Version, die alle anderen sehen.

• Flexibler Lebenszyklus: Sie können ein Dashboard jederzeit wieder auf „bearbeitbar“ umschalten. Und Kibana-Administratoren können weiterhin alle Dashboards verwalten (zum Beispiel, wenn der Eigentümer ausscheidet). Keine Sackgassen.

Sie können finalisierte, missionskritische Dashboards weitreichend teilen und sicher sein, dass sie konsistent bleiben. Dies ist in allen Elastic-Stufen und -Angeboten verfügbar, einschließlich Serverless.

Wer kann was tun?

Schnelle Referenz nach Rolle:

• Dashboard-Besitzer: Sie haben es erstellt; Sie haben vollen Bearbeitungszugriff.

• Kibana-Administrator: Kann alle Dashboards verwalten.

• Nutzer mit Bearbeitungsrechten: Kann eigene Dashboards erstellen und bearbeiten; kann schreibgeschützte Dashboards weder bearbeiten noch löschen.

• Nutzer mit Ansichtsrechten: Kann nur Dashboards anzeigen (und auflisten).

Aktion

Dashboard-Inhaber

Kibana-Administrator

Nutzer mit Bearbeitungsrechten

Nutzer mit Space-Ansicht

Dashboards auflisten und anzeigen

✔

✔

✔

✔

Neue Dashboards erstellen

✔

✔

✔

✘

Bearbeitbare Dashboards ändern/löschen

✔

✔

✔

✘

Dashboards mit Lesezugriff ändern/löschen

✔

✔

✘

✘

So aktivieren Sie den Schreibschutz

Sie können den schreibgeschützten Modus beim Speichern eines neuen Dashboards oder später über das Freigabemenü festlegen.

Beim Speichern eines neuen Dashboards

• Erstellen Sie Ihr Dashboard, und klicken Sie auf Speichern.

• Suchen Sie im Modal „Als neues Dashboard speichern“ nach Berechtigungen.

• Ändern Sie diese von Kann bearbeiten in Kann ansehen.

• Klicken Sie auf Speichern. Das war's. Für alle anderen ist es schreibgeschützt.

Für ein Dashboard, das Sie bereits besitzen

• Dashboard öffnen.

• Öffnen Sie das Menü Dashboard teilen.

• Im Freigabemodal suchen Sie Berechtigungen und wechseln Sie zu Kann anzeigen. Die Änderung tritt sofort in Kraft; andere Nutzer im selben Bereich können sie nicht mehr bearbeiten oder löschen.

• Sie können mit der Maus über die Aktion Teilen fahren, um zu sehen, welche Art von Berechtigungen ein bestimmtes Dashboard hat.

Sehen, welche Dashboards gesperrt sind

In der Hauptliste der Dashboards haben Dashboards, die Sie nicht bearbeiten oder löschen können, ein deaktiviertes Auswahlkästchen. Dadurch lässt sich leicht erkennen, welche Inhalte nur zur Ansicht freigegeben sind.

Im Dashboard werden Sie außerdem feststellen, dass die Aktion „Bearbeiten“ deaktiviert ist und ein Tooltip erscheint, der erklärt, dass das Dashboard als schreibgeschützt eingestellt wurde.

Ausprobieren

Schreibgeschützte Dashboards sind jetzt verfügbar. Erstellen Sie ein Dashboard, setzen Sie es auf Ansehen und teilen Sie es. Ihr Team erhält eine einzige verlässliche Informationsquelle, und Sie erhalten Sicherheit. Kein „Bitte nicht bearbeiten“ mehr im Titel.

Wir würden gerne hören, wie Sie schreibgeschützte Dashboards verwenden. Teilen Sie Ihr Feedback in unserem Community-Forum mit.

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.