Ein Online-Shop produziert pausenlos Spuren: Jede Bestellung, jede Zahlung, jeder fehlgeschlagene Login und jeder langsame Datenbankaufruf hinterlässt einen Log-Eintrag. Doch ungenutzte Logs sind nur Datenmüll auf der Festplatte. Erst strukturiertes Logging, zentrale Aggregation und durchdachtes Alerting verwandeln diese Spuren in Frühwarnsignale. Das Google SRE Book beschreibt mit den vier Golden Signals (Latenz, Traffic, Fehler, Sättigung) ein bewährtes Fundament dafür (Google SRE Book). Dieser Leitfaden zeigt, wie Sie Logs sinnvoll strukturieren, Alerts setzen, ohne Ihr Team in Alarm-Müdigkeit zu treiben, und im Ernstfall schnell reagieren. Den passenden technischen Unterbau liefert professionelles Log-Monitoring.
Strukturiertes Logging als Fundament
Klassische Log-Zeilen sind für Menschen geschrieben: ein Zeitstempel, eine Nachricht, vielleicht ein Stacktrace. Für die maschinelle Auswertung sind sie ungeeignet, weil jede Komponente ihr eigenes Format verwendet. Strukturiertes Logging löst das Problem, indem jeder Eintrag als maschinenlesbares Objekt -- meist JSON -- mit klar benannten Feldern geschrieben wird: Zeitstempel, Log-Level, Nachricht, Service, Request-ID und fachliche Kontextdaten wie order_id oder customer_id. So lassen sich Logs filtern, aggregieren und korrelieren, statt sie nur zu durchsuchen.
Das OWASP Logging Cheat Sheet empfiehlt, sicherheitsrelevante Ereignisse konsistent und manipulationssicher zu protokollieren -- etwa fehlgeschlagene Logins, Rechteänderungen oder Eingabevalidierungsfehler (OWASP Logging Cheat Sheet). Genauso wichtig ist, was nicht geloggt wird: Passwörter, vollständige Kreditkartennummern oder Session-Token gehören niemals ins Log. Für deutsche Shops ist das auch eine datenschutzrechtliche Pflicht; das BSI ordnet eine angemessene Protokollierung im IT-Grundschutz dem Baustein OPS.1.1.5 zu (BSI IT-Grundschutz). Personenbezogene Daten werden im Log nach Möglichkeit pseudonymisiert.
{
"timestamp": "2026-06-03T14:22:08.512Z",
"level": "ERROR",
"service": "shopware-checkout",
"trace_id": "a91f3c7e-1d22-4f0b-9c11-8e2a",
"route": "/checkout/finish",
"http_status": 500,
"order_id": 10493,
"customer_ref": "cust_7f12a",
"message": "Payment provider timeout after 8000ms",
"error_code": "PAY_TIMEOUT"
}Eine Request-ID, die alles verbindet
trace_id und reichen Sie sie durch alle Schichten weiter -- vom Webserver über die Shopware-Anwendung bis zum Payment-Gateway. So lässt sich ein einzelner fehlgeschlagener Checkout über alle Services hinweg rekonstruieren, statt sich durch fünf getrennte Logdateien zu wühlen.Log-Level richtig einsetzen
Log-Level sind die Grundlage jeder sinnvollen Filterung. Wer alles auf demselben Level loggt, ertränkt wichtige Meldungen im Rauschen. Eine bewährte Staffelung hilft, im Alltag den Überblick zu behalten und im Incident schnell die relevanten Einträge zu finden. Wichtig ist Konsistenz: Ein ERROR muss in jedem Service dasselbe bedeuten, sonst verlieren Schwellenwerte ihren Sinn.
DEBUG / TRACE
Detailinformationen für die Entwicklung. In Produktion meist deaktiviert oder nur temporär aktiviert, um ein konkretes Problem einzugrenzen.
INFO
Fachliche Ereignisse im Normalbetrieb: Bestellung angelegt, Zahlung bestätigt, Cronjob abgeschlossen. Basis für Geschäftskennzahlen aus Logs.
WARN
Auffälligkeiten, die noch keinen Ausfall bedeuten: langsame Antworten, wiederholte Zahlungsversuche, Annäherung an Speichergrenzen.
ERROR
Eine konkrete Operation ist fehlgeschlagen: Checkout abgebrochen, API-Aufruf nicht beantwortet. Kandidat für Schwellenwert-Alerts.
CRITICAL / FATAL
Der Dienst oder eine zentrale Funktion ist nicht mehr nutzbar. Solche Ereignisse rechtfertigen eine sofortige Eskalation an den Bereitschaftsdienst.
SECURITY / AUDIT
Sicherheits- und Audit-Ereignisse getrennt führen: Logins, Rechteänderungen, Admin-Aktionen -- nachvollziehbar und manipulationssicher.
Zentrale Log-Aggregation
Logs auf einzelnen Servern sind im Ernstfall wertlos: Wer im Incident auf jeden Server einzeln per SSH zugreifen muss, verliert wertvolle Minuten -- und auf einem abgestürzten Server kommt er womöglich gar nicht mehr an die Logs. Zentrale Log-Aggregation sammelt alle Einträge über einen Collector-Agenten ein, normalisiert sie in ein einheitliches Schema und macht sie durchsuchbar. Quelloffene Werkzeuge übernehmen das Einsammeln, Parsen und Indexieren; die konkrete Auswahl richtet sich nach Datenvolumen und Hosting-Umgebung.
Drei Aspekte sind dabei entscheidend. Erstens die Retention: Wie lange werden Logs aufbewahrt? Für die Fehlersuche reichen oft wenige Wochen, sicherheitsrelevante Audit-Logs sollten länger vorgehalten werden. Zweitens das Volumen: Ungebremstes DEBUG-Logging kann pro Shop schnell mehrere Gigabyte am Tag erzeugen, deshalb wird in Produktion gezielt gefiltert. Drittens der Zugriffsschutz: Logs enthalten oft sensible Informationen und müssen entsprechend abgesichert sein. Die zentrale Einrichtung berücksichtigt alle drei Punkte von Anfang an.
# Beispielhafte Sammel-Pipeline (generisch, Open Source)
sources:
nginx_access: { path: /var/log/nginx/access.log, parser: json }
shopware_app: { path: /var/www/shop/var/log/*.log, parser: json }
mysql_slow: { path: /var/log/mysql/slow.log, parser: slowlog }
transforms:
enrich:
add_fields: { env: production, shop: shop-01 }
drop_fields: [ password, card_number, session_token ]
sinks:
central_store:
index_by: [ service, level, http_status ]
retention_days: { default: 30, security: 365 }Metriken, Logs und Traces im Zusammenspiel
Logs sind nur eine von drei Säulen der Observability. Die CNCF-Initiative OpenTelemetry beschreibt Metriken, Logs und Traces als komplementäre Signale, die zusammen erst ein vollständiges Bild ergeben (CNCF OpenTelemetry). Jede Säule beantwortet eine andere Frage, und der größte Hebel entsteht, wenn sie über eine gemeinsame trace_id verknüpft sind: Eine Metrik zeigt, dass etwas nicht stimmt, das zugehörige Log erklärt warum, und der Trace zeigt wo in der Aufrufkette.
| Signal | Beantwortet | Typisches Beispiel im Shop | Stärke für Alerts |
|---|---|---|---|
| Metriken | Was passiert, in Zahlen? | Fehlerrate, p95-Latenz, Bestellungen pro Minute | Sehr gut: günstig zu speichern, ideal für Schwellenwerte |
| Logs | Warum ist es passiert? | Stacktrace eines abgebrochenen Checkouts | Gut: präzise Ursachenanalyse, höheres Volumen |
| Traces | Wo im System hängt es? | Anfrage durch App, Datenbank und Payment-Gateway | Stark bei verteilten Aufrufen und Latenzproblemen |
Für die meisten Online-Shops ist ein pragmatischer Einstieg sinnvoll: zuerst saubere Metriken für die wichtigsten Kennzahlen, dann strukturierte Logs zur Ursachenanalyse und schließlich Tracing für die Engpässe, die sich allein über Logs nicht erklären lassen. Wichtig ist, Alerts primär auf Metriken zu setzen und Logs für die anschließende Diagnose zu nutzen -- so bleiben Alerts stabil und das Log-Volumen kontrollierbar.
Sinnvolle Alerts: Schwellenwerte, Fehlerraten, Anomalien
Ein Alert ist nur dann sein Rauschen wert, wenn er auf etwas hinweist, das ein Mensch tatsächlich beheben muss. Das Google SRE Book formuliert dafür eine klare Regel: Alerts sollten symptombasiert sein und auf die Auswirkung für den Nutzer zielen, nicht auf jede einzelne technische Ursache (Google SRE Book). Für einen Shop bedeutet das: Ein Alarm bei steigender Checkout-Fehlerrate ist wertvoller als hundert Einzelmeldungen über kurzzeitig hohe CPU-Last.
- Schwellenwerte (Thresholds): Feste Grenzen mit Zeitfenster, etwa Fehlerrate der 5xx-Antworten über 2 Prozent während fünf Minuten. Das Zeitfenster verhindert Alarme bei einzelnen Ausreißern.
- Fehlerraten und Fehlerbudgets: Statt absoluter Zahlen die relative Fehlerquote betrachten. Das DORA-Programm zeigt, dass leistungsstarke Teams Zuverlässigkeit über solche messbaren Ziele steuern (DORA State of DevOps).
- Latenz-Perzentile: Nicht der Durchschnitt zählt, sondern p95 oder p99. Ein guter Mittelwert kann verbergen, dass jeder zwanzigste Kunde einen quälend langsamen Checkout erlebt.
- Anomalie-Erkennung: Abweichungen vom erwarteten Muster melden -- etwa null Bestellungen in einem Zeitfenster, in dem normalerweise welche eingehen. Solche fachlichen Alerts erkennen Ausfälle, die rein technisch unauffällig wirken.
- Sättigung: Annäherung an Grenzen wie Speicher, Verbindungspool oder Festplatte frühzeitig melden, bevor daraus ein Ausfall wird.
groups:
- name: shop-checkout
rules:
- alert: HoheCheckoutFehlerrate
expr: sum(rate(http_requests_total{route="/checkout",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{route="/checkout"}[5m])) > 0.02
for: 5m
labels: { severity: critical }
annotations:
summary: "Checkout-Fehlerrate über 2% seit 5 Minuten"
runbook: "https://wiki.intern/runbooks/checkout-5xx"
- alert: KeineBestellungen
expr: sum(increase(orders_completed_total[15m])) == 0
for: 15m
labels: { severity: critical }
annotations:
summary: "Seit 15 Minuten keine abgeschlossene Bestellung"Jeder Alert braucht ein Runbook
Alarm-Müdigkeit vermeiden
Das größte Risiko eines Alerting-Systems ist nicht der fehlende, sondern der zu häufige Alarm. Wer ständig Benachrichtigungen erhält, die keine Handlung erfordern, fängt an, sie zu ignorieren -- und übersieht irgendwann auch den entscheidenden Alarm. In der Praxis berichten geschätzt 73 Prozent der Teams von einer Form der Alarm-Müdigkeit (Projekterfahrung). Das Google SRE Book ist hier deutlich: Jeder Alert, der eine Person weckt, muss dringend, handlungsrelevant und nicht automatisch lösbar sein (Google SRE Book).
- Nur auf Symptome alarmieren, die den Nutzer betreffen -- nicht auf jede technische Einzelmetrik.
- Severity-Stufen klar trennen: Was weckt jemanden nachts, was wartet bis zum Morgen?
- Doppelte Alarme deduplizieren und zusammengehörige Meldungen zu einem Incident bündeln.
- Bekannte Wartungsfenster stummschalten, um vorhersehbare Alarme zu unterdrücken.
- Alert-Regeln regelmäßig überprüfen und Regeln entfernen, die nie zu einer Handlung geführt haben.
- Wiederkehrende, automatisch behebbare Probleme an der Wurzel lösen statt dauerhaft zu alarmieren.
Eskalation und On-Call
Ein präziser Alarm nützt nur, wenn er die richtige Person erreicht und im Zweifel weiterläuft. Eine On-Call-Rotation legt fest, wer zu welcher Zeit für Alarme zuständig ist, und eine Eskalationskette stellt sicher, dass ein nicht bestätigter Alarm automatisch die nächste Stufe erreicht. Ein bewährtes Modell für einen Shop: Stufe 1 sofort als Chat- und Push-Nachricht, Stufe 2 nach fünf Minuten als SMS, Stufe 3 nach fünfzehn Minuten als Anruf an den Bereitschaftsdienst, Stufe 4 nach dreißig Minuten an die technische Leitung.
Damit On-Call nachhaltig funktioniert, muss die Belastung tragbar bleiben. Das Google SRE Book empfiehlt, On-Call-Last und nächtliche Unterbrechungen zu begrenzen, damit die Bereitschaft nicht zur Dauerbelastung wird (Google SRE Book). Eine kleine, eingespielte Rotation mit klaren Übergaben und dokumentierten Zuständigkeiten ist verlässlicher als ein großer Verteiler, in dem sich am Ende niemand verantwortlich fühlt. Für viele Shop-Betreiber ist es deshalb sinnvoll, die nächtliche Bereitschaft an einen externen Dienstleister zu übergeben.
Eskalationsketten gehören getestet
Incident-Reaktion: vom Alarm zur Lösung
Wenn ein Alarm zu einem echten Vorfall wird, entscheidet die Reaktionsqualität über Ausmaß und Dauer des Schadens. Eine zentrale Kennzahl ist dabei die Mean Time to Recovery (MTTR) -- die durchschnittliche Zeit von der Erkennung bis zur Wiederherstellung. Das DORA-Programm zählt die Wiederherstellungszeit zu den Kernkennzahlen leistungsstarker Software-Teams (DORA State of DevOps). Ziel ist nicht, jeden Fehler zu vermeiden, sondern Fehler schnell und kontrolliert zu beheben.
- Erkennen und einordnen: Alarm bestätigen, Severity prüfen, betroffene Funktion bestimmen (ist der Checkout betroffen oder nur ein Randbereich?).
- Diagnostizieren: Über die
trace_iddie zusammengehörigen Logs, Metriken und Traces zusammenführen und die Ursache eingrenzen. - Stabilisieren: Erst die Auswirkung begrenzen -- etwa über ein Rollback oder das Abschalten eines fehlerhaften Features -- bevor die endgültige Ursache behoben wird.
- Kommunizieren: Betroffene intern und gegebenenfalls Kunden transparent informieren, idealerweise über eine Status-Seite.
- Aufarbeiten: Ein schuldfreies Postmortem hält Ursache, Verlauf und Verbesserungen fest -- so wird aus jedem Vorfall ein dauerhafter Lerngewinn.
Hoffnung ist keine Strategie. Verlässliche Systeme entstehen durch Messung, klare Signale und geübte Reaktion -- nicht durch den Wunsch, dass nichts passiert.
Wer Logging, Aggregation, Alerting und Incident-Reaktion einmal sauber aufgesetzt hat, kann denselben Aufbau über alle Updates und Releases hinweg nutzen. Eng damit verzahnt ist eine saubere Release-Disziplin: Wie Sie Änderungen risikoarm ausspielen und vor Fehlern abfangen, beschreibt der Beitrag zu Staging-Umgebungen und sicheren Updates. Beide Bausteine zusammen -- gute Sichtbarkeit im Betrieb und kontrollierte Änderungen -- bilden das Rückgrat eines verlässlich laufenden Online-Shops. Den laufenden Betrieb dieser Kette übernimmt unser Bereitschafts- und Notfall-Support; bei akuten Vorfällen unterstützt der direkte Draht zum Team.