PHP Monitoring und APM für Laravel und Symfony

Warum PHP Monitoring wichtig ist

PHP betreibt einen großen Teil des Webs: Onlineshops, Content-Plattformen, Kundenportale und APIs auf Basis von Laravel und Symfony. Das Ausführungsmodell ist einfach, ein Request pro Worker-Prozess, doch diese Einfachheit verdeckt zwei sehr unterschiedliche Fehlerbilder. Entweder ist der Code langsam, etwa wegen einer schweren Query oder einer externen API, oder der Pool der PHP-FPM-Worker ist voll und Requests warten, bevor überhaupt PHP-Code läuft. PHP Monitoring muss beides abdecken, sonst optimieren Teams den Code, obwohl die Kapazität das Problem ist, oder umgekehrt.

OpenTelemetry PHP ist für Traces, Metriken und Logs stabil. Die Auto-Instrumentierung basiert auf der PECL-Extension opentelemetry, über die sich Composer-Pakete in Framework- und Bibliotheksfunktionen einhängen. Mit OTEL_PHP_AUTOLOAD_ENABLED=true konfiguriert sich das SDK selbst aus Umgebungsvariablen. So wird PHP APM ohne Änderung am Anwendungscode möglich.

Die wichtigsten Signale für PHP Performance Monitoring

• Latenz und Fehler: Server-Spans je Route liefern Rate, Fehler und Dauer. Am Span erfasste Exceptions zeigen, was wo gebrochen ist.
• Datenbankzeit: PDO- und Doctrine-Spans zeigen, wie viel jedes Requests auf SQL entfällt und welche Statements dominieren.
• Externe Aufrufe: Guzzle- und cURL-Spans decken langsame Zahlungs-, Versand- oder Such-APIs auf.
• Worker-Kapazität: phpfpm_active_processes, phpfpm_idle_processes und phpfpm_listen_queue zeigen, ob der Pool mit dem Traffic Schritt hält. phpfpm_max_children_reached zählt, wie oft er an sein Limit stieß.
• Langsame und speicherhungrige Requests: phpfpm_slow_requests und phpfpm_process_last_request_memory weisen auf Endpoints hin, die Aufmerksamkeit brauchen.

Typische Performance-Probleme in PHP erkennen

Ausgelastete PHP-FPM-Pools

Sind alle Worker belegt, landen neue Requests in der Listen Queue. Die Latenz steigt für alle Endpoints gleichzeitig, während einzelne Traces unauffällig aussehen. Eine Listen Queue über null bei null freien Workern ist das typische Muster.

N+1-Queries in Eloquent und Doctrine

Lazy Loading von Relationen erzeugt eine Query pro Zeile. Im Trace-Wasserfall machen Dutzende fast identische PDO-Spans unter einem Request das Muster sofort sichtbar.

Langsame Drittanbieter-APIs

Ein synchroner Aufruf eines externen Dienstes blockiert den Worker für die gesamte Dauer. Client-Spans mit hoher Latenz zeigen die Abhängigkeit, weniger freie Worker zeigen die Folgen für die Kapazität.

Speicherlimits

Große Importe, Reports oder Bildverarbeitung können an memory_limit stoßen und in Fatal Errors enden. Der Spitzenspeicher je Request zeigt, welche Routen knapp davor liegen, bevor Nutzer Fehler sehen.

Langsame Queue-Worker

Laravel-Queue-Worker und Symfony-Messenger-Consumer laufen außerhalb des Web-Requests. Ihre Probleme bleiben deshalb oft verborgen, bis E-Mails, Exporte oder Webhooks verspätet ankommen. Spans für jeden verarbeiteten Job mit Dauer und Fehlern je Job-Klasse zeigen, welche Hintergrundarbeit langsamer wird und ob sie sich eine Datenbank mit dem Web-Tier teilt.

Kalte Caches nach Deployments

Nach einem Release sind OPcache und Anwendungs-Caches leer, die ersten Requests kompilieren Code und bauen die Konfiguration neu auf. Der Vergleich der Latenz je Release in den ersten Minuten trennt Aufwärmeffekte von echten Regressionen.

Best Practices für Laravel und Symfony Monitoring

1. Setzen Sie service.name und deployment.environment.name je Anwendung und trennen Sie Web-Worker von Queue-Workern.
2. Reichen Sie die OTEL-Variablen ausdrücklich an PHP-FPM weiter, etwa per env[...] in der Pool-Konfiguration, denn FPM leert die Umgebung standardmäßig.
3. Installieren Sie nur die Instrumentierungspakete, die Sie brauchen, um Overhead und Span-Volumen gering zu halten.
4. Aktivieren Sie FPM-Statusseite und Slowlog und alarmieren Sie auf wartende Requests statt nur auf CPU-Last.
5. Nutzen Sie Tail-based Sampling, um jeden langsamen oder fehlerhaften Request zu behalten.

So unterstützt Obseria PHP APM

Obseria empfängt Traces aus OpenTelemetry PHP per OTLP und liest PHP-FPM-Metriken über den Obseria Agent oder den OpenTelemetry Collector ein. TopoGraph verbindet Ihre PHP-Services mit Nginx, MySQL, Redis und externen APIs. Steigen die Antwortzeiten, unterscheidet Obseria Intelligence zwischen langsamem Code, langsamen Abhängigkeiten und erschöpften Worker-Pools und präsentiert die Ursache mit nachvollziehbarer Beweiskette. Dashboards, Alerts und SLOs sind inklusive, und alle Daten bleiben per OTLP exportierbar.