Dies ist die deutsche Version des im englischen Original bei helgeklein.com erschienenen Artikels.
Wahrscheinlich hast du schon einmal von Splunk gehört, aber kannst du einem Kollegen in wenigen Sätzen beschreiben, was es genau ist? Das ist gar nicht so einfach. Splunk passt in keine der althergebrachten Software-Schubladen. Das macht es interessant, aber auch schwieriger zu erklären. Dies ist mein Versuch.
Google für Logdateien
Was machst du, wenn du Informationen über den Zustand eines Rechners oder einer Anwendung benötigst? Du schaust dir die entsprechenden Logdateien an. Anhand der protokollierten Informationen kannst du als IT-Profi schließen, in welchem Zustand das System ist und wie es dahin gekommen ist. Sehr schön! Was machst du, wenn du Informationen über den Zustand aller Rechner oder Anwendungen benötigst? Logdateien durchsehen wäre die richtige Antwort, wenn das nur realistisch durchführbar wäre. Hier kommt Splunk ins Spiel. Splunk begann als eine Art „Google für Logdateien“. Heute bietet es viel mehr, aber auf der Verarbeitung textbasierter Logdateien baut vieles andere auf. Splunk speichert all die vielen im Rechenzentrum anfallenden Logdateien und bietet eine sehr schnelle Suche darauf, ganz grob wie Google das für das Internet tut.
Search Processing Language
Man kann natürlich ganz einfach nach einem einzelnen Begriff, wie zum Beispiel einem Benutzernamen oder einer Fehlermeldung suchen und schauen, wie oft der in einem bestimmten Zeitraum in den Logs auftaucht. Splunks Search Processing Language (SPL) bietet jedoch sehr viel mehr. SPL ist ein äußerst leistungsfähiges Werkzeug zur Analyse großer Datenmengen. Es bietet umfangreiche statistische Befehle zur Berechnung genau der gewünschten Kennzahlen von einer zuvor per Suche exakt ausgewählten Teilmenge an Daten. Wie SQL, nur mächtiger. Viel mächtiger. Ein Beispiel: nehmen wir an, du willst wissen, welche Anwendungen am langsamsten starten, den Anwender also am längsten warten lassen. Die folgende Suche beantwortet diese Frage. Zunächst werden die relevanten Daten durch Angabe eines sogenannten Sourcetype („ProcessStartup“) selektiert. Das Ergebnis dieses Einzelbefehls wird dann einem weiteren Befehl übergeben (Pipe-Syntax wie unter Unix bzw. in der PowerShell: „|“), der die Daten nach Anwendungen gruppiert („by Name“), den Durchschnitt für jede Gruppe berechnet („avg(StartupTimeMs)“) und das Resultat über die Zeit verteilt darstellt („timechart“):
index=uberagent sourcetype=uberAgent:Process:ProcessStartup | timechart avg(StartupTimeMs) by Name
Das Ergebnis sieht in etwa so aus:
Apps, Add-ons und Datenquellen
Wenn man den vorigen Abschnitt liest könnte man auf den Gedanken kommen sich zu fragen, woher Splunk denn Informationen über die Dauer von Anwendungsstarts hat. Gute Frage. Von Haus aus weiß Splunk tatsächlich gar nichts. Aber es kann Daten aus einer Vielzahl von Quellen einlesen: aus allen möglichen Arten von Logdateien, Windows-Ereignisprotokollen, Syslog, SNMP, und noch aus einigen weiteren. Wenn die benötigten Informationen in keinem Log fertig drinstehen, kann man ein Skript schreiben und Splunk anweisen, dessen Ausgabe ähnlich wie eine Logdatei weiterzuverarbeiten. Wenn das immer noch nicht genügt ist vielleicht ein Blick in Splunks App-Verzeichnis sinnvoll. Im Beispiel wurden die Daten von uberAgent erzeugt, unserem Windows-Agenten für Splunk. uberAgent läuft auf den zu überwachenden Windows-Rechnern unabhängig von Splunk, schickt die erhobenen Daten jedoch zu Splunk zur Speicherung und Weiterverarbeitung. Splunk-Apps können Daten erheben, aber ebenso auch Dashboards enthalten, die visualisieren, was zuvor in Splunk gespeichert wurde. Im Fall von uberAgent werden beide Arten verwendet: der eigentliche Agent sammelt Daten während eine Dashboard-App die in den Splunk-Indizes gespeicherten Daten für den Anwender aufbereitet. Ersterer läuft auf den überwachten Maschinen, letzere auf den Splunk-Servern.
Index, (kein) Schema, Ereignisse
Viele stellen sich bei der ersten Beschäftigung mit Splunk eine Art Datenbank vor. Das ist jedoch irreführend. Wo eine Datenbank die Definition von Tabellen und Feldern erzwingt, bevor Daten darin gespeichert werden können, akzeptiert Splunk fast alles direkt nach der Installation. Anders gesagt: Splunk hat kein festes Schema. Stattdessen wird erst bei einer Suche eine Feldextraktion durchgeführt. Viele Logdateiformate werden vollautomatisch erkannt, für exotischere Formate kann man Splunk in Konfigurationsdateien auf die Sprünge helfen. Dieser Ansatz bietet eine große Flexibilität. So wie Google jede Webseite „crawlen“ kann, ohne etwas über deren Inhalt zu wissen, indiziert Splunk alle Arten maschinengenerierter Daten, die in Textform darstellbar sind. Während der Indizierungsphase, in der Splunk hereinkommende Daten verarbeitet und für die Speicherung vorbereitet, führt der Indizierer eine entscheidende Änderung an den Daten durch: er unterteilt den Strom in einzelne Ereignisse. Ein Ereinigs korrespondiert beispielsweise mit einer Zeile einer Logdatei. Jedes Ereignis erhält einen eigenen Zeitstempel, der typischerweise direkt aus der verarbeiteten Textzeile extrahiert wird, sowie einige weitere Standardeigenschaften wie zum Beispiel den Namen des Rechners, von dem die Daten stammen. Anschließend werden Schlüsselwörter zur Suchbeschleunigung einem Index hinzugefügt und der Ereignistext in einer komprimierten Datei direkt im Dateisystem gespeichert.
Skalierbarkeit, (kein) Backend
Das bringt uns zum nächsten Punkt: es gibt kein aufwenig zu verwaltendes Backend, keine komplexe Datenbank, nichts. Splunk speichert direkt im Dateisystem. Das ist aus mehreren Gründen sinnvoll:
- Superschnelle Installation Splunk ist für viele verschiedene Plattformen verfügbar; unter Windows klickt man sich einfach durch das Installationsprogramm und hat nach wenigen Minuten eine voll funktionsfähige Installation.
- Einfache Skalierbarkeit Wenn ein einzelner Splunk-Server der Last nicht mehr gewachsen ist, fügt man einfach einen weiteren hinzu. Eingehende Daten werden automatisch auf die vorhandenen Server verteilt und Suchanfragen werden von allen Servern parallel verarbeitet, so dass die Geschwindigkeit mit der Anzahl an Servern steigt. Optional kann redundante Speicherung aktiviert werden, so dass jedes Ereignis auf zwei oder mehr Servern vorgehalten wird.
- Kein Single Point of Failure Ich habe zu viele Rechenzentren gesehen, wo ein einziger unterdimensionierter Datenbankserver Dutzende Anwendungen ausgebremst hat, ohne dass jemand die Ursache für die Performanceprobleme identifiziert hätte. Dies ist ein großartiger Anwendungsfall für uberAgent, aber mein eigentlicher Punkt ist, dass so etwas mit Splunk nicht passiert.
- Beliebig lange Datenhaltung ohne Verlust an Genauigkeit Manche Monitoring-Produkte halten Daten nur für eine gewisse Zeit vor. Andere reduzieren die Genauigkeit älterer Daten, um Platz zu sparen. Das tut Splunk nicht. Es kann problemlos hunderte von Terabytes pro Tag an neuen (!) Daten verarbeiten und praktisch unbegrenzte Datenmengen speichern. Wenn du die Dauer von Benutzeranmeldungen heute mit jener vor einem Jahr vergleichen willst: nur zu!
Lizenzierung, Download und Testinstallation
Wenn du Splunk oder uberAgent ausprobieren möchstest: diese Anleitung ermöglicht einen einfachen Einstieg.
Lizenzierung im Schnelldurchlauf: Splunk begrenzt die Datenmenge, die pro Tag indiziert werden kann. Eine kostenlose Version ermöglicht die Verarbeitung von 500 MB pro Tag. Wenn man eine Splunk Enterprise-Lizenz kauft, erwirbt man täglich zu indizierendes Datenvolumen. Die Anzahl der Splunk-Server, auf denen die Daten gespeichert werden, wie lange die Daten vorgehalten werden und wie weit zurück man in den Daten suchen kann wird nicht eingeschränkt.
Happy splunking!
http://faq-o-matic.net/?p=6159