Log-Management auf einem einzelnen Server

Wenn auf einem einzelnen Server etwas schiefgeht, sind die Logs meist alle vorhanden, verteilt über /var/log/nginx/, /var/log/postgresql/, das systemd-Journal, und was auch immer die Anwendung selbst schreibt, wohin es ihr beliebt. Die relevante Zeile zu finden bedeutet, zu wissen, in welchem von fünf Orten man suchen muss, und wenn die App Plaintext statt etwas Strukturiertem loggt, bedeutet "alle Anfragen von dieser IP in der letzten Stunde, über nginx und die App hinweg" mehrere unterschiedliche grep-Befehle mit unterschiedlichen Formaten. Nichts davon ist wirklich kaputt, es ist nur langsamer, als es sein müsste, besonders unter Druck.

Der vollständige ELK-Stack (Elasticsearch, Logstash, Kibana) löst das, ist aber für einen Server wirklich schwergewichtig, Elasticsearch allein will schon im Leerlauf einen ordentlichen Teil des Speichers. Der brauchbare Mittelweg für einen einzelnen Server ist kleiner als das.

Strukturierte Logs machen den Rest einfacher

Die wirkungsvollste einzelne Änderung ist, Anwendungslogs in ein strukturiertes Format (JSON) statt Freitext zu bringen. Zum Vergleich:

2026-10-28 14:32:01 ERROR Failed to process order 4821 for user 1029: timeout

{"time":"2026-10-28T14:32:01Z","level":"error","msg":"failed to process order","order_id":4821,"user_id":1029,"reason":"timeout"}

Die zweite Variante ist für einen Menschen auf den ersten Blick nicht lesbarer, aber sie ist abfragbar: "jeder Error für User 1029" oder "jeder Timeout in der letzten Stunde" wird zu einem Filter auf ein Feld statt zu einem Regex, der vielleicht auch unzusammenhängenden Text mit denselben Zahlen trifft. Die meisten Logging-Bibliotheken unterstützen strukturierte Ausgabe über eine Konfigurationsänderung, nicht über ein Rewrite.

journald macht schon mehr, als die meisten nutzen

Für alles, was als systemd-Service läuft (was auf einem modernen Linux-Server das Meiste ist), zentralisiert journalctl bereits stdout/stderr mit Zeitstempeln, und unterstützt Filterung, zu der viele gar nicht greifen:

# Alles von der App, letzte Stunde
journalctl -u myapp --since "1 hour ago"

# Logs mehrerer Units gleichzeitig verfolgen
journalctl -u myapp -u nginx -f

# Nur Errors, systemweit
journalctl -p err --since today

Das Letzte, Filtern nach Priorität über das gesamte System hinweg, kann eine verstreute Sammlung von Logdateien ohne externes Tooling überhaupt nicht. Wenn Anwendungslogs als JSON nach stdout gehen (statt in eine separate Datei), ist journalctls Ausgabe für diese Unit bereits strukturiert und kann zum Filtern auf bestimmte Felder an jq weitergeleitet werden.

Ein leichtgewichtiger Stack, für Dashboards

Für etwas, das näher an einem echten Log-Viewer ist, ohne den Footprint von Elasticsearch, ist Grafana Loki plus Promtail die üblicherweise empfohlene leichtgewichtige Kombination, Promtail liest Logdateien (oder das Journal) und schickt sie an Loki, das Grafana dann abfragen und neben den Metrik-Dashboards von Prometheus anzeigen kann, falls das schon eingerichtet ist. Lokis Ressourcenbedarf ist klein genug, um bequem neben einer Anwendung auf derselben VPS zu laufen, was der Hauptgrund ist, warum es hier passt, wo Elasticsearch das nicht würde.

# promtail-config.yml (minimal)
scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
    relabel_configs:
      - source_labels: ['__journal__systemd_unit']
        target_label: 'unit'

Rotation nicht vergessen

Nichts davon zählt, wenn die Disk mit Logs vollläuft, die sich niemand ansieht. logrotate ist für gängige Services meist schon konfiguriert, aber Anwendungslogs, die in einen eigenen Pfad geschrieben werden, brauchen einen eigenen Eintrag:

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

Und für das Journal selbst verhindert eine Größenbegrenzung, dass es still und unbegrenzt weiterwächst:

# /etc/systemd/journald.conf
SystemMaxUse=1G

Das eigentliche Ziel

Nichts davon muss aufwendig sein. Das Ziel ist, dass die Frage "was ist passiert, und wann", wenn etwas kaputtgeht, einen einzigen, beantwortbaren Ort zum Nachschauen hat, mit genug Struktur, um nach dem zu filtern, was zählt (eine User-ID, ein Fehlertyp, ein Zeitraum), statt durch Plaintext zu scrollen und zu hoffen, dass die relevante Zeile auffällt. Strukturiertes Logging plus journalctls Filterung deckt davon vieles kostenlos ab. Loki und Grafana fügen eine durchsuchbare Oberfläche obendrauf hinzu, für wenn "kostenlos" nicht mehr reicht.