Effiziente Dashboards in Splunk mit Simple XML
In einer zunehmend datengestützten Welt ist die Fähigkeit, große Datenmengen schnell und effektiv zu durchsuchen und zu analysieren, von zentraler Bedeutung. Besonders im Bereich der Datenvisualisierung und -analyse mit Tools wie Splunk ist es entscheidend, Suchanfragen und Dashboards so zu gestalten, dass sie sowohl eine hohe Leistung als auch eine benutzerfreundliche Handhabung bieten.
In diesem Blogbeitrag erläutern wir den Prozess, wie man effiziente Suchen für Splunk-Dashboards erstellt, die in Simple XML implementiert sind. Wir zeigen auf, wie man Suchanfragen sinnvoll strukturiert und Ressourcen schont, um die Performance von Dashboards zu verbessern – speziell, wenn es darum geht, große Datenmengen in Echtzeit zu visualisieren.
Wir werden anhand eines Beispiels demonstrieren, wie ein Dashboard für die Analyse interner Splunk-Logdateien entwickelt wird. Dieses Dashboard umfasst mehrere Diagramme und eine Tabelle, die dem Nutzer eine detaillierte Übersicht der Logdaten bieten sollen.
Beispiel-Dashboard
Eingabeparameter: Der Nutzer kann über ein Eingabefeld einen Zeitraum festlegen und die Aggregationsgenauigkeit der Zeitdiagramme durch die Auswahl einer Spanne definieren.
Graph 1 - Übersicht: Ein Zeitdiagramm, das die Häufigkeit von Log-Dateien nach Sourcetype im gewählten Zeitraum darstellt.
Dropdown und Graph 2 - Einzelansicht: Der Nutzer kann über ein Dropdown-Menü einen Sourcetype auswählen und diesen im gewählten Zeitraum in einem separaten Diagramm anzeigen lassen. Das Dropdown-Menü listet alle verfügbaren Sourcetypes automatisch auf.
Tabelle - Summe der Logeinträge nach Sourcetype: Diese Tabelle zeigt die Gesamtzahl der Logeinträge nach Sourcetype im gewählten Zeitraum, sortiert in absteigender Reihenfolge.
Beispiel-Dashboard:
Optimierung der Suche:
In einem klassischen Ansatz würde für jede dieser Ansichten eine eigene Suche erforderlich sein. Dies bedeutet, dass bei jedem Laden des Dashboards oder einer Änderung des Zeitraums alle drei Suchen erneut ausgeführt werden müssten. Durch die redundante Abfrage gleicher Informationen kommt es zu einer unnötig hohen Belastung des Systems. In der Folge kann die Ladegeschwindigkeit des Dashboards, insbesondere bei komplexen Suchabfragen oder vielen Elementen auf der Seite, negativ beeinflusst werden.
Um dies zu vermeiden, bietet Splunk eine effiziente Möglichkeit, die Last zu verringern: Post-Process Search. Dabei wird eine Hierarchie von Suchen erstellt, bei der eine Post-Process-Suche auf den Ergebnissen einer anderen Suche, welche dann als Base-Search bezeichnet wird, aufbaut. Dies vermeidet redundante Berechnungen und verringert die Systemlast sowie die Suchzeit.
Erstellung einer Post-Process-Suche:
Um eine Base-Search zu erstellen, wird der Suche eine eindeutige ID zugewiesen, die im <search>-Tag des XML-Dokuments definiert wird. In der Post-Process-Suche wird dann die ID der Base-Search (im Attribut base) angegeben, von der die Ergebnisse übernommen werden.
Beispiel einer Base-Search mit Post-Process-Suche:
<search id="idSuche">
<query>
<!-- SPL Abfrage -->
</query>
<earliest><!-- frühster Zeitpunkt --></earliest>
<latest><!-- spätester Zeitpunkt --></latest>
</search>
<search base="idSuche" id="andereSuche">
<query>
<!-- SPL Abfrage -->
</query>
</search>| Hinweis: Suchen können direkt im Inneren des <dashboard>-XHTML-Elements oder innerhalb eines Diagramms (<chart>), einer Tabelle (<table>) oder eines Eingabefelds (<inputs>) definiert werden. Möchte man eine im <dashboard> definierte Suche in einem Diagramm, einer Tabelle oder einem Eingabefeld verwenden, definiert man die Suche innerhalb des jeweiligen Elements und setzt im base-Attribut die ID der Suche als Wert. |
Nutzung von Tokens in Splunk:
Splunk ermöglicht die Verwendung von Tokens, um Eingabewerte zwischen verschiedenen Dashboard-Komponenten zu übertragen. Diese Tokens speichern die Werte, die der Nutzer in Eingabefeldern wie Zeit- oder Dropdown-Elementen auswählt, und ermöglichen deren Verwendung in Suchabfragen.
Im Beispiel unseres Dashboards werden die Zeit- und Spanneingaben in den Tokens tok_inp_time und tok_span gespeichert, die dann in den Suchabfragen genutzt werden, um den gewünschten Zeitraum und die Aggregationsgenauigkeit festzulegen.
Beispiel für die Definition von Tokens in XML:
<fieldset submitButton="false">
<input type="time" token="tok_inp_time">
<label>Time range</label>
<default>
<earliest>-30m</earliest>
<latest>now</latest>
</default>
</input>
<input type="dropdown" token="tok_span">
<label>Span</label>
<choice value="10s">10 s</choice>
<choice value="30s">30 s</choice>
<choice value="1m">1 m</choice>
<choice value="5m">5 m</choice>
<default>30s</default>
<initialValue>30s</initialValue>
</input>
</fieldset>
Besonderheiten beim Zeitinput:
Beim Zeitinput gibt es zwei Werte: den Startzeitpunkt und den Endzeitpunkt. Um den Zugriff auf diese Werte zu vereinfachen, erstellt Splunk automatisch zwei Tokens. Der Startzeitpunkt ist unter dem Token-Namen <tokenName>.earliest und der Endzeitpunkt unter <tokenName>.latest erreichbar. In unserem Beispiel wären dies tok_inp_time.earliest und tok_inp_time.latest.
Diese Zeitwerte können wir in der base_search innerhalb der <earliest>- und <latest>-XHTML-Elemente wie folgt verwenden:
<search id="base_search">
<query>
index=_internal
</query>
<earliest>$tok_inp_time.earliest$</earliest>
<latest>$tok_inp_time.latest$</latest>
</search>
Nun können wir das Token für die Spanne (tok_span) in den Suchen der Zeitdiagramme wie folgt verwenden:
<search base="base_search" id="timechart_search">
<query>
| timechart span=$tok_span$ count by sourcetype
</query>
</search>| Hinweis: Um Tokens von anderen Werten und Befehlen zu unterscheiden, wird ein $-Symbol um den Token-Namen verwendet. Dasselbe gilt innerhalb der SPL-Abfragen. Wenn ein Token noch nicht definiert wurde, kann die Suche nicht ausgeführt werden. Im Dashboard wird dies durch die Fehlermeldung „Suchvorgang wartet auf Eingabe“ angezeigt. |
Aufbau der Such-Hierachie mit Post Process Searches
Mithilfe von Tokens und dem Wissen von Post Process Searches, können wir das in Bild 3 folgende Schema im XML für die Diagramme und Tabellen verwenden. Es zeigt, dass die Suchen der Visualisierungen auf die Resultate anderer Suchen zugreifen. Dies wird durch Pfeile dargestellt. Somit muss keine neue Suche auf den Daten im Index gestartet werden, was schnelle und ressourcenschonende Dashboards mit vielen Elementen ermöglicht.
Im XML sieht die Umsetzung des Schemas, wie folgt aus:
<!-- Graph 1 -->
<row>
<panel>
<title>Overview</title>
<chart>
<search base="timechart_search"></search>
<option name="charting.chart">line</option>
<option name="charting.legend.placement">bottom</option>
</chart>
</panel>
</row>
<!-- Graph 2 mit Dropdown -->
<row>
<panel>
<title>Einzelansicht</title>
<input type="dropdown" token="tok_sourcetype">
<label>Sourcetype</label>
<search base="table_search">
</search>
<fieldForLabel>sourcetype</fieldForLabel>
<fieldForValue>sourcetype</fieldForValue>
<selectFirstChoice>true</selectFirstChoice>
</input>
<chart>
<search base="timechart_search" id="timechart_detail_search">
<query>
<![CDATA[
| table _time $tok_sourcetype$
]]>
</query>
</search>
<option name="charting.chart">line</option>
<option name="charting.legend.placement">bottom</option>
</chart>
</panel>
</row>
<!-- Tabelle -->
<row>
<panel>
<title>Summe Logeinträge nach Sourcetype</title>
<table>
<search base="base_search" id="table_search">
<query>
<![CDATA[
| stats count by sourcetype
| sort -count
]]>
</query>
</search>
</table>
</panel>
</row>
Schlussfolgerung
Mit den beschriebenen Techniken lässt sich die Performance eines Dashboards in Splunk signifikant verbessern, indem redundante Suchvorgänge vermieden und die Systemlast reduziert wird. Die Verwendung von Post-Process-Suchen und Tokens ermöglicht eine flexiblere und effizientere Datenvisualisierung auf Basis von Simple-XML-Dashboards.
Für eine vertiefende Schulung zu Splunk oder für Unterstützung bei der Implementierung komplexer Dashboards stehen wir Ihnen gerne zur Verfügung.
Kommentare
|
Hallo Kay,
in der Tat gilt das Limit von 50.000 Events an vielen Stellen. So auch für einige SPL-Kommandos wie top oder join. Die Anpassung von Parametern wie maxresultrows in der limits.conf kann hier helfen, hat allerdings auch Auswirkungen auf die Performanz und sollte nicht unbedacht erfolgen.
Daher ist in diesen Fällen eher die Nutzung von restriktiverer Filterung und Aggregierung, beschleunigten Datenmodellen und Summary Indizes anzuraten.
Wenn Ergebnisse von einer Post-Prozess-Suche benötigt werden, welche die Basissuche bereits eliminiert, so muss die Basissuche angepasst oder eine zweite Bassissuche angelegt werden. Auch hier verhelfen die zuvor genannten Methoden nebst optimierter SPL-Abfragen zu schnellen Antwortzeiten.
Ich hoffe, dies hilft Ihnen bei der Lösung der Herausforderungen, welche große Datenmengen mit sich bringen. Grundsätzlich existiert eine Vielfalt an Optimierungsmöglichkeiten, welche im Einzelfall betrachtet werden müssen.
Beste Grüße
Tom
|
Hallo, sehr spannendes und wichtiges Thema!
Ich habe eine Vielzahl von Splunk>Projekten begleitet mit einem tollen Team begleitet und die Wichtigkeit von performanten Dashboards, gerade im Shopflor, waren wichtige Punkte.
Dabei begegneten uns auch einige Fallstricke bei der Umsetzung des beschriebenen Vorgehens:
Gerade in Produktionen kommt es zu sehr großen Datenmengen. Die Post-Process Search kann nur auf den ersten 50.000 Ergebnissen der Base-Search operieren. Wenn die Base-Search mehr als 50.000 Events liefert, werden alle darüber hinausgehenden Events ignoriert, was zu unvollständigen oder fehlerhaften Visualisierungen führen kann.
Wie kann man dieses auflösen, oder ist da ein hard-cut?
Eine weitere Herausforderung besteht, die Post-Process-Suchen nicht alle SPL-Befehle nutzen können. Insbesondere statistische Berechnungen mit stats oder eventstats sind problematisch, da sie auf aggregierten Daten basieren, die möglicherweise nicht mehr vollständig sind.
Wie wäre hier ein Lösungsansatz?
Viele Grüße,
K-son