Quelle: Airbus.com

Wenn im System etwas hakt, ist das Logfile die erste Anlaufstelle für den informationssuchenden Admin. Logstash, ein Logserver mit eingebauten Analysetools, hilft dabei, die Protokolle vieler Server zentral zu archivieren, und macht die Daten ganz nebenbei auch noch durchsuchbar.

Im Cockpit eines Unternehmens zählt nur eins: Gibt’s Probleme, dann muss der Admin schnell deren Ursachen herausfinden. An den Daten hapert es meist nicht, denn die meisten IT-Systeme liefern brav und stetig Systemprotokolle und Fehlermeldungen. Doch die richtig auswerten – das ist in komplexen Netzwerken mit vielen Maschinen, Geräten, Systemen und Servern oft leichter gesagt als getan: Die Suche in den Logdateien verschiedener Dienste auf einem System gestaltet sich oft mühsam.

Die moderne Technik liefert zu viele Daten

Wer beispielsweise mit dem Clustermanager Pacemaker gearbeitet hat, kennt das Problem nur zu gut: Gerade Pacemaker gilt als besonders geschwätzig, denn wenn andere Dienste sich mit wenigen Logmeldungen begnügen, produziert er ein Vielfaches an Output.

Webserver-Logs von Apache sind ebenfalls ein gutes Beispiel – in den meisten Fällen richten Administratoren Apache nämlich so ein, dass er für jeden virtuellen Host separat loggt. Auf Webservern, die viele Kunden betreuen, kommt so eine unüberschaubare Menge an Logdateien zusammen, das Debuggen einzelner Probleme eines einzelnen Nutzers gerät zur Sisyphusarbeit.

Ein weiterer Faktor macht Admins das Leben schwer: Zwar sind in Fällen, in denen die Anzahl der zu administrierenden Server 20 nicht übersteigt, die Logs auf den einzelnen Maschinen meist noch überschaubar. Doch IT-Setups wachsen, Cloud-Computing-Umgebungen, die auf Open Stack, Cloud Stack oder andere Plattformen setzen, begnügen sich nur selten mit weniger als 20 Servern.

Zur Informationsflut aus den Logs kommen so auch die Meldungen weiterer Server, die der Admin händisch zusammensuchen muss. Als Klassiker gegen derartige Probleme etablierten Admins das Prinzip des Logservers: Logs sammeln sie nicht mehr auf den Hosts selbst, sondern auf einer zentralen Maschine.

Der Klassiker: Ein zentraler Logserver

Das verhindert wenigstens, dass Admins sich beim Navigieren per SSH zwischen Servern die Finger wund tippen. Aber dass auch ein zentraler Logserver die Datenmenge nicht verringern kann, versteht sich von selbst. Hilfreich wäre es, wenn der zentrale Logging-Dienst die Logdateien der zu überwachenden Systeme nicht nur sammelt, sondern sie auch indexiert und so durchsuchbar macht, wie es die kommerzielle Software Splunk ([1], [2]) demonstriert.

Die Open-Source-Welt schickt hier Tools wie Logstash [3] ins Feld: Die versprechen den Admins einerseits einen zentralen Logging-Dienst, bieten überdies aber auch die Option, per Webinterface in vorhandenen Logeinträgen zu suchen. Streng genommen ist es nicht Logstash allein, das sich um die sinnvolle und zentrale Verwaltung von Logdateien kümmert. Denn damit es seine Aufgaben wie versprochen erfüllen kann, benötigt es einige Helfer.

Logstash und seine Helfer

Logstash selbst ist eine Java-Applikation, und bei allen Vorurteilen, die Admins – sei es berechtigt oder unberechtigt – gegen Java haben, war die Entscheidung für Java seitens der Logstash-Entwickler gut begründet. Denn eben weil Java auch für Windows selbstverständlich zur Verfügung steht, lassen sich mit Logstash auch dessen Logdateien problemlos mit in die Sammlung aufnehmen – das ist bei anderen Rsyslog-Diensten in vielen Fällen nur mit mancherlei Verrenkungen zu erreichen.

