Aus Logzeilen werden Tickets: automatisiertes Production-Log-Triage

Christopher Zechendorf

15.06.2026

Share:

Wie wir Produktions-Logs täglich automatisch nach wiederkehrenden Fehlern durchsuchen und daraus fertig spezifizierte Entwickler-Tickets erzeugen.

Logs liest niemand gern

Auf jeder produktiven Website fallen täglich tausende Logzeilen an – in der TYPO3-Applikation, in PHP-FPM, im nginx-Fehlerlog, in Solr und im Newsletter-System. Die meisten davon sind Rauschen: Bot-Anfragen, abgelaufene Links, harmlose Warnungen. Dazwischen verstecken sich aber die wenigen Zeilen, die wirklich zählen – der wiederkehrende Fatal Error, der ein paar Besucher pro Tag auf eine Fehlerseite schickt, ohne dass sich jemand beschwert.

Das Problem an diesen Fehlern ist nicht, dass man sie nicht beheben könnte. Das Problem ist, dass sie niemand sieht. Wer Logs nur dann öffnet, wenn ein Kunde anruft, arbeitet reaktiv – und übersieht systematisch all die Fehler, die unterhalb der Beschwerdeschwelle bleiben, sich aber Woche für Woche wiederholen. Genau diese Lücke haben wir für eine von uns betreute Plattform, die Weinplattform VINUM, mit einer täglichen Automatisierung geschlossen.

Die Herausforderung

Ein Mensch, der täglich gewissenhaft alle Logs einer grösseren TYPO3-Installation durchgeht, bräuchte dafür jeden Morgen eine Stunde – und würde nach einer Woche aufgeben, weil 99 Prozent der Zeilen irrelevant sind. Die eigentliche Schwierigkeit liegt nicht im Lesen, sondern im Filtern und Einordnen:

• Wiederholung erkennen: Derselbe Fehler taucht mit jeweils anderer URL, anderem Zeitstempel und anderer Stack-Trace-Variante auf. Erst wenn man hunderte Zeilen auf ihre eigentliche Meldung normalisiert, wird sichtbar, dass dahinter ein einziges Problem steckt.
• Signal von Rauschen trennen: Ein einmaliger Fehler während eines Deployments ist ein Artefakt, kein Bug. Eine Vendor-Warnung, die hunderttausendfach auftritt, aber niemanden stört, ist bekanntes Rauschen. Ein eigener Fehler, der dreimal an zwei verschiedenen Tagen auftritt, ist ein echtes Problem.
• Ursache verstehen: Eine Logzeile sagt, wo es knallt, aber selten warum. Ohne Blick in den Code ist ein Ticket wertlos – es verschiebt die eigentliche Arbeit nur nach hinten.

Wir wollten deshalb keinen weiteren Alert-Mechanismus, der bei jedem Fehler eine E-Mail verschickt. Wir wollten ein System, das aus dem Wust an Logzeilen selbstständig die wenigen echten, wiederkehrenden Probleme herausfiltert – und sie so aufbereitet, dass sofort an der Lösung gearbeitet werden kann.

Unsere Lösung

1. Ein täglicher Scan über alle relevanten Logs

Eine geplante Aufgabe läuft jede Nacht und liest die letzten sieben Tage über alle relevanten Quellen zusammen: das TYPO3-Applikationslog, die Fatal Errors aus PHP-FPM, das nginx-Fehlerlog sowie die Logs von Solr und dem Newsletter-System. Das gleitende Sieben-Tage-Fenster sorgt dafür, dass auch Fehler erfasst werden, die nur alle paar Tage auftreten – die also bei einem reinen Tagesblick durchrutschen würden.

2. Clustern, klassifizieren, Rauschen herausfiltern

Anschliessend werden die Einträge auf ihre eigentliche Meldung normalisiert und zu Clustern zusammengefasst. Jeder Cluster wird klassifiziert und gegen eine Schwelle geprüft, die zur jeweiligen Fehlerart passt:

• PHP-Fatals (Out-of-Memory, Type Errors) gelten schon ab einem einzigen Vorkommen als ernst – ein abgestürzter Worker ist immer einen Blick wert.
• Fehler im eigenen Code müssen mindestens dreimal an mindestens zwei verschiedenen Tagen auftreten. Damit fallen einmalige Ausreisser und kurze Fehlerbursts rund um ein Deployment automatisch heraus.
• Vendor- und Core-Fehler werden erst ab sehr hoher Häufigkeit und ausserhalb der Deployment-Fenster betrachtet.

Bekanntes Rauschen – veraltete TypoScript-Bedingungen, von Bots ausgelöste Exceptions, Weiterleitungsschleifen – ist explizit ausgenommen. Übrig bleibt eine kurze Liste von Clustern, die mit hoher Wahrscheinlichkeit echte, behebbare Probleme sind.

3. Ursachenforschung im Code – noch vor dem Ticket

