lcer00
Goto Top

Minimaler Syslogserver mit rsyslog

article-picture
Hallo,

auf der Suche nach einer praktikablen SYSLOG-Server Lösung für unsere nicht-Windows-Systeme geht es jetzt "back to the roots". Zwischenzeitlich hatte ich verschiedene Lösungen ausprobiert:


Aus verschiendenen Gründen hat alles nicht so richtig gepasst. Beispielsweise ist der Wartungsaufwand für Elasticsearch & Kibana insbesondere bei Major-Versionsänderungen enorm. Fastvue ist schick, aber leider kaum konfigurierbar, die Weboberfläche hat kein https ...

Jetzt habe ich mir mal wieder ein ganz minimales System auf Debian Basis gebastelt. Das Schöne ist - nach der Grundinstallation von Debian (netinstall-Image, keine graphische Installation, nur Standartsystemwerkzeuge) mit muss man kein einziges zusätzliches Paket installieren.

Das System bietet natürlich keine Auswertung der Syslogs. Das muss man dann anders lösen. Es ist dafür aber wesentlich ressourcenschonender und einfacher zu realisiseren als beispielsweise Elastic-Stack.


Debian verwendet rsyslog für die Protokollierung. Das bringt schon alles erforderliche mit. Die Dokumentation zu rsyslog ist auf den ersteb Blick linuxtypisch etwas unzugänglich. Die Dokumente findet man unter https://rsyslog.readthedocs.io/en/latest/

