Logging, Monitoring & Alerts: Webapps im Betrieb sichtbar machen

Die meisten Webapps laufen genau bis zu dem Moment, in dem sie es nicht mehr tun. Und das Unangenehme daran ist selten der Fehler selbst, sondern wie man davon erfährt: durch einen verärgerten Anruf, eine E-Mail mit dem Betreff „geht nicht mehr" oder im schlimmsten Fall durch einen Kunden, der einfach abspringt.

Eine Anwendung, die produktiv im Einsatz ist, braucht mehr als ein grünes Häkchen beim Hoster. Sie braucht eine Möglichkeit, von innen heraus zu zeigen, was sie gerade tut, wo es klemmt und ob es ihr gut geht. Genau das meint der etwas sperrige Begriff Observability: die Fähigkeit, den Zustand eines Systems von außen ablesen zu können, ohne sich per SSH durchzuwühlen und zu raten.

In über 25 Jahren Betrieb von Business-Webapps habe ich eine einfache Wahrheit immer wieder bestätigt gesehen: Nicht die Anwendung ohne Fehler ist die professionelle, sondern die, bei der man den Fehler sieht, bevor der Nutzer ihn meldet. Dieser Beitrag zeigt, wie Sie dahin kommen, in drei Ebenen: Logging, Monitoring und Alerts.

TL;DR - Die Kurzfassung

• Logging beantwortet die Frage „was ist passiert?" - strukturiert, durchsuchbar, mit Kontext statt nur echo "Fehler".
• Monitoring beantwortet „wie geht es dem System gerade?" - Verfügbarkeit, Antwortzeiten, Fehlerrate, Ressourcen.
• Alerts beantworten „muss ich jetzt etwas tun?" - wenige, gezielte Benachrichtigungen statt Dauerrauschen.
• Die häufigsten Fehler: gar nicht loggen, alles loggen, oder so laut alarmieren, dass niemand mehr hinschaut.
• Man muss nicht groß anfangen. Schon ein strukturiertes Logfile plus ein simpler Uptime-Check sind ein Quantensprung gegenüber „der Kunde ruft an".

Warum „läuft doch" nicht reicht

Eine Webapp ist kein Auslieferungsprodukt, das man einmal abgibt und das dann für sich existiert. Sie ist ein laufender Betrieb. Server werden voll, externe Schnittstellen ändern sich, eine seltene Eingabe löst einen Fehler aus, den im Test niemand gesehen hat. Das ist normal und kein Zeichen schlechter Arbeit.

Der Unterschied zwischen einem professionell betriebenen System und einem Bastelprojekt liegt nicht darin, ob solche Dinge passieren, sondern ob sie auffallen, bevor sie wehtun. Ohne Beobachtung merken Sie einen vollgelaufenen Speicher erst, wenn die Seite weiß bleibt. Mit Beobachtung bekommen Sie drei Tage vorher einen Hinweis und handeln in Ruhe.

Faustregel: Jedes Problem, von dem Sie zuerst durch einen Nutzer erfahren, ist ein Problem, das Sie hätten früher sehen können.

Ebene 1: Logging - was ist passiert?

Logging ist die Grundlage. Es beantwortet im Nachhinein die Frage, was genau zu welchem Zeitpunkt geschah. Der typische Anfängerfehler ist nicht, zu wenig zu loggen, sondern unstrukturiert zu loggen: ein paar verstreute Fehlermeldungen, die niemand wiederfindet, wenn es darauf ankommt.

Strukturiert statt Textwüste

Ein gutes Log ist maschinenlesbar und durchsuchbar. Statt einer Textzeile, die man mit dem Auge durchforsten muss, schreibt man Einträge mit festen Feldern, idealerweise als JSON. Vergleichen Sie diese beiden Varianten:

// Schlecht: was, wo, für wen, wie schlimm? Unklar.
error_log("Zahlung fehlgeschlagen");

// Gut: strukturiert, mit Kontext und Schweregrad
$logger->error('payment_failed', [
    'order_id'   => 4711,
    'user_id'    => 88,
    'amount'     => 149.00,
    'gateway'    => 'stripe',
    'reason'     => $e->getMessage(),
    'request_id' => $requestId,
]);

