PHP monitoring and APM for Laravel and Symfony

Why PHP monitoring matters

PHP runs a large part of the web: e-commerce shops, content platforms, customer portals and APIs built with Laravel and Symfony. The execution model is simple, one request per worker process, but that simplicity hides two very different failure modes. Either the code is slow, because of a heavy query or an external API, or the pool of PHP-FPM workers is full and requests wait before any PHP code runs. PHP monitoring has to cover both, or teams end up optimizing code when the real problem is capacity, or the other way around.

OpenTelemetry PHP is stable for traces, metrics and logs. Auto-instrumentation relies on the opentelemetry PECL extension, which lets Composer packages hook into framework and library functions. With OTEL_PHP_AUTOLOAD_ENABLED=true, the SDK configures itself from environment variables, which makes PHP APM possible without changing application code.

Signals that matter for PHP performance monitoring

• Request latency and errors: server spans per route give rate, errors and duration. Exceptions recorded on spans show what broke and where.
• Database time: PDO and Doctrine spans show how much of each request is spent in SQL, and which statements dominate.
• External calls: Guzzle and cURL spans reveal slow payment, shipping or search APIs.
• Worker capacity: phpfpm_active_processes, phpfpm_idle_processes and phpfpm_listen_queue tell you whether the pool keeps up with traffic. phpfpm_max_children_reached counts how often it hit the limit.
• Slow and memory-hungry requests: phpfpm_slow_requests and phpfpm_process_last_request_memory point to endpoints that need attention.

Common PHP performance problems and how to detect them

Saturated PHP-FPM pools

When all workers are busy, new requests sit in the listen queue. Latency rises for every endpoint at once, while traces of individual requests look normal. A non-zero listen queue together with zero idle workers is the fingerprint.

N+1 queries in Eloquent and Doctrine

Lazy loading of relations issues one query per row. In the trace waterfall, dozens of nearly identical PDO spans under one request make the pattern obvious.

Slow third-party APIs

A synchronous call to an external service blocks the worker for its full duration. Client spans with high latency show the dependency, and fewer idle workers show the knock-on effect on capacity.

Memory limits

Large imports, reports or image processing can hit memory_limit and end in fatal errors. Per-request peak memory reveals which routes come close before users see errors.

Slow queue workers

Laravel queue workers and Symfony Messenger consumers run outside the web request, so their problems often stay hidden until emails, exports or webhooks arrive late. Spans for each processed job, with duration and failures per job class, show which background work slows down and whether it shares a database with the web tier.

Cold caches after deploys

After a release, OPcache and application caches are empty, and the first requests compile code and rebuild configuration. Comparing latency per release over the first minutes separates warm-up effects from real regressions.

Best practices for Laravel and Symfony monitoring

1. Set service.name and deployment.environment.name per application, and separate web workers from queue workers.
2. Pass OTEL variables to PHP-FPM explicitly, for example with env[...] entries in the pool configuration, because FPM clears the environment by default.
3. Install only the instrumentation packages you need to keep overhead and span volume low.
4. Enable the FPM status page and slow log, and alert on queued requests rather than on CPU alone.
5. Use tail-based sampling to keep every slow or failed request.

How Obseria helps with PHP APM

Obseria receives OpenTelemetry PHP traces over OTLP and scrapes PHP-FPM metrics through the Obseria Agent or the OpenTelemetry Collector. TopoGraph connects your PHP services with Nginx, MySQL, Redis and external APIs. When response times rise, Obseria Intelligence distinguishes between slow code, slow dependencies and exhausted worker pools and presents the root cause with its chain of evidence. Dashboards, alerts and SLOs are included, and all data stays exportable via OTLP.