Rsyslog enthält eine sehr flexible Skriptsprache (Rainerscript https://rsyslog.readthedocs.io/en/latest/rainerscript/index.html ), mit der sich differenzierte Kontrollstrukturen programmieren lassen. (https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ...) ). So ist eine ganze Menge Log-Verarbeitung mit Bordmitteln möglicht. Die meisten im Internet auffindbaren Beispiele zu rsyslog verwenden jedoch hauptsächlich Legacy-Formate - auch die Standard-Debian-Configurationsdatei. Das Verwenden von Rainerscript ist jedoch deutlich leistungsfähiger.

In diesem Tutorial zeige ich, wie man:

  • rsyslog zum empfangen von Syslog-nachrichten verwendet
  • Die Protokolle separat in dynamisch erzeugten Protokolldateien speichert.

back-to-topKonfiguration


back-to-topVorbereitungen

Zunächst müssen einige Verzeichnisse erstellt werden:


Die ersten beiden sind Spoolverzeichnisse für die eingehenden Nachrichten (siehe unten). Im dritten Verzeichnis sollen die Logdateien abgelegt werden. Die zusätzlichen Konfigurationsdateien enthalten Templates und Rulesets.
Deren Benennung ist eigentlich egal da die Konfigurationsdateien später per Platzhalter eingebunden werden.
Der Einlesereihenfolge wegen empfiehlt sich hier jedoch das voranstellen von Ziffern, so dass später gezielt erweitert werden kann.

back-to-topTemplates erstellen


Reinerscript ermöglicht die Verwendung von Templates: https://rsyslog.readthedocs.io/en/latest/configuration/templates.html https://www.rsyslog.com/how-to-bind-a-template/ In diesem Beispiel werden Templates vom Typ "string" benötigt.
Im Verzeichnis erstellt man eine Datei


Die Notation erfolgt im "neuen" Format. Siehe Infos unter https://rsyslog.readthedocs.io/en/latest/configuration/templates.html#le ...
Ist ist möglich, beliebige Eigenschaften, auch mehrere nacheinander, zu verwenden. Die später resultierenden Pfade erstellt rsyslog dann automatisch. Die Möglichen Eigenschaften kann man hier finden: https://rsyslog.readthedocs.io/en/latest/configuration/properties.html

Ich habe hier die Kombination aus fromhost-ip und hostname verwendet. IP ist immer eindeutig - der Hostname nicht unbedingt. Manchmal ist der Hostname auch sehr seltsam belegt (bei meinen Bintec-Router steht da unabhängig vom eingestellten Hostname des Routers immer den auf 3 Zeichen gekürzten englischen Wochentag !!!). Man kann das aber anpassen: https://rsyslog.readthedocs.io/en/latest/configuration/property_replacer ... machts möglich.

back-to-topRulesets erstellen


Die Rulsets sind Regelsets für die eingehenden Nachrichten. Hier kann man allerhand machen. Ich verwende hier zwar das Legacy-Format für die Aktion ( *.warn ), aber es sind auch umfangreiche Controllstrukturen möglich: https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ... . Das "stop" am Ende sorgt dafür, dass keine weiteren Regeln auf die Nachricht angewendet werden. Läßt man das weg, landen die Nachrichten zusätzlich da, wo die /etc/rsyslog.conf sie hinsortiert - z.B. im syslog.


Ich habe hier eingehende Rulesets für TCP und UDP Transport erstellt. Das ist normalerweise nicht erforderlich. Ein Rulset würde genügen. Ausserdem erfolgt der syslog Transport typischerweise über UDP. Wer aber möglicherweise besonder wichtige Syslogsender per TCP transportieren lassen will, damit keine Pakete auf dem Weg zum Syslogserver untergehen, kann hier gleich noch separate Regeln hinzufügen.

Anmerkung zum Queue: Die Dokumentation findet sich unter https://rsyslog.readthedocs.io/en/latest/rainerscript/queue_parameters.h ... Im Beispiel werden die eingehenden Nachrichten zuerst einein Spool-Verzeichnis geschrieben, und dann abgearbeitet. Da die Nachrichten lediglich in lokalen Logfiles gespeichert werden sollen, ist dies ein Festplattenbasierter Queue eigentlich nicht erforderlich. Will man die Nachrichten dann aber ggf. an andere Logserver weiterleiten, bietet sich ein festplattenbasierter Queue an, da so das Risiko reduiert wird, beim Absturz oder Herunterfahren des Rechner Nachrichten, die noch im RAM liegen, zu verlieren. Ich habe den Queue jedenfalls mit in die Konfiguration aufgenommen, da die Config dann auch für etwaige Erweiterungen taugt.

back-to-topLetzte Anpassungen an der rsyslog.conf

Die folgende Config basiert auf der Standard-Debian-Config:


Hier ist die Reiheinfolge der Einträge wichtig! Die wesentlichen Punkte sind folgende:


  • Die UDP und TCP Module müssen geladen werden. Dazu entfernt man einfach die Kommentier-Raute.
  • Die dazugehörigen input-Statements bleiben auskommentiert. Zuerst müssen die Dateien aus /etc/rsyslog.d geladen werden!
  • Erst nach $IncludeConfig werden die Rulesets an das Input-Modul gebunden.
  • Erst danach kommen die Regeln der standard-Konfiguration.

Zum Schluss startet man rsyslog neu und überprüft den Status.


back-to-topTroubleshooting

Ein paar Hinweise:

  • Die Fehlermeldungen schreibt rsyslog ins das syslog. Dort sollte man nachschauen, wenn es probleme gibt. z.B. tail /etc/rsyslog face-smile
  • Eingehende Nachrichten werden nicht immer sofort verarbeitet und in die Logdatei geschrieben. Zunächst sollte man warten, ob die Logdatei bzw. Einträge nicht doch noch 1 Minute später erstellt werden.
  • Der Code eines Rulesets wird zur Laufzeit interpretiert. Daher ist bei Fehlern im Rulset-Code der Start von rsyslog möglicherweise erfolgreich, der Prozess stürzt aber ab, sobald ein engehendes Paket dem Ruleset zugewiesen wird. Daher lohnt es sich zu püfen, ob rsyslog nach 20 Minuten immer noch läuft (service rsyslog status)

back-to-topWie weiter?


back-to-toplogrotate Einrichten

Es macht Sinn, Speicherplatzsparend zu arbeiten und daher sollte man logrotate für die Logdateien aktivieren. Dier die ergänzte Debian Standart-Config aus /etc/logrotate.d/rsyslog


back-to-topNutzung

Wie nutze ich das? Na ganz einfach - die entsprechende Logdatei wird von der Console aus angezeigt:
... zeigt die letzten 100 Zeilen an.


... und alle weiteren folgenden, quasi "Live"

back-to-topwas noch fehlt...

Je nach Situation sollte man natürlich folgendes nicht vergessen:

  • ssh-Zugriff absichern
  • firewall aktivieren
  • Datensicherung einrichten.

Grüße
lcer

Content-Key: 1739455565

Url: https://administrator.de/contentid/1739455565

Ausgedruckt am: 24.09.2022 um 20:09 Uhr

Mitglied: beidermachtvongreyscull
beidermachtvongreyscull 19.01.2022 um 13:28:50 Uhr
Goto Top
Danke für die Anleitung!

Kennst Du den hier schon:
https://sourceforge.net/projects/syslogserverwindows/

Den verwende ich recht gerne.

VG
bdmvg
Mitglied: it-frosch
it-frosch 03.02.2022 um 17:56:48 Uhr
Goto Top
Hallo Icer,

danke dir. Ich hatte für unsere Server auch mal einen Syslogserver (allerdings mit gebaut hatte aber dann immer wieder Probleme auf Grund der anfallenden Datenmengen die von den anderen Servern kamen.

Welche Ideen hast du für die Auswertung?
Momentan sammelst du du ja alle Logs nur auf dem Server. face-wink

Grüße vom it-frosch
Mitglied: lcer00
lcer00 03.02.2022 um 21:51:20 Uhr
Goto Top
Hallo,

momentan benutze ich die Config als Dstensammelmaschine. Da kann kann ich hinterher schauen, wenn es Probleme gab. Oder man kann in Debugszenarien live zusehen, was passiert (tail -f).

Im einfachsten Fall könnte man alle Meldungen > Warnung in eine separate Datei Schreiben und deren Größe Monitoren, um dann zu schauen, was es gibt.

Gutes logfile-Monitoring ist nochmal eine ganz andere Nummer. Das fängt damit an, die richtigen Fragen zu stellen. Welche Logeinträge sind da relevant? Gibt es Schwellenwerte, wenn ja, wie hoch ist die Schwelle? Schau Dir z.B. die fail2ban Config an. Wie optimierst Du da die Parameter, um die Bösen Jungs auszusperren ohne den Regelbetrieb zu stark zu stören? Meine Cisco-Switches melden z.B. mit hohem Schweregrad, wenn ein Port keinen Link mehr hat. Die Info ist aber zumindest zum Feierabend recht sinnlos - natürlich werden die DesktopPCs da abgeschaltet.

Wenn Du wirklich proaktiv die Logfiles zum Erkennen von Fehlentwicklungen nutzen willst, sollte man nicht selbst basteln. Da würde ich über so etwas wie Elastic Stack gehen. Mittels logstash kann man detailliert die Daten Vorverarbeiten und Kibana kann das Visualisieren, mittlerweile sogar mit irgendwelchen KI-Algorithmen. Aber dazu muss man entweder viel Zeit einplanen oder besser noch, einen Mitarbeiter einstellen - oder backen.

Nach ja, ein wenig geht schon. Schau Dir mal die Output-Module von Rsyslog an. https://rsyslog.readthedocs.io/en/latest/configuration/modules/idx_outpu ...

Mail, Pipe oder SNMP-Trap wären Möglichkeiten, eine Benachrichtigung auszulösen. Kontrollstrukturen werden ja ordentlich unterstützt. https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ...

Grüße

lcer
Mitglied: Gentooist
Gentooist 09.09.2022 um 20:39:05 Uhr
Goto Top
Ja das ist in der Tat schon recht minimal, wobei rsyslog wiederum nicht der minimalste Logging Daemon ist. Es gibt noch Metalog, Syslog-NG und den originalen sysklogd natürlich der sehr minimal ist.

Man kann übrigens Rsyslog auch in eine Datenbank loggen lassen, und dann per Webinterface (Loganalyzer) darauf zugreifen.
Mitglied: aqui
aqui 13.09.2022 um 19:02:21 Uhr
Goto Top
...wie im hiesigen RasPi Tutorial beschrieben. 😉