Der zweite Eintrag lässt sich später nach order_id filtern, nach Gateway gruppieren oder über die request_id mit anderen Logzeilen desselben Aufrufs verbinden. Das ist der Unterschied zwischen „irgendwo war mal ein Fehler" und „am 14. um 9:42 schlug Bestellung 4711 bei Stripe fehl, hier ist die Kette".

Log-Level sinnvoll nutzen

Nicht jede Zeile ist gleich wichtig. Etablierte Stufen helfen, später das Wesentliche herauszufiltern:

Level	Wofür	Beispiel
DEBUG	Detail für die Entwicklung	„Cache-Treffer für Schlüssel X"
INFO	Normale, erwartete Ereignisse	„Nutzer angemeldet"
WARNING	Auffällig, aber noch kein Ausfall	„API-Antwort dauerte 8 Sekunden"
ERROR	Etwas ist fehlgeschlagen	„Zahlung konnte nicht gebucht werden"
CRITICAL	System teilweise oder ganz außer Betrieb	„Datenbank nicht erreichbar"

Im Tagesbetrieb interessieren Sie meist nur WARNING aufwärts. Aber wenn es einmal brennt, sind die DEBUG- und INFO-Zeilen Gold wert, um den Hergang zu rekonstruieren. In PHP übernimmt diese Arbeit eine Bibliothek wie Monolog, die sich an den Standard PSR-3 hält. Man muss das Rad nicht selbst bauen.

Wohin mit den Logs?

Für kleinere Anwendungen reicht eine rotierende Logdatei auf dem Server völlig aus, solange sie strukturiert ist und automatisch aufgeräumt wird (unter Linux erledigt das logrotate). Wichtig ist nur: Das Log darf die Platte nicht volllaufen lassen, und sensible Daten wie Passwörter oder vollständige Kreditkartennummern haben dort nichts zu suchen. Wächst das System, lohnt sich eine zentrale Sammelstelle, in die mehrere Server und Dienste hineinschreiben.

Fehler-Tracking: vom Logeintrag zur Benachrichtigung

Ein Logfile sagt Ihnen, was passiert ist, aber nur, wenn Sie hineinschauen. Den Schritt davor, nämlich das aktive Melden von Fehlern, übernimmt ein Fehler-Tracking-Dienst. Der bekannteste ist Sentry: Er fängt nicht abgefangene Exceptions automatisch ab, bündelt gleiche Fehler zu einem Eintrag statt tausend Einzelmeldungen und liefert gleich den vollständigen Kontext mit, also Stacktrace, betroffene Adresse, Browser und oft sogar die Eingabe, die den Fehler ausgelöst hat.

Der praktische Gewinn: Statt nachts im Log zu graben, bekommen Sie eine saubere Meldung mit allem, was Sie zur Behebung brauchen, und sehen sofort, ob ein Fehler einmal oder fünfhundertmal auftrat. Sentry lässt sich mit wenigen Zeilen in eine PHP-Anwendung einbinden und mit Monolog kombinieren, sodass Ihr strukturiertes Logging und das Fehler-Tracking Hand in Hand arbeiten. Es gibt einen kostenlosen Einstieg und die Möglichkeit, es auf dem eigenen Server zu betreiben, wenn die Daten das Haus nicht verlassen sollen.

Ebene 2: Monitoring - wie geht es dem System?

Während Logging in die Vergangenheit schaut, schaut Monitoring auf das Jetzt. Es misst kontinuierlich ein paar aussagekräftige Werte und macht sie sichtbar, meist als Kurve über die Zeit. Vier Kennzahlen genügen für den Anfang fast immer:

• Verfügbarkeit (Uptime): Antwortet die Anwendung überhaupt? Ein simpler Aufruf der Startseite alle paar Minuten reicht, um einen Komplettausfall sofort zu bemerken.
• Antwortzeit: Wie lange dauert eine typische Anfrage? Eine schleichend langsamer werdende Seite ist oft der erste Hinweis auf ein größeres Problem.
• Fehlerrate: Welcher Anteil der Anfragen endet mit einem Serverfehler? Ein Sprung von 0,1 auf 5 Prozent ist ein Alarmsignal, lange bevor jemand anruft.
• Ressourcen: Wie voll sind Festplatte, Arbeitsspeicher und CPU? Besonders der Plattenplatz ist ein Klassiker, der lautlos zum Stillstand führt.

