In manchen Fällen wissen wir nicht genau, welche Form der Darstellung in einem Dashboard für die Anwender besonders gut geeignet ist. Manchmal hängt das davon ab, welche Vorkenntnisse die Anwender zum aktuellen Thema haben, oder aber vom gewählten Zeitbereich. Gerade in interaktiven Dashboards mit verschiedenen Auswahlmöglichkeiten (Input-Elementen) ist oft nicht vorhersehbar, welche Daten schließlich in den Panels dargestellt werden, und die „beste“ Darstellungsform ist folglich auch nicht einfach zu bestimmen.

In diesem Beispiel wollen wir zeigen, wie wir die Darstellungsform in einem Timechart an die gewählten Elemente anpassen können. Als Basis dient eine einfache Suche im index=_internal, die jeder in seiner Umgebung leicht nachstellen kann. Da wir nicht wissen, welche Sourcetypes aus diesem Index für die Anwender interessant sind, überlassen wir ihnen die Entscheidung und bieten dazu ein Multiselect-Input-Element an. In dem resultierenden Timechart mit der Suche index=_internal | timechart count by sourcetype kann es nun aber zu Situationen kommen, in denen einzelne Sourcetypes quasi unsichtbar sind, weil die Anzahl an Events des einen Sourcetypes deutlich kleiner sind als die Anzahl an Events von anderen Sourcetypes. Da sich alle Sourcetypes die gleiche Y-Achse teilen, ist die gemeinsame Darstellung von sehr großen und sehr kleine Werten problematisch.

Splunk hilft uns da mit dem Trellis-Layout, bei dem wir ein Chart basierend auf einem ausgewählten Feld in viele kleine Charts aufteilen können, von denen nach Wunsch dann jeder Chart eine separate, unabhängige Y-Achse verwenden kann. Das können wir natürlich fest im Panel konfigurieren … leider passt das aber nicht so recht, wenn die Anwender nur einen einzigen Sourcetype ausgewählt haben — dann möchten wir lieber eine Darstellung ohne Trellis haben. Um den Anwendern ja nach Auswahl im Multiselect-Input die beste Darstellung anzubieten, aktivieren wir das Trellis-Layout nur dann, wenn zwei oder mehr Werte im Multiselect-Input ausgewählt sind.

Der erste Teile des Dashboards definiert das Multiselect-Input-Element, bei dem die möglichen Werte für die Sourcetypes aus einer Suche bereitgestellt werden ( index=_internal | stats count by sourcetype | fields - count ). Die Auswahl der Anwender speist dann das Token $sourcetype_tok$, als Delimiter wird ein Leerzeichen verwendet:

Im folgenden Teil finden wir eine versteckte Suche, die nur verwendet wird, um ein weiteres Token zu berechnen. Diese Suche basiert auf einem | makeresults, um möglichst schnell zu sein. Mit Hilfe des Tokens $sourcetype_tok$ aus dem Multiselect-Input-Element berechnet diese Suche das Feld multiselect. Bei jeder Änderung des Tokens $sourcetype_tok$ ändert sich also auch der Wert des Feldes multiselect. Die Zeile setzt dann ein weiteres Token $trellis_enabled_tok$ je nach Inhalt des Feldes multiselect: wenn in diesem Feld ein Leerzeichen vorkommt ( like($result.multiselect$,"% %") ), dann bekommt das Token den Wert 1, ansonsten 0.

Die beiden entscheidenden Token sind nun definiert, schauen wir uns an wie sie verwendet werden. Die gewählten Sourcetypes im Token $sourcetype_tok$ sehen wir in der Suche des eigentlichen Charts in dem Filter sourcetype IN ($sourcetype_tok$) . Wir sehen im Ergebnis später also nur die Sourcetypes, welche die Anwender gerade aktiv ausgewählt haben:

Am Ende des Charts sehen wir dann die Verwendung des Tokens $trellis_enabled_tok$: Der Eintrag $trellis_enabled_tok$ aktiviert das Trellis-Layout nur dann, wenn dieses Token den Wert 1 enthält. Basierend auf der obigen Bedingung if(like($result.multiselect$,"% %"),1,0) ist das dann der Fall, wenn das Token aus dem Multiselect-Input-Element mindestes ein Leerzeichen, also mindestens zwei gewählte Werte enthält:

Schauen wir und das ganze jetzt im Bild an, zunächst mit einem ausgewählten Sourcetype, also mit deaktiviertem Trellis-Layout:

Und dann mit mehreren ausgewählten Sourcetypes, wodurch automatisch das Trellis-Layout aktiviert wird. Wir sehen dabei sehr schön, dass die Y-Achse beim Sourcetype scheduler z.B. nur bis 5 geht, beim Sourcetype splunk_ui_access hingegen bis 2000. Wären diese beiden Werte in einem einzelnen Chart mit geteilter Y-Achse, würde der Sourcetype scheduler einfach verschwinden:

Das komplette Dashboard sieht dann so aus:

Übrigens bieten wir auch Jobs an. Mehr erfährst du hier.