Eine Logstash-Installation, die sich über mehrere Server erstreckt, besteht aus mindestens fünf verschiedenen Diensten. Die zentrale Rolle nehmen die Logstash-Komponenten selbst ein: Der Shipper ist quasi ein Client, der auf jedem Zielsystem läuft und dort Log-Messages einsammelt. Diese schickt er im nächsten Schritt an den Indexer, der die Logmeldungen nach den Vorgaben des Admin interpretiert und weiterverarbeitet.

Auf demselben Host, auf dem auch der Indexer zu finden ist, läuft in der Regel auch der Webserver von Logstash, der Admins ein Suchfeld für Logdateien bietet. Im Hintergrund tun zwei weitere Dienste ihre Arbeit, die nicht direkt zu Logstash gehören, für dessen Funktion aber dennoch wichtig sind: der Nachrichtenbroker Redis sowie die Suchumgebung Elasticsearch.

Redis ist der zentrale Dreh- und Angelpunkt für die Kommunikation der Shipper und des Indexers. Die Logstash-Instanzen auf den einzelnen Servern liefern ihre Nachrichten beim Redis-Server ab, von wo der Logstash-Indexer sie im nächsten Schritt bezieht. Elasticsearch – ebenfalls eine Java-Anwendung – baut den Index im Hintergrund und bietet auch die Schnittstelle, an die der Webserver von Logstash Suchanfragen vom Webinterface weiterleitet.

Modulares Design

Ein großer Vorteil von Logstash ist seine Vielfalt, die aus dem modularen Design hervorgeht. Das macht das Werkzeug nämlich sehr flexibel, bis vor einigen Monaten war es bei Logstash-Installationen zum Beispiel Usus, anstelle von Redis einen AMQP-Broker zu nehmen, wobei es dabei meist auf Rabbit MQ [4] hinauslief.

Das »amqp« -Modul für Logstash war jedoch weder besonders gut gepflegt noch bei den Logstash-Entwicklern beliebt. Die Entscheidung, auf einen anderen Broker umzusteigen, ließ sich sehr leicht umsetzen, da lediglich die Schnittstelle zum Messaging-Broker in Code zu gießen war. Mittlerweile funktioniert der Redis-Connector tadellos und Rabbit MQ avanciert zum Relikt aus vergangenen Zeiten.

Ohne Grenzen

Auch an anderer Stelle wird deutlich, dass der Kreativität der Admins bei Logstash kaum Grenzen gesetzt sind: Das Tool bietet die Möglichkeit, über definierte Filter Logeinträge nicht nur zu archivieren, sondern sie auch zu interpretieren, da einzelne Werte einer Logzeile indexiert und suchbar sind.

Ein Beispiel: HTTP-Logs verwaltet Logstash auf Wunsch so, dass per Webinterface später die gezielte Suche nach allen Zugriffen möglich ist, die einen “Internal Error” hervorgerufen haben. Auf beispielsweise Pacemaker angewandt könnte das auch bedeuten, dass Admins nach genau solchen Logmeldungen suchen können, in denen Pacemaker ausdrücklich einen Fehler mit »ERROR« -Präfix meldet.

Darüber hinaus lassen sich über die Filter auch unterschiedliche Einträge aus den Log-Aufzeichnungen völlig entfernen. Wer zum Beispiel verhindern möchte, dass die klassischen »– MARK –« -Meldungen von Syslog im Logarchiv landen, passt dazu lediglich die Konfiguration der Logstash-Shipper an.

Test-Setup

Wer Logstash ausprobieren möchte, hat Glück. Entgegen allen Unkenrufen im Netz ist die Installation nämlich keineswegs eine Herkulesarbeit. Wichtig ist nur, vorher klarzustellen, welche Rolle welchem Host zukommt. Wenn feststeht, auf welchem Host der Redis-Server und Elasticsearch sowie der eigene Indexer von Logstash laufen sollen, kann es losgehen. Das folgende Beispiel orientiert sich an Ubuntu 12.04, funktioniert auf Debian aber auch. RPM-Pakete für Redis und Elasticsearch stehen für die typischen Enterprise-Distributionen im Netz ebenfalls zur Verfügung, auch auf RHEL oder SLES liegt dem Vergnügen also nichts im Wege