Der Gesundheits-Endpunkt

Ein bewährtes und einfaches Mittel ist ein eigener Health-Check: eine kleine Adresse wie /health, die nicht die Webseite ausliefert, sondern in Sekundenbruchteilen prüft, ob die wichtigen Bausteine erreichbar sind, und das Ergebnis als kompaktes JSON zurückgibt.

// /health - von einem Monitoring-Dienst regelmäßig abgefragt
$checks = [
    'database' => $db->ping(),
    'cache'    => $cache->ping(),
    'storage'  => disk_free_space('/') > 1_000_000_000, // > 1 GB frei
];

$ok = !in_array(false, $checks, true);
http_response_code($ok ? 200 : 503);
header('Content-Type: application/json');
echo json_encode(['status' => $ok ? 'ok' : 'degraded', 'checks' => $checks]);

Ein externer Dienst ruft diese Adresse alle paar Minuten auf. Kommt eine 200 zurück, ist alles in Ordnung. Kommt eine 503 oder gar keine Antwort, weiß man sofort, welcher Baustein klemmt, ganz ohne sich einzuloggen. Das ist mit wenigen Zeilen gebaut und einer der besten Hebel überhaupt.

Werkzeuge fürs Monitoring

Den Health-Endpunkt regelmäßig abfragen, Werte über die Zeit sammeln und bei Auffälligkeiten warnen, das übernimmt ein Monitoring-Werkzeug. Für einen schnellen Start genügt ein externer Uptime-Dienst, der Ihre Seite von außen anpingt und meldet, wenn sie nicht antwortet. Wer es umfassender und im eigenen Haus haben will, greift zu einem etablierten System wie Nagios (oder seinen modernen Verwandten wie Icinga und Zabbix): Diese prüfen nicht nur, ob die Seite lebt, sondern überwachen ebenso Plattenplatz, Dienste, Datenbanken und Hintergrundprozesse auf Ihren Servern, mit einer langen Historie und flexiblen Schwellwerten. Für reine Kurven und Dashboards kombiniert man oft Prometheus zum Sammeln mit Grafana zur Darstellung. Womit man startet, hängt von der Größe ab, das Prinzip bleibt gleich: regelmäßig messen, sichtbar machen, bei Abweichung warnen.

Ebene 3: Alerts - muss ich jetzt handeln?

Logs und Monitoring sind wertlos, wenn niemand hineinschaut. Der letzte Baustein dreht das Prinzip um: Statt dass Sie nachsehen müssen, meldet sich das System bei Ihnen, aber nur dann, wenn es wirklich nötig ist.

Hier wird der häufigste und teuerste Fehler gemacht: zu viel alarmieren. Wer bei jeder Kleinigkeit eine E-Mail bekommt, schaltet nach einer Woche innerlich ab. Diese Alarm-Müdigkeit ist gefährlich, weil im Rauschen die eine Meldung untergeht, die zählt. Ein guter Alert erfüllt drei Bedingungen:

• Er ist umsetzbar. Es gibt eine konkrete Handlung. „Platte zu 95 Prozent voll" ist umsetzbar. „CPU bei 60 Prozent" ist meist nur Information.
• Er ist dringend. Alarmiert wird, was nicht bis morgen warten kann. Alles andere gehört in einen Bericht, nicht in eine Nacht-SMS.
• Er ist eindeutig. Aus der Meldung geht hervor, was betroffen ist und wo man nachschaut, nicht nur, dass irgendetwas „komisch" ist.

Lieber fünf Alerts, auf die Sie jedes Mal reagieren, als fünfzig, die Sie wegklicken. Stille ist hier ein Qualitätsmerkmal.

Gute Anlässe für einen echten Alert sind: Die Anwendung ist nicht erreichbar, die Fehlerrate schießt nach oben, der Plattenplatz wird knapp, oder ein zentraler Hintergrundprozess läuft nicht mehr. Am wirkungsvollsten laufen Alerts dorthin, wo Sie ohnehin hinschauen: in einen Chat-Kanal wie Mattermost oder per XMPP direkt aufs Handy. So liegt die Meldung im selben Fenster, in dem Sie sowieso arbeiten, statt in einem Postfach, das gerade niemand offen hat. Ich richte das gern so ein, dass die Systeme in genau den Messenger sprechen, den Sie im Alltag nutzen.

