📋 · System-Aufzeichnungen

Logs: Die Zeitzeugen deiner Systeme

Logs sind die erste Anlaufstelle wenn etwas schiefläuft – und eine wertvolle Datenquelle wenn man versteht wie man sie strukturiert, sammelt und durchsucht. Gutes Logging ist der Unterschied zwischen Raten und Wissen.

journalctlLokistructured logsRotationPromtail

Wo Logs auf Linux leben – und wie man sie liest

Linux-Logs haben mehrere Heimaten:

systemd Journal: Der zentrale Log-Speicher für systemd-Services. journalctl -u nginx -f für Live-Logs, journalctl --since "1 hour ago" für Zeiträume, journalctl -p err für Fehler.
/var/log/: Klassische Textdateien – syslog, auth.log, kern.log. Mit tail -f oder grep durchsuchen.
Docker Logs: docker compose logs -f servicename. Container schreiben nach stdout/stderr, Docker leitet in JSON-Dateien unter /var/lib/docker/containers/.
Anwendungslogs: Jede App nach eigenem Schema – JSON ist deutlich besser als Freitext für maschinelle Verarbeitung.

# Praktische Log-Befehle
journalctl -u nginx --since today # Heutige Nginx-Logs
journalctl -p err -n 50            # Letzte 50 Fehler
docker compose logs --tail=100 app # Letzte 100 Zeilen
grep -i "error" /var/log/syslog | tail -20

Strukturiertes Logging: JSON statt Freitext

Freitext-Logs sind für Menschen lesbar aber schwer maschinell zu verarbeiten. Strukturierte Logs lösen das:

JSON-Format: Jede Log-Zeile als JSON-Objekt mit konsistenten Feldern: {"level": "error", "msg": "...", "timestamp": "...", "request_id": "..."}
Pflichtfelder: Timestamp (ISO 8601), Level (debug/info/warn/error), Message, Service-Name. Optional: Request-ID für Trace-Verfolgung über mehrere Services
Python: `structlog` Library für strukturierte Logs. FastAPI und Django haben eingebaut JSON-Logging-Optionen.
Docker JSON-Logging: "logging": {"driver": "json-file", "options": {"max-size": "10m", "max-file": "3"}} in compose.yml – begrenzt Disk-Verbrauch

Log-Aggregation mit Loki und Promtail

Auf einem einzelnen Server reicht journalctl. Für mehrere Services oder Server braucht man zentrale Log-Aggregation:

Promtail: Log-Shipper von Grafana – liest Docker-Logs und Journal, schickt sie an Loki. Läuft als Container auf jedem Host.
Loki: Speichert Logs mit Labels – suche nach {container="n8n"} |= "error" in Grafana. Kein Index der Log-Inhalte – günstiger als Elasticsearch.
Grafana: Logs und Metriken nebeneinander explorieren – Fehler-Spike in Prometheus korrelieren mit den zugehörigen Log-Einträgen in Loki
Alerting auf Logs: Grafana-Alerts auf Log-Pattern – „wenn mehr als 10 ERROR-Zeilen in 5 Minuten → Telegram-Benachrichtigung"

Zusammen mit Prometheus und Grafana entsteht ein vollständiges Observability-Setup.

Häufige Fragen zu Logs

Wie verhindere ich dass Logs die Festplatte füllen?

Systemd-Journal: in `/etc/systemd/journald.conf` `SystemMaxUse=500M` setzen. Docker: in compose.yml Logging-Options mit max-size und max-file. Nginx/Apache: logrotate konfiguriert automatisch tägliche Rotation und hält eine Woche vor. `df -h /var/log` regelmäßig prüfen.

Wie finde ich in Logs den Fehler der vor einem Crash passiert ist?

Systemd: `journalctl -b -1` zeigt Logs des letzten Boots (vor dem Crash). Mit `-p err` auf Fehler einschränken. Docker: `docker inspect container_name` zeigt Exit-Code. Danach `docker logs container_name 2>&1 | tail -50` für letzte Ausgaben vor dem Stop.

Loki vs. Elasticsearch für Log-Aggregation?

Loki für Self-Hosting: günstiger (kein Index), einfacher zu betreiben, gut integriert mit Grafana. Elasticsearch für: Volltext-Suche in Log-Inhalten, komplexe Analysen, wenn schon ELK-Stack vorhanden. Für die meisten Heimserver-Projekte ist Loki deutlich die bessere Wahl.

Wie lange soll ich Logs aufbewahren?

Für Debugging: 7–30 Tage reichen für die meisten Fälle. Security-Logs (Auth, SSH-Zugriffe): 90 Tage empfohlen, bei DSGVO-relevanten Systemen rechtliche Anforderungen prüfen. In Loki: per Stream-Retention-Policy unterschiedliche Aufbewahrung für verschiedene Log-Typen konfigurierbar.