Logging im Enterprise-Umfeld

Warum Logging zählt — und gerne unterschätzt wird

Logs sind die billigste Versicherung gegen den teuersten Moment in der Software: einen Vorfall, dessen Ursache niemand mehr rekonstruieren kann. Gute Logs verkürzen den Weg von „Alarm" zu „Ursache verstanden" von Stunden auf Minuten — schlechte verlängern ihn auf Tage.

In regulierten Branchen kommt eine zweite Ebene dazu: Aufsichtsbehörden, Datenschutzbeauftragte und Wirtschaftsprüfer wollen Nachweise. Nicht „wir loggen das schon irgendwie", sondern: wer hat wann auf welches Datum zugegriffen, welche Entscheidung wurde getroffen, wer hat sie genehmigt. Logs sind hier nicht nice-to-have, sondern Pflichtnachweis.

Trotzdem werden sie in Projekten oft als das behandelt, was man am Ende „auch noch mitnimmt". Die Folge sieht man im ersten Produktionsvorfall: unstrukturierte Freitext-Ausgaben, verstreut auf zehn Hosts, ohne durchgehende Request-ID, ohne Zeitsynchronisation, ohne klare Log-Stufen. Was bleibt, ist Rätselraten.

Vom Monolithen zum Microservice — warum altes Logging nicht mehr reicht

Im Monolithen war Logging trivial. Eine Anwendung, eine Logdatei, ein grep — und der Fehler war eingekreist. Mit Microservices verschwindet diese Einfachheit, und mit ihr die Möglichkeit, sich auf Pragmatismus zu verlassen.

Beispiel: Eine Bürgeranfrage „Termin im Bürgerbüro buchen" durchläuft heute typischerweise sechs Services — API-Gateway, Authentifizierungs-Service, Terminverwaltung, Kalender-Backend, Benachrichtigung, Audit-Log. Jeder Service hat seine eigene Logdatei, eigene Hosts, eigene Container, eigene Zeitstempel mit potenziell unterschiedlichen Zeitzonen. Wenn die Anfrage bei Schritt fünf mit einem 502er hängenbleibt, ist „in alle Logs gleichzeitig grep'en" keine Option mehr — selbst wenn man Zugriff auf alle zehn Container hätte.

Drei Konsequenzen ergeben sich für jedes verteilte System:

• Logs müssen zentralisiert werden. Verstreute Dateien auf zehn Containern sind im Vorfall wertlos. Ein zentraler Sammelpunkt — ob On-Premises oder als Service — ist nicht optional.
• Logs müssen strukturiert sein. Freitext ist nicht filterbar. JSON ist Standard, weil es ohne Parser-Akrobatik abfragbar bleibt.
• Logs müssen korrelierbar sein. Ohne eine durchgängige Request- oder Trace-ID, die jeden Service durchläuft, gibt es kein Bild des Gesamtvorgangs — nur Fragmente.

Die drei Säulen der Observability

Logging ist nur ein Teil des Bildes. Observability — die Fähigkeit, den Innenzustand eines Systems aus seinen externen Signalen zu rekonstruieren — stützt sich auf drei Säulen, die einander ergänzen, statt einander zu ersetzen.

Logs dokumentieren konkrete Ereignisse: „Nutzer X hat um 14:32 die Anfrage Y gestartet, sie endete mit Fehlercode Z". Sie werden reaktiv gelesen, wenn etwas zu klären ist.

Metriken sind aggregierte Zeitreihen: „95. Perzentil der Antwortzeit über die letzten fünf Minuten", „aktuelle CPU-Auslastung", „offene Warteschlangenelemente". Sie wirken proaktiv — Schwellwerte lösen Alarme aus, lange bevor jemand ein Log öffnet. Werkzeuge: Prometheus, Grafana Mimir, Datadog Metrics.

Traces verfolgen eine einzelne Anfrage über Service-Grenzen hinweg. Sie zeigen nicht nur, dass etwas langsam war, sondern welcher Service welchen Anteil zur Gesamtlatenz beigetragen hat. Werkzeuge: OpenTelemetry (Standard für die Instrumentierung), Jaeger oder Tempo (Storage und Visualisierung).

Wer nur eine Säule baut, fliegt im Vorfall blind: Metriken zeigen, dass es klemmt; Logs zeigen, was passiert ist; Traces zeigen, wo der Engpass sitzt. Ein reifes Setup verbindet alle drei — idealerweise so, dass man im Alarm auf eine Metrik klickt, von dort in den passenden Trace springt und am Ende beim relevanten Log-Eintrag landet.

Anatomie eines belastbaren Log-Eintrags und Stack-Aufbau

