PHP-Monitoring und Logging: Fehler frühzeitig erkennen

Ihre Anwendung schweigt – ein schlechtes Zeichen

Haben Sie schon einmal von einem wütenden Nutzer von einem Bug im Live-System erfahren? Wenn ja, wissen Sie, wie weh das tut. Wenn nicht, haben Sie (noch) Glück gehabt.

PHP treibt 78% aller Websites weltweit an. Aber es hat eine Eigenheit: Es ist zu „leise“. Standardmäßig schluckt PHP einfach einen Fehler, zeigt eine weiße Seite oder, noch schlimmer, arbeitet mit fehlerhaften Daten weiter. Ohne ein System für Monitoring und Logging sind Sie blind.

In diesem Artikel zeigen wir Ihnen, wie Sie Ihre PHP-Anwendung von einer „Blackbox“ in ein transparentes System verwandeln, in dem jeder Fehler, jede langsame Anfrage und jede verdächtige Aktion festgehalten wird. Los geht's!

Warum „echo $error“ kein Logging ist

Viele Einsteiger schreiben:

try {\n    // irgendein Code\n} catch (Exception $e) {\n    echo $e->getMessage();\n}\n

Das ist kein Logging. Das ist ein Schrei ins Leere. Die Ausgabe im Browser wird nicht gespeichert, nicht strukturiert und liefert keinerlei Analyse. Echtes Logging bedeutet, dass Sie:

\n
• Einen Fehler innerhalb von 5 Minuten nach seinem Auftreten sehen
\n
• Verstehen, auf welchem Server und in welcher Umgebung er passiert ist
\n
• Tausende von Einträgen filtern und genau den richtigen finden
\n
• Eine Benachrichtigung in Telegram/Slack erhalten, wenn etwas kaputt ist
\n

Kommen wir zu den Tools, die das können.

Monolog – der De-facto-Standard für PHP

Wenn Sie PHP schreiben und Monolog nicht verwenden, erfinden Sie höchstwahrscheinlich das Rad neu. Diese Bibliothek ist zum Standard für Logging in PHP geworden (ja, Laravel und Symfony nutzen sie unter der Haube).

Installation und einfaches Beispiel

composer require monolog/monolog\n

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\n\n// Erstellen eines Log-Kanals\n$log = new Logger('my_app');\n// Schreiben in die Datei /var/log/my_app.log\n$log->pushHandler(new StreamHandler('/var/log/my_app.log', Logger::WARNING));\n\n// Verwendung\n$log->warning('Dies ist eine Warnung');\n$log->error('Kritischer Fehler: Datenbank nicht erreichbar');\n

Schon besser. Aber Monolog kann noch viel mehr. Sie können Logs gleichzeitig an verschiedene Ziele senden:

\n
• In eine Datei – für lokales Debugging
\n
• In Elasticsearch – für eine vollwertige Suche
\n
• An Telegram/Slack – für dringende Benachrichtigungen
\n
• In Syslog – für die Systemadministration
\n

Fortgeschrittenes Beispiel mit mehreren Handlern

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Handler\\ElasticsearchHandler;\nuse Monolog\\Formatter\\LineFormatter;\n\n$log = new Logger('production');\n\n// Alle Fehler in eine Datei schreiben\n$fileHandler = new StreamHandler('/var/log/app.log', Logger::DEBUG);\n$log->pushHandler($fileHandler);\n\n// Kritische Fehler sofort an Telegram\n$telegramHandler = new TelegramBotHandler(\n    'YOUR_BOT_TOKEN', \n    'YOUR_CHAT_ID', \n    Logger::CRITICAL\n);\n$telegramHandler->setFormatter(new LineFormatter(\n    "[%datetime%] %channel%.%level_name%: %message% %context%\\n"\n));\n$log->pushHandler($telegramHandler);\n\n// Loggen\n$log->critical('Datenbank ausgefallen', ['server' => gethostname()]);\n

Wenn jetzt nachts die Datenbank ausfällt, erfahren Sie es per Benachrichtigung auf Ihrem Handy – und nicht erst morgens vom Kunden.

Sentry – Fehlerüberwachung mit Kontext

Monolog schreibt hervorragend Logs, aber wenn die Fehlerzahl steigt, wird das reine Lesen von Dateien zur Qual. Hier kommt Sentry ins Spiel – ein System zur Fehlersammlung mit einer Weboberfläche.

Sentry sammelt automatisch:

\n
• Den Aufrufstapel (Stack Trace)
\n
• Anfragedaten (URL, Header, Body)
\n
• Benutzerinformationen (falls übergeben)
\n
• Den Zustand von Variablen
\n