# Logging Best Practices: Informationen nutzbar machen

TL;DR / Management Summary Ein Logfile, das nur “Fehler aufgetreten” sagt, ist wertlos. In der professionellen IT-Infrastruktur nutzen wir strukturiertes Logging. Wir schreiben Nachrichten mit klaren Log-Leveln (INFO, WARN, ERROR), nutzen Zeitstempel nach ISO-8601 und bereiten Daten nach Möglichkeit im JSON-Format auf. Dies ermöglicht es modernen Tools (ELK, Loki, Artikel 045), Anomalien automatisch zu erkennen und Alarme auszulösen. Wer Logging beherrscht, reduziert die MTTR (Mean Time To Recovery) massiv.

# 1. Einführung & Architektur

Der Weg der Information.

Ein Log-Event sollte drei Fragen beantworten:

1. Wann ist es passiert? (Timestamp)
2. Wo ist es passiert? (Host, Service, PID)
3. Was ist passiert? (Message, Error Code)

# Die Logging-Pipeline (Mermaid)

graph LR
    A[Shell Script / App] -->|logger / stdout| B[Local Journald]
    B --> C[rsyslog / Forwarder]
    C -->|JSON via Network| D[Central Log Store: ELK / Graylog]
    D --> E[Visualization: Grafana]
    D --> F[Alerting: Alertmanager]

# 2. Strukturierte Logs: JSON ist King

Vom Text zum Datensatz.

Klassischer Text ist schwer zu parsen. JSON kann von jedem System direkt als Datenbank-Objekt gelesen werden.

# Beispiel: Bash-Logging Funktion für JSON

log_json() {
    local level="$1"
    local msg="$2"
    local timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
    
    printf '{"time": "%s", "level": "%s", "host": "%s", "msg": "%s"}\n' \
           "$timestamp" "$level" "$(hostname)" "$msg" | tee -a /var/log/myapp.json
}

# Nutzung
log_json "ERROR" "Database connection failed"

# 3. Log-Level: Die Spreu vom Weizen trennen

Relevanz definieren.

Nutzen Sie konsequent die Standard-Level:

• DEBUG: Nur für die Entwicklung (sehr gesprächig).
• INFO: Normale Betriebsereignisse (z.B. “Backup gestartet”).
• WARN: Anomalien, die kein sofortiges Handeln erfordern (z.B. “Disk 80% voll”).
• ERROR: Ein Dienst oder Task ist fehlgeschlagen (Eingreifen nötig!).
• CRITICAL: Systemweite Störung (Pager schlägt Alarm).

# 4. Day-2 Operations: System-Integration

Mit dem OS verschmelzen.

Nutzen Sie das Tool logger, um Ihre Skripte in das System-Journal einzubinden (Artikel 113).

# Tags und Priorities nutzen

# -t: Tag (Prozessname), -p: Priority (Facility.Level)
logger -t "BACKUP_JOB" -p user.err "CRITICAL: Backup disk not reachable!"

# 5. Troubleshooting & “War Stories”

Wenn das Loggen selbst zum Problem wird.

# Story 1: “Der Log-Spammer”

Symptom: Der Server hat keine Disk-I/O mehr frei, obwohl keine User darauf arbeiten. Ursache: Eine Applikation im DEBUG Modus schreibt hunderte MB pro Minute in eine Textdatei ohne Rotation. Lösung: Nutzen Sie immer logrotate. Setzen Sie den Default-Log-Level auf INFO. Schalten Sie DEBUG nur gezielt für Minuten ein.

# Story 2: “Das verlorene Multi-Line Log”

Symptom: Ein Java-Stacktrace erzeugt in ELK 50 verschiedene Log-Einträge (eine pro Zeile). Die Suche ist unmöglich. Ursache: Der Log-Forwarder denkt, jeder Zeilenumbruch ist ein neues Event. Lösung: Nutzen Sie Multiline-Filter im Shipper (Filebeat/Logstash) oder (besser) konfigurieren Sie die Applikation so, dass sie Stacktraces in ein einziges JSON-Feld schreibt.

# 6. Fazit & Empfehlung

• Zentralisierung: Schauen Sie sich niemals Logs auf einzelnen Servern an. Senden Sie alles an einen zentralen Host.
• Wartbarkeit: Definieren Sie eine einheitliche Logging-Funktion für alle Skripte Ihres Teams.
• Wahl: Nutzen Sie Loki für einfache Setups und ELK für komplexe Security-Analysen.

# Anhang: Cheatsheet für Log-Admins