Wie ihr feststellt, dass ein Host keine Logs mehr an Splunk sendet...und zwar schnell

Ich bin erst seit einigen Monaten bei Splunk, doch in dieser kurzen Zeit war eine der Fragen, die mir am häufigsten gestellt wurden: „Wie erhalte ich eine Benachrichtigung, wenn Splunk keine Logs empfängt?“.

Doch, obwohl diese Frage so oft gestellt wird, konnte ich zu meiner Überraschung in der Dokumentation nicht viel darüber finden, wie man dies mit den nativen Splunk-Funktionen erreicht. In diesem Blog möchte ich euch daher ein paar Tipps geben, wie ihr diese Frage mithilfe von Splunk und der Search Processing Language (SPL) beantworten könnt.

Ein paar Hintergrundinformationen

Bevor es losgeht möchte ich euch kurz erklären, welche Methodik hinter der verwendeten SPL steckt. Damit wisst ihr dann nicht nur, was zu tun ist, sondern versteht auch das Wie und Warum.

Auch möchte ich betonen, dass es in Splunk auf jeden Fall mehrere Möglichkeiten gibt, diese Frage zu beantworten. Es gibt beispielsweise einen Blog-Artikel über das Monitoring inaktiver Hosts mithilfe von Metadaten. Und auch ich bin zu Anfang völlig anders (doch leider völlig ineffizient) vorgegangen. Ich habe mich dann mit ein paar Kollegen beraten, und sie halfen mir, das gleiche Ergebnis mit einer viel schnelleren Suche zu erreichen. Alles dank tstats!

Hinweis am Rande: Eine fundierte Erläuterung zu tstats (und der Beschleunigung des Zugriffs auf Daten in Splunk) findet ihr in der hervorragenden .conf16-Präsentation „How to Scale: From _raw to tstats (and beyond!).“

Hinweis

Bei meinem Lösungsansatz ist zu beachten, dass diese spezielle Funktionalität davon abhängt, dass ein paar Vorbedingungen erfüllt sind, und zwar:

• Splunk muss auf die richtige Uhrzeit eingestellt sein.
• Die Zeitstempel der Events geben einen Zeitpunkt an, der in etwa der Uhrzeit entspricht, zu der das Event von Splunk empfangen und indiziert wird.
• Splunk hat innerhalb des Zeitfensters, in dem ihr sucht, Daten für diesen Index, diesen Host, diese Quelle oder diesen Source-Type empfangen.
  

Besonders der zweite Punkt ist wichtig, da Splunk bei dieser Methodik den Zeitstempel in einem Event für den Abgleich mit einem relativen Zeitfenster nutzt, um festzustellen, ob das Event innerhalb dieses Zeitraums empfangen wurde. Der Anwendungsfall hierfür wird sich auf eher „in Echtzeit laufende“ Bereitstellungen beziehen, bei denen Splunk Daten aus einer hochfrequenten Datenquelle wie etwa einem Syslog-Server oder Push-Logs über HTTP Event Collector empfängt.

Indizierte Standardfelder

Die Standardfelder, die Splunk als Teil jedes Events indiziert, sind:

1. Host
2. Source (Quelle)
3. Sourcetype
4. Uhrzeit (_time)
    

Hier ist wichtig zu wissen, dass dies alles ist, was wir an Informationen benötigen, um festzustellen, wann Splunk nach einer bestimmten Zeitspanne kein Event mehr empfangen hat. Da uns diese Informationen zur Verfügung stehen, können wir:

• Den Zeitstempel jedes Events auf der Grundlage des Hosts, der Quelle oder des Sourcetyps ermitteln, den bzw. die Splunk empfangen hat
• Einen relativen Zeitstempel berechnen, mit dem wir feststellen, ob ein Log außerhalb des Zeitfensters für den Empfang liegt
• Prüfen, ob der Zeitstempel der einzelnen Events innerhalb oder außerhalb des Zeitfensters des relativen Zeitstempels liegt
   

Wenn wir mit diesen Elementen vertraut sind, können wir eine Suche innerhalb von Splunk erstellen, mit der wir feststellen, ob ein Event nicht empfangen wurde. Wir können dann eine entsprechende Benachrichtigung versenden.

Benachrichtigung, wenn keine Daten von einem bestimmten Host eingehen

Falls ihr benachrichtigt werden möchtet, wenn Events von einem bestimmten Host nicht mehr empfangen werden, könnt ihr eine Suche erstellen, um den Zeitstempel der Events vom Host mit dem relativen Zeitfenster zu vergleichen.

| tstats latest(_time) as latest where index=* earliest=-24h by host