Ein guter Log-Eintrag ist eine strukturierte Nachricht, keine Erzählung. Format: JSON. Pflichtfelder, ohne die der Eintrag im Vorfall nichts wert ist:

{
  "timestamp": "2026-05-13T14:32:18.421Z",
  "level":     "error",
  "service":   "termin-service",
  "host":      "termin-pod-7c4b9",
  "requestID": "8a3f1c2e-94df-4ef8-9f98-9fbe9b9831c9",
  "userID":    "u-h8a9c2",
  "message":   "Datenbank-Timeout bei loadSlots",
  "context": {
    "leistung":    "perso",
    "duration_ms": 5023
  },
  "stack":     "Error: connect ETIMEDOUT 10.0.4.12:5432..."
}

• timestamp — ISO 8601 mit Millisekunden, immer in UTC. Lokalzeit ist im verteilten System Pfusch.
• level — debug · info · warn · error. Mehr Stufen verwirren nur. Produktion läuft typischerweise auf info oder höher.
• service und host — wo entstand der Eintrag. Im Container-Umfeld zusätzlich Pod-Name oder Container-ID.
• requestID — eine UUID, die durch alle Services gereicht wird. Der wichtigste Hebel im Vorfall (siehe Abschnitt Praxis).
• userID — pseudonymisiert (Hash, opake ID). Niemals die E-Mail-Adresse im Klartext (siehe DSGVO).
• message und context — die eigentliche Nachricht und strukturierte Metadaten. Lieber zehn Felder zu viel als zwei zu wenig — Speicher ist günstiger als der nächste Vorfall.

Der Stack — vier Stufen

Ein zentraler Log-Stack besteht aus vier Schichten, unabhängig vom konkreten Werkzeug:

1. Producer — die Anwendung

   Jede Anwendung schreibt strukturierte JSON-Logs nach stdout oder in eine Datei. Bibliotheken: Winston oder Pino (Node.js), Logback oder Log4j2 (Java), structlog (Python), Serilog (.NET). Für HTTP-Access-Logs in Express ergänzt Morgan einen Logger wie Winston — Morgan protokolliert eingehende Requests, Winston übernimmt alles Fachliche.

2. Collector — der Einsammler

   Sammelt Logs von allen Hosts und Containern, parst, filtert und reichert sie an. Logstash (im ELK-Stack), Promtail (im Loki-Stack), Fluent Bit oder Vector (vendor-neutral). Im Kubernetes-Umfeld läuft der Collector typischerweise als DaemonSet — ein Container pro Knoten, der die Logs aller Pods abgreift.

3. Storage — das durchsuchbare Archiv

   Elasticsearch indexiert jeden Feldinhalt; das ist mächtig, aber speicher- und kostenintensiv. Grafana Loki indexiert nur die Labels (z.B. service, level) und legt den eigentlichen Logtext komprimiert ab — günstiger im Betrieb, dafür weniger ad-hoc-Volltextsuche. Cloud-Alternativen: Datadog, Splunk, AWS CloudWatch Logs.

4. Visualisierung — das Frontend

   Kibana ist das Frontend für Elasticsearch. Grafana ist universeller — es kann Loki, Elasticsearch, Prometheus und viele weitere Quellen gleichzeitig anzeigen. In Setups, die Logs, Metriken und Traces zusammenführen wollen, ist Grafana meistens die bessere Wahl, einfach weil derselbe Bildschirm alle drei Säulen darstellt.

Stack-Vergleich: ELK vs. Grafana Loki

Im Open-Source-Markt haben sich zwei Stacks etabliert. Welcher passt, hängt vor allem von Suchanforderungen, Volumen und Budget ab.

Cloud- und SaaS-Alternativen

Für Teams ohne Kapazität, einen Stack selbst zu betreiben, übernehmen Datadog, Splunk Cloud, Sumo Logic, AWS CloudWatch Logs oder Azure Monitor Storage und Visualisierung als Service. Der Trade-off: höhere laufende Kosten pro GB und weniger Hoheit über die Daten — was bei sensiblen Logs (Personendaten, Bankdaten) gegen sie sprechen kann. In stark regulierten Umgebungen prüfen wir das Bereitstellungsmodell daher immer gegen die jeweilige Datenklassifikation, bevor wir den SaaS-Weg empfehlen.

Praxis: Korrelation, DSGVO, Retention

Drei Disziplinen, die im Setup leicht vergessen werden, im Betrieb aber den Unterschied machen.

Request-Korrelation per Trace-ID

Die einzige Technik, die im verteilten System wirklich trägt: jede Anfrage bekommt am Eingang eine eindeutige ID, die durch alle Services mitläuft. Drei Schritte:

