Bevor es an den Aufbau neuer Features mit logstash geht, soll erst mal der übliche Vorläufer von logstash in Netzwerken ersetzt werden: Der gute alte Syslog Server.
Zu Syslog finden sich weiterführende Informationen in der Wikipedia, deshalb hier nur kurz umrissen: Syslog ist sowohl ein Protokoll, als auch der Name eines Tools, das dieses Protokoll benutzt, um Logs innerhalb eines Systems von Applikationen einzusammeln und in Logfiles zu schreiben und sie auch übers Netzwerk an andere Hosts zu schicken. Diese anderen Hosts sind normalerweise die eingangs erwähnten Syslog Server, die einfach mal alles an Logs sammeln, was ihnen präsentiert wird und in lokale Logfiles schreiben.
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:
- Die Lösung skaliert nicht. Wenn ein Server nicht mehr mit dem Annehmen und Wegschreiben von Logs mitkommt, kann man ihn höchstens durch stärkere Hardware ersetzen. Irgendwann ist da aber Schluss.
- Die Logs liegen genau so am Syslog Server wie auf stand-alone Hosts auch. Also unstrukturiert. Durchsuchen und Auswerten verlangt normalerweise einiges an grep/awk oder Perl und Regex magic.
- Die Übertragung passiert normalerweise unverschlüsselt über UDP. Beides will man normalerweise nicht für kritische Logs. (Auch wenn Ableger wie rsyslog und syslog-ng da teilweise Abhilfe schaffen)
Punkt 1 und 2 kriegt man mit logstash sehr einfach in den Griff. Man kann mit logstash einen Syslog Server bauen, der Logs sowohl im klassischen Syslog Format vom syslog Tool, als auch von neueren Tools wie rsyslog, die auch über TCP und teilweise sogar verschlüsselt senden können, annehmen kann.
input {
syslog {
type => "syslog"
port => 514
}
}
Aus. Das war’s. Mehr ist nicht nötig und das ist sogar schon etwas mehr, als nötig ist. Der Port ist auch ohne Angabe auf dem Syslog Standard von 514, allerdings sowohl TCP, als auch UDP. Der type ist übrigens frei wählbar und wird nur später benutzt, um den Weg der Nachricht durch logstash zu planen. Er hat nichts damit zu tun, dass Daten im Syslog Format erwartet werden. Weitere Informationen zu den möglichen Optionen des Syslog Input gibt’s in der logstash Dokumentation.
Nochmal zusammengefasst reicht es, dem Quickstart aus dem ersten Beitrag dieser Serie zu folgen und den syslog Teil des obigen Beispiels zum input hinzuzufügen. Jetzt noch die IP Adresse des bisherigen Syslog Servers auf den logstash Server verschieben und fertig.
Zugegeben, natürlich war das Quickstart Beispiel nicht für eine Produktivumgebung gedacht. Dazu fehlt zumindest noch Ausfallsicherheit und die Meldungen werden immer noch ziemlich unstrukturiert abgelegt. Die zum Aufbereiten nötigen Filter können aber ebenso nach und nach hinzugefügt werden. Ziel dieses Artikels war ja, den Syslog Server zu ersetzen und auf weitere Verbesserungen vorzubereiten.
Was mehr Aufwand benötigt ist die gesicherte Übertragung der Syslog Nachrichten an den logstash Server. Mit syslog ist das sowieso nicht möglich. Mit rsyslog Sind aber auf jeden Fall Änderungen an der Konfiguration jedes sendenden Host nötig.
Wer das Beispiel einfach mal ausprobieren möchte und bisher keinen zentralen Syslog Server hatte, kann mit folgenden kurzen Codebeispielen andere Server zum Versand bringen.
syslog:
*.* @192.168.200.2
Wobei 192.168.200.2 hier die IP Adresse des logstash Servers ist. Der Eintrag ist eine Zeile aus /etc/syslog.conf auf den meisten Systemen. Danach muss syslog neu gestartet werden. Mit service syslog restart auf gängigen Linux Distributionen, sofern sie überhaupt noch syslog einsetzen und mit svcadm disable system-log ; svcadm enable system-log auf Solaris.
rsyslog:
*.* @@192.168.200.2:514
Wobei die doppelten @ dafür sorgen, dass die Übertragung über TCP stattfindet. Diese Zeile kann in eine eigene Datei in /etc/rsyslog.d gelegt werden.
Es soll natürlich hier nicht verheimlicht werden, dass logstash auch eigene Möglichkeiten mitbringt, die Daten auf dem Host einzusammeln und an einen zentralen logstash Server zu schicken. Wie das geht, ist Inhalt eines späteren Artikels oder unserer logstash Schulungen.
28 October – 1 November began a new month with a new conference to look forward to and tips for logs and JavaScript.
