6
Minimaler Syslogserver mit rsyslog
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:
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.
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.
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.
Die folgende Config basiert auf der Standard-Debian-Config:
Hier ist die Reiheinfolge der Einträge wichtig! Die wesentlichen Punkte sind folgende:
Zum Schluss startet man rsyslog neu und überprüft den Status.
Ein paar Hinweise:
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
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"
Je nach Situation sollte man natürlich folgendes nicht vergessen:
Grüße
lcer
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:
- Debian mit Loganalyzer: Installation eines Logservers mit Loganalyzer als Debian-VM auf Hyper-V
- Debian mit Logstash und Elasticsearch/Kibana
- Windows mit Fastvue Syslog monitoring with PRTG and Fastvue
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.
Inhaltsverzeichnis
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.
Konfiguration
Vorbereitungen
Zunächst müssen einige Verzeichnisse erstellt werden:
mkdir /var/spool/rsyslog/in514tcp
mkdir /var/spool/rsyslog/in514udp
mkdir /var/log/logcentral
touch /etc/rsyslog.d/100_template_010_DYNAMICLOGFILE.conf
touch /etc/rsyslog.d/500_ruleset_010_incoming.confDie 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.
Templates erstellen
nano /etc/rsyslog.d/100_template_010_DYNAMICLOGFILE.confReinerscript 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
template (name="DYNAMICLOGFILE" type="string" string="/var/log/logcentral/%fromhost-ip%-%hostname%/default.log")
template (name="DYNAMICLOGFILEPRI" type="string" string="/var/log/logcentral/%fromhost-ip%-%hostname%/%syslogpriority-text%.log") 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.
Rulesets erstellen
nano /etc/rsyslog.d/500_ruleset_010_incoming.confDie 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.
ruleset(name="incomingtcp"
queue.filename="incomingtcp"
queue.spoolDirectory="/var/spool/rsyslog/in514tcp"
queue.type="linkedlist"
queue.size="100000"
queue.saveOnShutdown="on"
queue.syncqueuefiles="on"
){
*.warn ?DYNAMICLOGFILEPRI
*.* ?DYNAMICLOGFILE
stop
}
ruleset(name="incomingudp"
# queue.filename="incomingudp"
# queue.spoolDirectory="/var/spool/rsyslog/in514udp"
# queue.type="linkedlist"
# queue.size="100000"
# queue.saveOnShutdown="on"
# queue.syncqueuefiles="on"
){
*.warn ?DYNAMICLOGFILEPRI
*.* ?DYNAMICLOGFILE
stop
}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.
Letzte Anpassungen an der rsyslog.conf
Die folgende Config basiert auf der Standard-Debian-Config:
# /etc/rsyslog.conf configuration file for rsyslog
#
# For more information install rsyslog-doc and see
# /usr/share/doc/rsyslog-doc/html/configuration/index.html
#################
#### MODULES ####
#################
module(load="imuxsock") # provides support for local system logging
module(load="imklog") # provides kernel logging support
#module(load="immark") # provides --MARK-- message capability
# provides UDP syslog reception
module(load="imudp")
#input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
#input(type="imtcp" port="514")
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
################
#### INPUTS ####
################
input(type="imtcp" port="514" ruleset="incomingtcp")
input(type="imudp" port="514" ruleset="incomingudp")
###############
#### RULES ####
###############
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Some "catch-all" log files.
#
*.=debug;\
auth,authpriv.none;\
mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail.none -/var/log/messages
#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*Hier ist die Reiheinfolge der Einträge wichtig! Die wesentlichen Punkte sind folgende:
# provides UDP syslog reception
module(load="imudp")
#input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
#input(type="imtcp" port="514")
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
################
#### INPUTS ####
################
input(type="imtcp" port="514" ruleset="incomingtcp")
input(type="imudp" port="514" ruleset="incomingudp")
###############
#### RULES ####
###############- 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.
service rsyslog restart
service rsyslog statusTroubleshooting
Ein paar Hinweise:
- Die Fehlermeldungen schreibt rsyslog ins das syslog. Dort sollte man nachschauen, wenn es probleme gibt. z.B. tail /etc/rsyslog
- 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)
Wie weiter?
logrotate 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
...
/var/log/messages
/var/log/logcentral/**/*.log
{
rotate 4
weekly
...Nutzung
Wie nutze ich das? Na ganz einfach - die entsprechende Logdatei wird von der Console aus angezeigt:
tail -n100 /var/log/logcentral/192.168.0.1-Router/default.logtail -n100 -f /var/log/logcentral/192.168.0.1-Router/default.log... und alle weiteren folgenden, quasi "Live"
was noch fehlt...
Je nach Situation sollte man natürlich folgendes nicht vergessen:
- ssh-Zugriff absichern
- firewall aktivieren
- Datensicherung einrichten.
Grüße
lcer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1739455565
Url: https://administrator.de/contentid/1739455565
Ausgedruckt am: 21.11.2024 um 06:11 Uhr
6 Kommentare
Neuester Kommentar
Danke für die Anleitung!
Kennst Du den hier schon:
https://sourceforge.net/projects/syslogserverwindows/
Den verwende ich recht gerne.
VG
bdmvg
Kennst Du den hier schon:
https://sourceforge.net/projects/syslogserverwindows/
Den verwende ich recht gerne.
VG
bdmvg
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.
Grüße vom it-frosch
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.
Grüße vom it-frosch
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
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
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.
Man kann übrigens Rsyslog auch in eine Datenbank loggen lassen, und dann per Webinterface (Loganalyzer) darauf zugreifen.
...wie im hiesigen beschrieben. 😉
2
Zitat von @Gentooist:
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.
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.
Was dann aber wieder mehr Schwachstellen hat - denn der DB-Server kann ja dann auch wieder crashen...
Ich würde hier mal ganz simpel anfangen:
a) Überlegen WAS überhaupt geloggt werden soll (wie beim Monitoring auch kommt man oft in die Versuchung jeden Furz zu überwachen - und am Ende soviel Daten zu haben das keiner mehr drauf guckt...)
b) WER soll das Prüfen? Egal wo die Logs nun liegen. Egal ob man die Auswertung auf der Konsole macht (ich nutze zB. einfach die Logfiles weil ich da schnell mit nem "cat /var/log/syslog | grep -i "error" " drübergehen kann... ) oder ob man da graphische Tools für nimmt,... Am Ende läuft es ja oft drauf raus das man dann irgendwo das super logging hat aber keiner reinguckt bzw. erst dann jemand reinguckt wenn irgendwas schon im Eimer ist... Auch hier der Vergleich zum Monitoring: Da wird ja auch gerne dann eingestellt das jeder Furz per Email rausgeht - was dann nach 1-2 Tagen bedeutet das sich die Empfänger ne Regel ins Postfach werfen das alles vom Monitoring in irgendeinen Unterordner wandert.
c) Wer betreut den LOG-Server? Auch da: Schön wenn die Kiste irgendwo in der Ecke steht.. Hier kann man sich z.B. auch nen einfaches Synology-NAS mit wenigen Klicks dafür aufbauen. Hilft nur nix wenn die Kiste irgendwann absemmelt, vollläuft oder sonstwas damit ist (der Praktikant hats geklaut ;) ) und es keiner merkt. Insbesondere bei ner VM muss man noch überlegen: Was passiert denn wenn der HOST sich da mit nem Problem meldet? (Ich mache zB. auch das Logging von Switches auf den Syslog... is aber natürlich nur solang hilfreich wie das Netzwerk soweit steht das die Log-Maschine erreicht werden kann... )
Wenn das alles geklärt ist dann kann man sich den rsyslog gut aufbauen (wobei ich meine man musste da gar nich soviel machen - habe mir das aber einfach in nen Ansible-Script gekippt, daher weiss ich nicht genau was da alles gemacht wird :D Einmal ins Script und raus ausm Hirn halt...).
1