1. ID am Eingang erzeugen

   Das API-Gateway generiert für jede eingehende Anfrage eine UUID und legt sie in den Request-Kontext (HTTP-Header X-Request-ID oder MDC bei Java). Existiert bereits eine ID vom Aufrufer, wird sie übernommen — so reichen Traces auch über Systemgrenzen hinaus.

2. ID weitergeben

   Bei jedem internen Aufruf (HTTP, Queue, gRPC) wird die ID im Header oder Message-Property mitgeschickt. OpenTelemetry, Spring Cloud Sleuth oder Micrometer Tracing übernehmen das automatisch, sobald sie eingebunden sind — was den manuellen Aufwand drastisch reduziert.

   // API-Gateway: ID am Eingang setzen
   app.use((req, res, next) => {
     req.requestID = req.headers['x-request-id'] ?? randomUUID();
     next();
   });
   
   // Beim Aufruf des Persistenz-Service mitgeben
   const newOrder = await http.post(ORDER_URL, req.body, {
     headers: { 'x-request-id': req.requestID }
   });

3. ID in jeden Logeintrag schreiben

   Jeder Logger liest die ID aus dem Kontext und ergänzt sie als requestID-Feld in jedem JSON-Eintrag. In Kibana oder Grafana genügt dann eine Suche requestID:"8a3f…", um alle Einträge der Anfrage über alle Services hinweg in chronologischer Reihenfolge zu sehen — die teuerste Frage im Betrieb wird zur Sekundenangelegenheit.

DSGVO — was darf ins Log

Logs sind ein Datenverarbeitungsvorgang im Sinne der DSGVO. Wer Personendaten ins Log schreibt, muss sie begründen können (Zweckbindung), löschen können (Recht auf Vergessenwerden) und auf das Notwendige beschränken (Datensparsamkeit). Konkrete Regeln, die sich in regulierten Projekten bewährt haben:

• Keine Klarnamen, keine Passwörter, keine Zahlungsdaten im Log. Niemals. Auch nicht in der Fehlermeldung „falsches Passwort für user@firma.de" — das ist genau der Eintrag, den ein Auditor schmerzhaft findet.
• User-IDs pseudonymisieren. Ein opaker Hash oder eine interne ID, nicht die E-Mail-Adresse. Eine separate, zugriffsgeschützte Mapping-Tabelle löst die Pseudonymisierung im Vorfall auf — unter Vier-Augen-Prinzip.
• Felder auf Notwendigkeit prüfen. Geburtsdatum, Anschrift, IBAN gehören nur dann ins Log, wenn ein konkreter Zweck (z.B. Audit einer Buchung) das verlangt — und dann nur in dem Service, der den Zweck verantwortet.
• Retention klar definieren. 30 Tage für Debug-Logs, 90 Tage für Access-Logs, ein Jahr für Security-relevante Audit-Logs sind ein üblicher Rahmen. Die exakten Werte richten sich nach Aufbewahrungspflicht und Datenschutzbeauftragten — wichtig ist, dass sie festgelegt sind, nicht ungeschrieben.
• Transport- und Speicherverschlüsselung. TLS vom Producer bis zum Storage; Verschlüsselung at rest. Im Cloud-Setup gehört dazu auch die Frage, wer die Schlüssel kontrolliert.

Volumen und Kosten — der unterschätzte Hebel

Logs wachsen. Ein einzelner Microservice mit moderaten 50 Requests pro Sekunde und einem 1 KB großen JSON-Eintrag pro Request erzeugt rund 4,3 GB pro Tag, etwa 130 GB pro Monat. Mal zehn Services — und der Log-Stack ist plötzlich der teuerste Posten im Cluster. Drei Hebel, in der Reihenfolge ihrer Wirkung:

• Log-Levels strikt nutzen. debug nur in der Entwicklung, info nur für Ereignisse, die in Audits relevant sind. Produktion läuft meist auf warn aufwärts; Levels lassen sich pro Service über Umgebungsvariablen drehen, ohne Deploy.
• Sampling für High-Volume-Ereignisse. Wenn ein Health-Check fünfmal pro Sekunde feuert, reicht 1 von 100. Bei Fehlern: niemals sampeln — jeder Fehler zählt.
• Retention abgestuft. Heiß (durchsuchbar): 7 Tage. Warm (komprimiert, langsamer): 30 Tage. Kalt (Objekt-Archiv, z.B. S3 Glacier): nach gesetzlicher Vorgabe. Das schiebt 80 % des Volumens in die günstigste Storage-Klasse, ohne die Auswertbarkeit zu verlieren.