🌐 Auch auf: English · Français · Español
die Wahrheit. Sie sind laut, manchmal hässlich, aber absolut unverzichtbar, wenn etwas schiefgeht.Heute habe ich Graylog und Fluent Bit auf meinem Server installiert. Nicht nur,
weil ich beruflich mit diesen Tools arbeite, sondern auch, weil ich sie künftig immer öfter nutzen werde – schließlich ist mein Homelab zum
Experimentieren, Lernen und Beschäftigen meiner grauen Zellen da.
Warum Logging wichtig ist
Logging ist einer der grundlegendsten Bausteine zuverlässiger Systeme. Metriken sagen dir,
dass etwas nicht stimmt, Logs sagen dir, warum. Zentrales Logging wird entscheidend,
sobald du mehr als eine einzige Maschine betreibst.
Fluent Bit, Graylog & Sidecar
Fluent Bit ist die Client-Komponente auf dem Server. Seine Aufgabe ist simpel:
Logs lokal einsammeln und an Graylog schicken.
Graylog liefert GUI und Backend, in denen die Logs gespeichert, verarbeitet, durchsucht
und fürs Alerting genutzt werden. Damit lassen sich problemlos Log-Meldungen von mehreren tausend
Servern einsammeln und zentral auswerten.
Sidecar ist ein zusätzlicher Dienst, mit dem sich der
Fluent-Bit-Agent zentral direkt aus Graylog konfigurieren lässt – Rollouts und Änderungen werden dadurch deutlich bequemer.
Speicher-Tuning & erste Lessons Learned
Funktional lief alles ziemlich gut, aber ich musste den RAM-Bedarf deutlich
reduzieren. Interessanterweise hat sich Graylog sofort Swap geschnappt – obwohl der Server
insgesamt 32 GB RAM zur Verfügung hat.
Diese Java-typischen Speicherthemen sind für mich noch neu, da muss ich mich also
tiefer einarbeiten. Für den Anfang war ein Grafana-Dashboard extrem
hilfreich, um CPU- und RAM-Auslastung im Detail zu beobachten.
Um den Heap zu begrenzen, habe ich folgenden Eintrag in
/etc/graylog/datanode/datanode.conf ergänzt:
opensearch_heap = 2gBeispiel für eine Fluent-Bit-Konfiguration
Hier die aktuelle Fluent-Bit-Konfiguration, die auf meinem Ubuntu/Debian-System läuft. Sie sammelt Logs aus mehreren lokalen Quellen (systemd-Journal, Syslog, Auth-Logs und Kernel-Logs) und leitet alles über den GELF-Output per TCP an Graylog weiter.
Das Setup funktioniert gut fürs Homelab und ist trotzdem nah dran an dem, was du in Produktion betreiben würdest.
############################################
# Fluent Bit – Ubuntu / Debian
############################################
[SERVICE]
Flush 30
Daemon Off
Log_Level info
storage.type memory
###################################################################
# INPUTS
###################################################################
# Systemd Journal (primary input source)
[INPUT]
Name systemd
Tag journal.*
Read_From_Tail On
# /var/log/syslog
[INPUT]
Name tail
Path /var/log/syslog
Tag syslog.*
DB /var/log/fluent-bit/db_syslog.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
# Authentication Logs
[INPUT]
Name tail
Path /var/log/auth.log
Tag auth.*
# Kernel Log
[INPUT]
Name tail
Path /var/log/kern.log
Tag kernel.*
###################################################################
# OUTPUT
###################################################################
[OUTPUT]
Name gelf
Match *
Host 192.168.10.x
Port 12201
Mode udp
Gelf_Short_Message_Key log
Gelf_Host_Key host
Mit dieser Konfiguration schickt Fluent Bit zuverlässig alle relevanten System-Logs an Graylog,
wo sie indiziert, durchsucht und fürs Alerting genutzt werden können.
Fazit
Zentrales Logging ist ein mächtiges Werkzeug – auch (oder gerade) im Homelab. Es schärft das
Gespür für Produktivsysteme und macht die Fehlersuche deutlich weniger schmerzhaft, wenn irgendwann
doch etwas kaputtgeht.