| eval recent = if(latest > relative_time(now(),"-5m"),1,0), realLatest = strftime(latest,"%c")

| where recent=0

_{^{Abbildung 1. Screenshot von Splunk, auf dem ein Host ohne neue Events in den letzten 5 Minuten gezeigt wird}}

Lasst uns nun einen Blick auf die SPL werfen und die einzelnen Komponenten aufschlüsseln, um die Abläufe innerhalb der Suche zu verstehen:

| tstats latest(_time) as latest where index=* earliest=-24h by host

Es wird eine tstats-Suche ausgeführt, bei der das „_time“-Feld der letzten Events abgerufen wird, die in Indizes enthalten sind, auf die der Benutzer Zugriff hat. Das früheste Event soll maximal 24 Stunden in der Vergangenheit liegen, und diese Daten sollen nach dem Hostnamen gruppiert werden.

| eval recent = if(latest > relative_time(now(),"-5m"),1,0), realLatest = strftime(latest,"%c")

Es wird ein neues Feld namens „recent“ erstellt. Um bestimmen zu können, worauf dieses Feld eingestellt werden soll, muss eine Überprüfung mit Bedingung durchgeführt werden. Tut dies, um festzustellen, ob die Uhrzeit des spätesten Events größer ist (also näher an der Gegenwart liegt) als die aktuelle Uhrzeit minus fünf Minuten. Ist dies der Fall, wird die Variable „recent“ auf 1 eingestellt, andernfalls auf 0. Außerdem wird die späteste Uhrzeit mit der Funktion „strftime“ aus dem Epoch-Format in eine menschenlesbare Form konvertiert.

| where recent=0

Alle Ergebnisse, bei denen das Flag „recent“ den Wert 0 hat, sollen zurückgegeben werden. (Grund: Wenn das Flag auf 1 oder höher eingestellt ist, hat der Index aktuelle Events empfangen.)

Hierbei verwendet Splunk jetzt den Zeitstempel des letzten, vom Host empfangenen Logs, um zu berechnen, ob dieser innerhalb des Zeitfensters, in dem Splunk den Datenempfang erwartet, ein Event übermittelt hat. Diese SPL-Anweisung lässt sich auch ganz leicht auf Quelle und Sourcetyp abändern.

Kurz zusammengefasst: Diese Suche verwendet den (sehr schnellen) Befehl tstats, um alle Hosts zu prüfen und diejenigen zu identifizieren, die innerhalb der letzten fünf Minuten keine Daten übermittelt haben. Bitte beachten: Bei dieser Abfrage wird vorausgesetzt, dass ihr an irgendeinem Punkt innerhalb eures Suchzeitraums Daten von den Hosts empfangen habt, die vom obigen Befehl aufgeführt werden.

Außerdem solltet ihr beachten, dass diese Suche bei Hosts funktioniert, die während des gesamten Suchzeitraums existiert haben (also während der vergangenen 24 Stunden).  Ich habe vor, einen weiteren Artikel darüber zu schreiben, wie man eine Lookup-Datei mit Hosts verwendet, um zu prüfen, ob die Hosts in Splunk gar nicht existieren und/oder außerhalb des Suchfensters liegen.

Benachrichtigung, wenn ein bestimmter Index keine Daten empfängt

Wenn ihr benachrichtigt werden möchtet, falls innerhalb eines bestimmten Zeitraums keine Daten von einem bestimmten Host empfangen wurden, ersetzt ihr, wie nachfolgend gezeigt, in der oben angegebenen Abfrage einfach „index“ durch „host“:

| tstats latest(_time) as latest where index=* earliest=-24h by index

| eval recent = if(latest > relative_time(now(),"-5m"),1,0), realLatest = strftime(latest,"%c")

| where recent=0

_{^{Abbildung 2. Screenshot von Splunk, der einen Index ohne neue Events in den letzten 5 Minuten zeigt}}

Abschließende Bemerkungen

Nachdem euch nun die SPL-Abfrage zur Verfügung steht, mit der ihr feststellen könnt, ob bestimmte Assets innerhalb von Splunk keine Daten senden, könnt ihr Benachrichtigungen, Berichte und Dashboards erstellen, um proaktives Monitoring einzusetzen und zu reagieren, wenn ein Gerät eventuell offline ist oder wegen anderer Probleme keine Daten sendet. Die Erstellung dieser Elemente würden den Rahmen dieses Artikels sprengen, doch auf unserer umfassenden Splunk Docs-Website finden sich die nötigen Anleitungen.

Ich hoffe, dieser Post war für euch nützlich und informativ!