Als Splunk PS Consultants führen wir häufig sogenannte Health Checks durch, bei denen wir die Splunk-Installation der Kunden prüfen und die Möglichkeiten zur Optimierung dokumentieren. Einer der Punkte, der bei fast jedem Health Check auftritt ist die sub-optimale Konfiguration von Sourcetypes. Diese Sourcetype-Konfiguration definiert sehr wichtige Aspekte bei der Verarbeitung von eingehenden Daten in Splunk, u.a. das Linebreaking, also das Aufteilen großer Datenblöcke in einzelne Events, sowie die Erkennung der Zeitstempel (Timestamp recognition). Splunk bringt einige Standard-Einstellungen mit, die auch ohne explizite Konfiguration versuchen, diese Aspekte möglichst gut abzudecken. Allerdings gibt es immer das Risiko, dass die Standard-Einstellungen nicht alle Sonderfälle in den Logs zu 100% richtig erkennen, und zum anderen sind die Standard-Einstellungen so definiert, dass sie auf möglichst viele Fälle zutreffen — was aber alles andere als Performance-optimiert ist. Untersuchung bei Splunk haben gezeigt, dass in einigen Fälle durch die korrekte Konfiguration des Sourcetypes  bei einer definierten Datenmenge um fast 75% reduziert werden konnte!

Für jeden Sourcetype sollte es in einer Splunk-Installation eine entsprechende Konfiguration geben. Die folgenden Parameter stellen die Best Practices zur Definition von Sourcetypes das, genauer gesagt zur Konfiguration von Line Breaking und Timestamp Recognition – weitere Parameter für andere Aspekte sind natürlich möglich. In diesem Beitrag stellen wir die grundlegenden Parameter vor, in den folgenden Beiträgen werden wir an konkreten Beispielen den Umgang mit besonderen Log-Formaten zeigen.

Die ersten 6 Parameter werden in der props.conf auf der Splunk-Instanz eingesetzt, welche die Parsing-Phase ausführt, also in den meisten Fällen ein Indexer. Falls die Daten auf dem Weg von der Quelle zum Indexer über einen Heavy Forwarder laufen, wird die Parsing Phase in der Regel auf dem HF ausgeführt: in diesem Fall muss die entsprechende Konfiguration auf dem HF und nicht auf dem Indexer ausgerollt werden:

1. TIME_PREFIX: ein regulärer Ausdruck, der beschreibt an welcher Stelle im Event der Zeitstempel beginnt, der als _time verwendet werden soll.
2. MAX_TIMESTAMP_LOOKAHEAD: Die Länge des Zeitstempels.
3. TIME_FORMAT: Das Format des Zeitstempels in der strptime()-Notation (siehe https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Commontimeformatvariables)
4. SHOULD_LINEMERGE = false. Sollte immer auf false stehen, wenn es keine zwingenden Gründe dagegen gibt.
5. LINE_BREAKER: ein regulärer Ausdruck, der die Grenze zwischen zwei Events angibt. Default ([[\r\n]+), also einer oder mehrere Zeilenumbrüche.
6. TRUNCATE = 999999. Schützt lange Events davor, abgeschnitten zu werden. Der Wert 0 verhindert das Abschneiden komplett.

Die nächsten 2 Parameter werden in der props.conf auf der Splunk-Instanz eingesetzt, welche die Input-Phase ausführt, also in den meisten Fällen ein Universal Forwarder:

7. EVENT_BREAKER_ENABLE: Aktiviert den Prozess, der auf dem Universal Forwarder (ab 6.5) die Grenzen zwischen Events erkennen kann. Sobald dieser Prozess aktiv ist (pro Sourcetype), kann der Forwarder beim LoadBalancing auf den nächsten Indexer wechseln, auch wenn er noch keine End of File erkannt hat.
8. EVENT_BREAKER: ein regulärer Ausdruck, der die Grenze zwischen zwei Events angibt. Default ([[\r\n]+), also einer oder mehrere Zeilenumbrüche.

Bei sehr langen multiline Events hilft der folgende Parameter, die gewünschte Anzahl der Zeilen zu kontrollieren (wieder in der Parsing-Phase):

9. MAX_EVENTS: Maximale Anzahl der Zeilen in einem multiline Event, weitere Zeilen werden verworfen. Default: 256.

Wir sind also auf der sicheren Seite, wenn wir jede Konfiguration für einen Sourcetype mit dem folgenden Template beginnen:

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