Hier liegt der eigentliche Unterschied zu einem klassischen Monitoring. Bevor ein Ticket entsteht, wird zu jedem qualifizierten Cluster die Ursache im Quellcode recherchiert: Welche Stelle löst den Fehler aus, unter welcher Bedingung, und wie sieht ein sauberer Fix aus? Das Ergebnis ist kein blosser Hinweis “hier ist ein Fehler”, sondern ein vollständig ausformuliertes Entwickler-Ticket – mit Ursachenbeschreibung, Lösungsvorschlag, Randfällen, Akzeptanzkriterien und einer Priorität, die sich aus der Fehlerklasse ergibt. Ein solches Ticket kann ohne weitere Vorarbeit direkt in die Entwicklung gehen.

4. Keine Doppel-Tickets: Fingerprints und Wiedereröffnung

Da der Scan täglich läuft, würde derselbe Fehler ohne Gegenmassnahme jeden Tag ein neues Ticket erzeugen. Deshalb bekommt jedes Ticket einen Fingerabdruck der zugrundeliegenden Fehlermeldung. Taucht derselbe Fehler erneut auf, wird das bestehende offene Ticket lediglich um einen Kommentar ergänzt; ein bereits geschlossenes Ticket wird wieder geöffnet, falls der Fehler zurückkehrt. So entsteht nie ein Duplikat, und ein vermeintlich behobener Fehler, der wiederkommt, fällt sofort auf. Pro Lauf werden höchstens fünf neue Tickets erzeugt – der Rest wird in einer Übersicht zusammengefasst, damit ein einzelner schlechter Tag die Entwicklung nicht überrollt.

Das Ergebnis

Aus reaktivem Log-Durchsehen ist proaktive Zuverlässigkeitsarbeit geworden: Jeder wiederkehrende Fehler wird zu einer konkreten, nachvollziehbaren Aufgabe, statt unbemerkt im Log zu verharren. Drei Beispiele aus den ersten Läufen zeigen, was das praktisch bedeutet.

Ein wiederkehrender Out-of-Memory im Frontend. Mehrmals pro Woche brachen Frontend-Anfragen mit erschöpftem Arbeitsspeicher ab – begleitet von 502- und 504-Fehlern, wenn die betroffenen PHP-Worker starben. Die Spur führte tief: Ursache war eine massive Duplizierung von Medien-Verknüpfungen in der Datenbank. Eine einzelne Seite referenzierte dieselbe Datei über 316.000 Mal; über die gesamte Website hatten sich rund 695.000 doppelte Verweise angesammelt. Beim Aufbau der Seite versuchte TYPO3, jede einzelne dieser Referenzen aufzulösen – und sprengte dabei das Speicherlimit. Wir haben die korrupten Daten bereinigt (von 717.698 auf 22.681 Zeilen), die schreibende Stelle gefixt, die die Verknüpfungen angehängt statt ersetzt hatte, sodass sich der Datensalat nicht erneut aufbauen kann, und zusätzlich das Frontend so abgesichert, dass selbst defekte Daten nie wieder zu einem Speicherüberlauf führen.

Ein wiederkehrender Serverfehler in der englischen Weinsuche. Innerhalb von zwei Tagen sammelten sich 30 identische Fehler an: Jede Suchanfrage in der englischen Sprachversion endete mit einem HTTP-500-Fehler, weil für diese Sprache kein Solr-Suchindex existiert und eine fehlende Null-Prüfung den Aufruf ins Leere laufen liess. Da die betroffenen Links gültige TYPO3-Prüfsummen trugen, handelte es sich um echte, verlinkte Suchanfragen – nicht um Bot-Müll. Der Fix folgte einem Muster, das an anderer Stelle im Projekt bereits bewährt war.

Ein wiederkehrender Fehler auf der Event-Danke-Seite. Über mehrere Wochen verteilt traten 17 Abstürze auf, wenn eine Anmeldebestätigung nicht aufgelöst werden konnte – etwa beim erneuten Öffnen alter Links oder durch eine eigene Weiterleitung, die in bestimmten Fällen eine leere Kennung übergab. Auch hier lag die Ursache dank der vorgelagerten Code-Recherche schon mit dem Ticket auf dem Tisch.

Unter dem Strich: weniger 500er- und 502er-Fehler für die Besucher, eine deutlich kürzere Zeit von der Entstehung eines Fehlers bis zu seiner Behebung – und eine lückenlos dokumentierte Spur, welcher Fehler wann erkannt und wie behoben wurde.

Fazit

Betriebsstabilität entsteht selten durch das eine grosse Tool, sondern durch das konsequente Schliessen kleiner Lücken. Die wichtigste davon ist die zwischen “der Fehler steht im Log” und “jemand kümmert sich darum”. Indem wir das Sichten, Filtern und Einordnen der Logs automatisieren und jeden echten Fund samt Ursachenanalyse direkt als Arbeitsauftrag aufbereiten, wird aus einer Datenflut, die niemand liest, eine überschaubare Liste konkreter Aufgaben. Reliability wird so zu etwas Planbarem statt zu einer Frage des Zufalls – und genau das ist der Unterschied zwischen “läuft schon irgendwie” und einer Website, der man vertrauen kann.

Möchten Sie wissen, welche wiederkehrenden Fehler in den Logs Ihrer Website schlummern? Sprechen Sie uns an – wir schauen uns Ihre Betriebsstabilität gerne systematisch an.