Da ich mich die letzte Zeit intensiv auf logstash Schulungen und – Consulting vorbereitet habe, liegt es nur nahe, dass ich auch zu diesem Thema blogge. Bei so zentralen Systemen ist es natürlich wichtig, sich intensiv damit auseinander zu setzen und viel Zeit zu investieren, um erstmal die Hintergründe und Zusammenhänge zu verstehen, damit man eine Installation planen kann, bevor man das erste Mal Code in die Hand nimmt. Prinzipiell ist das so richtig, aber es muss auch mal ok sein, einfach mal mit einem neuen, interessanten System rumzuspielen, bevor man sich intensiver damit beschäftigt, um erstmal ein gewisses Gefühl für die Arbeitsweise zu bekommen und weil es einfach Spass macht.
Und genau dafür soll dieser Quickstart Guide sein. Zuvor aber dennoch ein paar Worte dazu, was logstash denn nun eigentlich ist und wozu man es verwenden kann und soll. Wer das schon weiss, darf auch weiter nach unten scrollen. Aber keine Sorge, weitere Infos über die Abläufe in einer logstash Installation kommen noch in dieser Blogserie. Genauso ein paar Beispiele, wie Logs von logstash aufbereitet werden können. Wer also keine Lust hat, sich mal kurz logstash zu installieren, muss nur ein wenig warten.
Jeder Computer und auch sonst fast jedes Gerät, mit dem man in der IT zu tun bekommt, schreibt Logfiles, wo besondere Ereignisse festgehalten werden. Das hilft nicht nur, aber insbesondere, beim Erkennen und Nachvollziehen von aufgetretenen Fehlern. Als Administrator steht man nun vor dem Problem, dass diese Logfiles auf den Systemen bleiben und man sich erstmal dorthin verbinden muss, um sie zu lesen. So bleiben oft kleinere Fehler, die grössere Ausfälle im Vorfeld ankündigen und helfen würden, diese zu verhindern, unerkannt. Für diesen Fall bieten wir gerne Unterstützung mit Monitoring wie Icinga an. Wer aber nicht erst warten möchte, bis es kracht, sondern schon proaktiv handeln möchte, muss irgendwie an die Logfiles rankommen, ohne den halben Tag damit zu verbringen, sie von den Systemen abzuholen. Natürlich gibt es noch viele weitere Gründe, Logs zu sammeln, zu lesen und auszuwerten, aber das würde den Rahmen eines Einleitungsartikels sprengen. Es gibt bereits seit langer Zeit Lösungen wie logwatch oder syslog Server, die zumindest helfen, die Informationen aus Logfiles zu sammeln. Wozu dann logstash? Ein paar der Vorteile gegenüber herkömmlicher Lösungen sind:
- logstash kann auf vielen verschiedenen Systemen ausgeführt werden und ist als Java (bzw. JRuby) Anwendung nicht auf ein paar Betriebssysteme beschränkt
- logstash kann alle möglichen und unmöglichen Formate lesen. Syslog und Windows Eventlog sind naheliegend, aber auch über das Drupal dblog oder IRC können Nachrichten in logstash kommen. Gibt es keine Schnittstelle für einen Dienst, können auch beliebige Textfiles auf Systemen als Logfile angesehen und ausgewertet oder die Rückgabe beliebiger Programme gelesen werden.
- logstash ist von vornherein darauf ausgelegt, hervorragend zu skalieren. Alle Komponenten können mehr oder weniger auf beliebig viele Server ausgebracht und miteinander verbunden werden. Teilweise als sehr einfach zu verwaltende loadbalancing und high availability cluster, teilweise einfach als redundante Instanzen, die nichts voneinander wissen und einfach jeweils nur einen Teil der zu verarbeitenden Daten erhalten. Und das, wie von Tools, die wir unterstützen, nicht anders zu erwarten, alles ohne Lizenzkosten. Wer dann noch freie Linux Distributionen einsetzt, wird eigentlich nur durch Anschaffungs- und Betriebskosten der Hardware in der Grösse der logstash Installation beschränkt.
- logstash leitet Logs nicht einfach stumpf weiter, sondern zerlegt sie in Felder, die dann in der Auswertung genutzt werden können. Damit fällt die Regexbastelei zum Küren des grössten Spamempfängers anhand der Sendmail Logs weg, denn eine Information wie die Empfängeradresse kann schon beim Verarbeiten der Logs als eigenes Feld ausgewiesen werden, nach dem dann gefiltert oder mit dem dann Berechnungen angestellt werden können.
Jetzt aber wie versprochen die Kurzanleitung:
logstash wird als .jar File zum Download angeboten, das auch gleich ein paar andere der benötigten Tools in embedded Versionen enthält. Den Download findet man prominent unter http://logstash.net/ . Ausserdem muss Java installiert sein. logstash ist ziemlich unempfindlich, welche Java Version eingesetzt wird. In Tests hat OpenJDK-7 hervorragend funktioniert.
Als nächstes wird eine einfache Konfigurationsdatei namens logstash-quickstart.conf
angelegt:
input { stdin { type => "stdinput" } file { path => "/var/log/messages" type => "syslog" } } output { stdout { codec => rubydebug } elasticsearch { embedded => true } }
Dieses Beispiel muss mit einem User gestartet werden, der Leserechte auf /var/log/messages
hat. Wer das nicht für einen Test möchte, kann den file
Part einfach weglassen. Dieses Konfigfile lässt logstash Events aus /var/log/messages
sowie von stdin annehmen und gibt sie auf stdout aus, speichert sie aber auch gleichzeitig in die im .jar File mitgebrachte Elasticsearch Instanz.
Gestartet wird logstash mit
java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web
Dann passiert erstmal nicht viel. Nach ein paar Sekunden erhält man eine Warnung, dass verwendete Plugins noch nicht als stabil gekennzeichnet sind, die man für einen Test einfach mal ignorieren kann. Dann wartet logstash auf neue Logmeldungen. Falls nicht zufällig eine neue Nachricht in /var/log/messages
geschrieben wird, kann man auch einfach eine Testnachricht abschicken, die dann logstash durchläuft und aufgeschlüsselt wieder ausgegeben wird. Ohne weitere Konfiguration wird aber natürlich nicht viel aufgeschlüsselt, sondern die gesamte Nachricht im message
Feld wieder ausgegeben. Ein paar zusätzliche Felder fügt logstash automatisch hinzu und der type
wurde ebenfalls über die Konfiguration gesetzt.
[root@fenris ~]# java -jar logstash-1.3.3-flatjar.jar agent -f logstash-quickstart.conf -- web Using milestone 2 input plugin 'file'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.3/plugin-milestones {:level=>:warn} hello world { "message" => "hello world", "@version" => "1", "@timestamp" => "2014-01-23T12:06:27.895Z", "type" => "stdinput", "host" => "fenris.int.netways.de" }
„hello world“ ist die eingetippte Testnachricht.
Um logstash zu beenden, kann Ctrl+C gedrückt werden. Aber zuvor lohnt sich ein Blick auf http://localhost:9292/index.html#/dashboard/file/logstash.json . Woah! Das ist Kibana. Das mitgelieferte Webinterface zur Analyse der gespeicherten Events.
Und jetzt kommt der Clou: Die logstash Installation ist voll funktionsfähig und die gesammelten Events bleiben auch gespeichert, wenn man logstash beendet und später wieder neu startet. Ab hier geht es „nur“ mehr darum, die Daten in mehr und brauchbare Felder zu zerlegen, sie von mehr Quellen zu sammeln, sie zwischen Hosts mit logstash Instanzen weiterzuleiten und die beteiligten Systeme zu tunen und zu skalieren. Dazu wird es Sinn machen, die embedded Versionen von Elasticsearch und Kibana als eigenständige Instanzen ausserhalb des .jar Files zu installieren und es um weitere Tools wie Redis zu ergänzen.
Wer jetzt schon überzeugt ist, dass logstash eine feine Sache ist, findet sich sicher etwas bei unseren logstash Starterpaketen oder logstash Schulungen . Wer nicht, hat noch ein paar Folgen dieser Blogserie Zeit, sich überzeugen zu lassen.
0 Kommentare
Trackbacks/Pingbacks