Die häufigsten Fehler im Betrieb

• Gar nicht beobachten. „Läuft doch" als Strategie. Der erste Ausfall, von dem ein Kunde erzählt, ist der teure Weckruf.
• Alles loggen, nichts strukturieren. Gigabyteweise Text, in dem im Ernstfall niemand das Entscheidende findet.
• Sensible Daten ins Log schreiben. Passwörter, Tokens oder vollständige Zahlungsdaten im Klartext sind ein Datenschutzproblem, kein Debug-Hilfsmittel.
• Zu laut alarmieren. Wenn alles ein Alarm ist, ist nichts mehr ein Alarm.
• Logs nie aufräumen. Ein volllaufendes Logverzeichnis legt am Ende genau das System lahm, das es überwachen sollte.

Ein pragmatischer Einstieg

Sie müssen nicht mit einer aufwändigen Monitoring-Landschaft starten. Eine sinnvolle Reihenfolge, die schon nach dem ersten Schritt einen spürbaren Unterschied macht:

1. Strukturiertes Logging mit einer Standardbibliothek einführen, mit Log-Leveln und Rotation. Das allein macht jede künftige Fehlersuche um Größenordnungen schneller.
2. Einen Health-Endpunkt bauen, der die wichtigsten Abhängigkeiten prüft.
3. Einen externen Uptime-Check einrichten, der diesen Endpunkt regelmäßig aufruft und bei Ausfall meldet.
4. Wenige, gezielte Alerts definieren: nicht erreichbar, Fehlerrate hoch, Platte voll.
5. Erst dann erweitern: zentrale Logsammlung, Dashboards, längere Datenhistorie, wenn das System und seine Bedeutung es rechtfertigen.

So entsteht ein System, das Ihnen Bescheid gibt, statt dass Sie raten müssen. Genau so baue ich Anwendungen: nicht nur bis zum „läuft auf meinem Rechner", sondern bis zum sicheren, beobachtbaren Betrieb, bei dem Sie und ich sehen, wenn etwas aus dem Ruder läuft, bevor es jemand anders tut.

Checkliste: Ist Ihre Webapp im Betrieb sichtbar?

• Schreibt die Anwendung strukturierte Logs mit sinnvollen Log-Leveln?
• Werden Logs rotiert und aufgeräumt, ohne die Platte zu fluten?
• Ist sichergestellt, dass keine Passwörter oder Zahlungsdaten im Log landen?
• Gibt es einen Health-Endpunkt, der die wichtigsten Abhängigkeiten prüft?
• Wird die Verfügbarkeit von außen regelmäßig gemessen?
• Bekommen Sie bei einem echten Problem eine eindeutige, umsetzbare Meldung?
• Erfahren Sie von Ausfällen zuerst vom System, nicht von Ihren Nutzern?

Fazit: Sehen, bevor es wehtut

Logging, Monitoring und Alerts sind keine Kür für große Konzerne, sondern die Grundausstattung jeder Anwendung, auf die sich ein Geschäft verlässt. Sie beantworten der Reihe nach drei Fragen: Was ist passiert, wie geht es dem System gerade, und muss ich jetzt handeln.

Der eigentliche Gewinn ist nicht technischer, sondern menschlicher Natur: ruhig schlafen, weil das System sich meldet, wenn etwas ist, und sonst still seine Arbeit tut. Sie tauschen die böse Überraschung gegen die rechtzeitige Warnung. Und das ist, gerade bei einer Anwendung, von der Ihr Betrieb abhängt, einer der besten Tausche, die es gibt.

---

Sie betreiben eine Webapp und wissen nicht so recht, was darin gerade passiert, oder Sie erfahren von Problemen immer erst durch Nutzer? Schreiben Sie mir kurz, worum es geht. Ich schaue mir an, wie Ihre Anwendung betrieben wird, und sage Ihnen, mit welchen wenigen Schritten Sie sie sichtbar machen.