Eine kurze Anmerkung in eigener Sache: Um Terminkollisionen zu vermeiden, wird das Erscheinen neuer Artikel dieser Serie auf Montag Nachmittag verschoben.
In den bisherigen Artikeln dieser Serie habe ich erwähnt, dass logstash mit anderen Tools gemeinsam eingesetzt wird. Diese Verbindung ist so stark, dass einige davon, Elasticsearch und Kibana, als embedded Version im logstash .jar File mit ausgeliefert werden. Spricht man von einer logstash Installation, meint man damit normalerweise gleich mehrere logstash Instanzen und zusätzliche Tools. Wie es sich für freie Tools gehört, arbeitet logstash nämlich nicht nur mit den erwähnten Elasticsearch und Kibana, sondern noch mit vielen weiteren Tools zusammen, die diese beiden auch teilweise ersetzen können.
Genauer gesagt ist logstash nur ein Framework, das Plugins verwendet um diverse andere Tools miteinander zu verbinden und die Nachrichten am Weg aufzubereiten. Dabei werden viele Plugins mitgeliefert. Es ist aber verhältnismässig leicht, eigene Plugins zu schreiben. Welche Plugins mitgeliefert werden und wie die zu konfigurieren sind, findet man in der logstash Dokumentation. Dort sieht man auch schön die Aufteilung in die drei Stufen jeder logstash Instanz:
- Input
- Filter
- Output
In der Dokumentation ist Codec noch als eigener Punkt erwähnt, dabei handelt es sich aber nicht um eine eigene Stufe, sondern wird nur gemeinsam mit einer der anderen Stufen verwendet. Die Syntax ist d
abei immer ziemlich einfach und vor allem durchgängig gleich. Nur die Optionen unterscheiden sich und verändern sich auch teilweise von Version zu Version. Ein regelmässiger Blick in die Dokumentation ist deshalb bei Updates unbedingt empfehlenswert.
Input: Diese Plugins befördern Logs in die logstash Instanz. Das können passive Wege sein wie der bereits erwähnte syslog Input, der einen Port öffnet und wartet, bis dort Nachrichten ankommen, oder aktive, wie der file Input, der eine Datei überwacht und jede neue Zeile als ein neues Event verarbeitet.
Filter: Hier passiert die Magie, die logstash stark von Syslog Servern abhebt. Die Events werden verändert und aufbereitet. Das kann das Umformen eines Timestamp in ein einheitliches Format sein, das Auflösen einer IP Adresse in einen Hostnamen, oder, besonders wichtig, das Zerlegen der Nachricht in einzelne Felder. Mit dem grok Filter kann mithilfe von vorgefertigten Mustern und Regex Information aus Events klassifiziert werden, was in den erwähnten Feldern resultiert. Die Filter sind normalerweise für das Umformen und nur selten für das „Ausfiltern“ also Verwerfen von ungewollten Nachrichten zuständig.
Output: Mit diesen Plugins wird gesteuert, an welche Tools logstash seine Information ausgibt. In den bisherigen Beispielen war das eine Elasticsearch Instanz. Es ist aber auch möglich, an Icinga zu schreiben, bestimmte Events per Mail zu verschicken oder sie an andere logstash Instanzen schicken.
Sehr oft wird logstash dazu verwendet, um Daten zu weiteren Instanzen oder Zwischenspeichern wie Redis weiterzuleiten. Eine Instanz hat dabei normalerweise nur eine Aufgabe. Grob kann man logstash in Shipper und Central einteilen, wobei die Shipper Daten sammeln und an einen Zwischenspeicher schicken. Von dort holt sie dann entweder ein weiterer Shipper (um z.B. Aussenstellen mit der Zentrale zu verbinden) oder der Central ab, der üblicherweise als einziger logstash in einem grösseren System Filter verwendet. Realisiert wird das mit getrennten Konfigurationsdateien, wobei man beim Start der jeweiligen Instanz eben die passende Datei angibt. Es ist also durchaus üblich, mehrere logstash Instanzen auf einem einzigen Host zu haben. Die Bezeichnung „Shipper“ und „Central“ oder auch „Indexer“ hat sich in der Dokumentation so eingebürgert. Es handelt sich dabei nur um eine Umschreibung der konfigurierten Plugins und nicht etwa um eine eigene Einstellung in der Konfiguration oder gar eine andere logstash Version.
Sind in einer Instanz mehrere Inputs definiert, holt sich logstash Nachrichten von allen diesen Inputs. Sind mehrere Outputs definiert, wird an jeden dieser Outputs eine Kopie des gerade verarbeiteten Events geschickt. Da es keine Möglichkeit gibt, doppelte Events leicht wieder auszusortieren, sollte man sehr vorsichtig sein, wohin man Events sendet. Sind mehrere redundante Ziele vorhanden, wie z.B. mehrere Redis Instanzen, so definiert man die innerhalb eines einzelnen Outputs und logstash wählt beim Start dann eines dieser Ziele aus und sendet so lange dorthin, bis er nichts mehr annimmt und wechselt erst dann zum nächsten Ziel.
Besonders hilfreich ist das Klassifizieren der Daten in verschiedene Felder. Wer schon einmal Logs von Mailservern nach Informationen durchsucht hat, weiss, dass es nicht einfach bis unmöglich ist, zum Beispiel die Empfängeradressen aus jeder Logmeldung mit einem einzigen Shell Command auszulesen, vor allem wenn auch Filterdienste wie Spamassassin in das maillog schreiben. Mit logstash können je nach Art der Logmeldung unterschiedliche Filter angelegt werden und so ein Feld wie mail_recipient (die Namen sind frei wählbar) immer mit der Empfängeradresse befüllt werden. Bei der Auswertung mit Kibana kann dann nach dem Feld gefiltert oder Graphen anhand dessen gezeichnet werden.
0 Kommentare