Wie einfach die Installation von Redis funktioniert, hängt maßgeblich von der Antwort auf die Frage ab, ob es Redis-Server-Pakete für das eigene System gibt. Auf Ubuntu reicht ein simples »apt-get install redis-server« , um die Komponenten zu installieren. Im Anschluss empfiehlt es sich, in »/etc/redis/redis.conf« den Eintrag »bind 127.0.0.1« so abzuändern, dass er die tatsächliche IP-Adresse des Hosts enthält.

Ansonsten macht Redis nämlich tatsächlich eine Verbindung zum Localhost auf, was dem Ansinnen zuwiderläuft, andere Hosts ihre Logstash-Meldungen direkt an Redis ausliefern zu lassen. Wer Wert auf Sicherheit legt, sollte in »redis.conf« über die »requirepass« -Direktive ein Passwort für den Zugriff definieren.

Elasticsearch installieren

Elasticsearch (Abbildung 1) ist wie Logstash eine Java-Anwendung, für die in Ubuntu aber leider keine Pakete vorhanden sind. Zum Glück hilft der Upstream aus und stellt auf seiner Website [5] ein fertiges ».deb« -Paket bereit, auf Ubuntu lässt es sich mit »dpkg -i« ebenfalls installieren. Der Befehl gibt zwar zunächst eine Fehlermeldung aus, das liegt jedoch an Abhängigkeiten, die nicht erfüllt sind. Nach dem Befehl »apt-get -f install« ist Elasticsearch einsatzbereit.

Abbildung 1: Die eigentliche Organisation und Verwaltung der Lognachrichten erledigt nicht Logstash, sondern Elasticsearch, das im Hintergrund mitläuft.

Achtung: Auch Elasticsearch lauscht in der Standardvariante nur auf 127.0.0.1, sodass ein eventuell vorhandener Indexer zwingend auf dem selben Host laufen muss. Sollen Elasticsearch und der Index-Dienst von Logstash auf unterschiedlichen Hosts laufen, finden Admins die notwendigen Schalter in »/etc/elasticsearch/elasticsearch.yml« , sie heißen »network.bind_host« und »network.host« .

Verschiffen …

Damit geht es an die Konfiguration von Logstash selbst. Wichtig ist, dass Logstash nicht in Form einzelner Java-Bibliotheken für Client und Server kommt, sondern als große Datei für alle Dienste. Welche Aufgaben eine Logstash-Instanz erfüllt, hängt letztlich nur vom Inhalt der Datei ab, die das Tool als Quelle für ihre Konfiguration nutzt. Nach dem Download der Logstash-Jar-Datei von [5] – zu Redaktionsschluss war 1.1.9 die aktuelle Version – gilt es also lediglich, die richtigen Parameter zu wählen.

Für einen Shipper könnte eine »shipper.conf« aussehen wie in Listing 1. Mit dieser Konfiguration würde Logstash die Meldungen der Syslog-Files und auch die von Apache in der »Default« -Virtual-Domain an den Indexer schicken. Der Host mit dem Indexer ist im Beispiel 192.168.122.165.

01 input {
02  file {
03    type => "syslog"
04
05    # Wildcards work here :)
06    path => [ "/var/log/messages", "/var/log/07 syslog", "/var/log/*.log" ]
08  }
09  file {
10    type => "apache-access"
11    path => "/var/log/apache2/access.log"
12  }
13
14  file {
15    type => "apache-error"
16    path => "/var/log/apache2/error.log"
17  }
18 }
19
20 output {
21  stdout { debug => true debug_format => "json"}
22  redis { host => "192.168.122.165" data_type => 23 "list" key => "logstash" }
24 }

Etwas verwirrend wirkt hier möglicherweise das Wort »key« , denn es bezieht sich nicht auf einen für Authentifizierungszwecke angelegten Schlüssel, sondern lediglich auf den Wert, den Redis als Namen für die Logstash-Queue verwendet. Mit dieser Konfigurationsdatei lässt sich Logstash bereits starten, dafür sorgt der Befehl »java -jar logstash-1.1.9-monolithic.jar agent -f shipper.conf« .

