Der Klassiker: syslog -> logstash

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.logstash_01
Gegenüber Lösungen wie logstash ergeben sich bei Syslog vor allem 3 Probleme:

  1. 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.
  2. 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.
  3. 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.schulung_logstash
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.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Weekly Snap: Async.js & Impress.js, Rsyslog & OSDC Cfp

weekly snap28 October – 1 November began a new month with a new conference to look forward to and tips for logs and JavaScript.
Just as we were beginning to recover from the OSMC, Eva kick started preparations for the Open Source Data Center Conference with a Call for Papers and early bird specials.
In the meantime, Matthias played with simple, asynchronous queries in JavaScript with Async.js and Achim showed how to build buffers into logs with rsyslog as Christoph discovered impress.js.

Logs puffern mit rsyslog

Wie wichtig Logdateien sind weiß jeder Administrator und mit Logstash, Graylog und Elasticsearch hat das Thema auch einen kleinen Hype im Open Source Umfeld erfahren. Zur bequemen Analyse der Logs werden diese meist zentral auf einem Logserver gesammelt. Ein typisches Setup wäre z.B. Logstash mit Elasticsearch auf dem Logserver und rsyslog auf den Clients. Warum rsyslog? Es ist mittlerweile der Standard auf den bekannten Linux Distributionen und zudem schlank und zuverlässig. Natürlich macht es Sinn auf Seiten des Logservers Puffer einzubauen (z.B. mit Redis), aber ich will einen genaueren Blick auf die rsyslog-Konfiguration werfen.
Neben einer verschlüsselten Kommunikation erwarte ich von einem Log-Daemon Folgendes:

  • Puffern der Logs, falls der Logserver nicht erreichbar ist.
  • Andere Prozesse dürfen nicht beeinträchtigt oder blockiert werden, wenn der Logserver nicht verfügbar ist.
  • Der Log-Daemon sollte das System auch in extremen Fällen nicht vollschreiben.
  • Logs sollten in einem brauchbarem Format gesendet werden.

Kein Problem:

$WorkDirectory /var/spool/rsyslog
$template ForwardFormat,"<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
$ActionQueueType LinkedList
$ActionQueueFileName logbuffer
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
$ActionQueueMaxDiskSpace 200M
$ActionQueueDiscardSeverity 3
$ActionQueueTimeoutEnqueue 5
*.* @@logserver.example.com:4321;ForwardFormat

Ein brauchbares Format wird durch Zeile 2 und 10 erreicht. Vor allem der Timestamp nach RFC3339 ist nützlich. Zeile 2 definiert in dem Template ForwardFormat wie die Logs aussehen sollen und Zeile 10 sendet diese, entsprechend dem Template, per TCP (@@, wie intuitiv) an den Logserver.
Für das Puffern der Logs sind die Zeilen 3-5 zuständig. Als Datentyp soll eine verkettete Liste verwendet werden. Diese hat vor allem den Vorteil, dass nur so viel Speicher wie nötig belegt wird. Ab 8000 Logs im Speicher werden diese auf Platte in die Datei logbuffer gesynct ($ActionQueueHighWaterMark [1,2]). Zeile 7 sorgt dafür, dass maximal 200 MB Logs auf Platte in den Puffer wandern. Weitere Logs (die entweder keinen Platz mehr haben oder zu lange zum Annehmen brauchen) werden dank Zeile 9 verworfen und zwar nach 5 ms. Dies sorgt dafür, dass keine Prozesse blockieren, die versuchen Logs zu schreiben, aber keinen Platz mehr im Puffer kriegen. Zeile 8 bewirkt, dass bei vollen Puffern eher wichtige Logs (Severity 0-2) als unwichtige gepuffert werden. Temporäre Puffer werden auf Grund von Zeile 1 nach /var/spool/rsyslog geschrieben. Die Zeilen 3-9 werden auf die nächste Action angewendet, in diesem Fall Zeile 10.
Mit diesem Setup können Logs immer noch verloren gehen. Allerdings wird es im normalen Zustand wohl kaum passieren, dass der Puffer auf Platte benötigt wird. Sollte es wirklich zu Verbindungsabbrüchen kommen, können hier immer noch 200 MB gepuffert werden und ggf. kann der Wert noch angepasst werden. Mit diesem Setup entscheidet man sich auch für das Verwerfen von Logs, sobald der Puffer voll ist. Dies gewährleistet allerdings, dass andere Systemdienste (wie z.B. sshd) ohne Probleme weiter benutzbar bleiben.
Das Queueing Modell von rsyslog ist nicht so simpel wie oben dargestellt. Eine ausführlichere Beschreibung gibt es in der Dokumentation von rsyslog selbst [1,2].
Anmerkung:
Das oben verwendete Format der rsyslog-Konfiguration wird ab Version 6.3.3 als Legacy Format bezeichnet. In den aktuellen Versionen der bekannten Distributionen wird Version 5.x verwendet.
[1] http://www.rsyslog.com/doc/queues.html
[2] http://www.rsyslog.com/doc/rsyslog_conf_global.html

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.