… indizieren …

Nicht komplizierter gestaltet sich das Setup des Indexers. Ebenso wie der Shipper braucht auch der Indexer nur eine passende Konfiguration, Listing 2 enthält ein Beispiel. Die Konfiguration von Logstash unterteilt sich also jeweils in »input« – und »output« -Blöcke, die – nomen est omen – festlegen, woher der jeweilige Dienst seine Nachrichten bezieht und wohin er sie weiterleitet.

01 input {
02  redis {
03    host => "192.168.122.165"
04    type => "redis-input"
05    data_type => "list"
06    key => "logstash"
07    format => "json_event"
08 }
09 }
10 output {
11 elasticsearch {
12    host => "192.168.122.165"
13 }
14 }

Der Indexer beginnt sein Tagwerk im Anschluss mit dem Befehl »java -jar logstash-1.1.9-monolithic.jar agent -f indexer.conf« . Im Gegensatz zum Shipper produziert der Indexer übrigens praktisch keinen eigenen Output auf dem Standardausgabekanal. Wenn dort also Ruhe herrscht, ist das für den Admin noch lange kein Grund zur Sorge.

… und servieren

Schließlich fehlt noch der eigentliche Logstash-Webserver, der überhaupt keine eigene Konfigurationsdatei braucht. So lässt er sich starten:

java -jar logstash-1.1.9-monolithic.jar web --backend elasticsearch://192.168.122.165/

Unmittelbar im Anschluss steht dem Admin bereits der Login am Logstash-System auf Port 9292 zur Verfügung (Abbildung 2), im Beispiel wäre die gesamte Adresse also »http://192.168.122.165:9292« . Direkt nach dem ersten Start sollten bereits Logmeldungen zu sehen sein (Abbildung 3), alternativ lässt sich der Ablauf übers Suchfeld sicherstellen. Im Grunde sind damit die wesentlichen Schritte der Logstash-Installation abgeschlossen.

Abbildung 2: Die Suche nach »NetworkManager« in den Logstash-Aufzeichnungen ruft zeitlich sortierte Meldungen auf den Bildschirm.

Abbildung 3: Die Status-Updates des Shippers von Logstash verraten, was die Software tut: Sie verschickt eintreffende Logmeldungen an Redis.

Selbstverständlich steht es den Sysops frei, das Setup nach ihrer eigenen Façon zu verschönern: Typischerweise soll beispielsweise der Logstash-Shipper auf jedem System beim Start automatisch laufen, sodass das Anlegen eines entsprechenden Init-Skripts notwendig ist. (Wer sich die Arbeit nicht machen möchte, findet im Netz aber auch fertige Skripte dieser Art.)

Außerdem empfiehlt es sich, anwendungsspezifische Filter anzulegen, um alle Möglichkeiten der Lösung auszuschöpfen. Eine Übersicht über mögliche Filteroptionen in Logstash, die auch reguläre Ausdrücke unterstützen, findet sich samt ausführlicher Dokumentation auf der Anbieter-Website [6].

Logstash ist eine sehr elegante Lösung, um zentrales Logging zu erreichen. Dass sowohl Chef-Cookbooks wie auch Rezepte für Puppet schon zur Verfügung stehen, kommt insbesondere jenen Admins zugute, die größere Rechnerfarmen pflegen und deshalb mit einem zentralen Management für ihre Konfigurationsdateien arbeiten. Gerade in solchen Setups lässt sich Logstash nämlich sehr leicht nachrüsten.

Seine ganze Stärke spielt Logstash aber erst dann aus, wenn es um das Durchsuchen von Logs geht. Jeder Admin, der schon mal händisch in Zehntausenden Zeilen von Logfiles nach einem Fehler gesucht hat und dann zum ersten Mal eine Fehlersuche mit Logstash erlebt, hat ein echtes Aha-Erlebnis. Nur für Admin-Piloten mit ausgeprägter Java-Allergie ist und bleibt Logstash allerdings ein windiger Vogel.