- Does friendsofopentelemetry/opentelemetry-bundle work with Laravel?
- No. It is a Symfony bundle, not a Laravel package, and Laravel never registers Symfony bundles, so there is no boot path for it in a Laravel application even though Laravel consumes some Symfony components. The bundle's value is the Symfony-specific glue: compiler passes and decorators for the HTTP kernel, HttpClient, Messenger, Console, Doctrine and Twig. The portable part is the underlying open-telemetry/opentelemetry-php SDK plus contrib instrumentation, which you would wire yourself. Treat this bundle as a reference implementation, not a dependency.
- What is the Laravel alternative to this OpenTelemetry bundle?
- There is no official Laravel port. The usual starting points are keepsuit/laravel-opentelemetry, the open-telemetry/opentelemetry-php-contrib packages, or a thin in-house ServiceProvider plus middleware around the SDK. Compare release cadence, Laravel version support and how each handles queue propagation before committing. For most teams the realistic path is SDK plus contrib instrumentation with your own Laravel wiring.
- How do I install and configure the OpenTelemetry bundle in Symfony?
- Composer require the bundle, register it in bundles.php, and point the OTLP exporter at your collector in the bundle config tree. Set resource attributes such as service.name, deployment.environment and service.version so telemetry is attributable in the backend. Enable instrumentation one decorator at a time rather than all at once, so a break is easy to isolate. Pin the bundle, SDK and contrib instrumentation versions together.
- Which Symfony and PHP versions does this OpenTelemetry bundle support?
- The realistic target is Symfony 6.4 and 7.x on PHP 8.1 or newer. Check the repository CI matrix for the exact Symfony and PHP combinations tested, and confirm behaviour on the PHP version you actually deploy rather than the CI floor. The OTel PHP SDK and contrib instrumentation have moved through breaking majors, so pin exact versions instead of floating them. A minor Symfony bump can silently break a decorator without a failing test on your side.
- What does the bundle auto-instrument out of the box?
- It decorates the HTTP kernel, PSR-18 and Symfony HttpClient, Messenger, Console, Doctrine and Twig. That is Symfony glue around the framework-agnostic SDK, which is exactly why the value does not transfer to Laravel. Because auto-instrumentation hooks framework internals, a framework upgrade can break a decorator and telemetry simply goes dark. Keep a smoke test that asserts spans actually reach the backend.
- How do I export telemetry to an OTLP backend like Tempo, Jaeger or a vendor APM?
- Configure the OTLP exporter in the bundle config and point it at your collector endpoint, choosing HTTP or gRPC depending on backend support. Validate against the exact collector version you run and confirm the backend accepts your protocol choice. Use the batch span processor outside of local debugging, and agree on a resource attribute schema before rolling out. Keeping the collector as the single egress point makes swapping backends far easier.
- Does this bundle respect the OTEL_* environment variable specification?
- That is one of the first things to verify before adopting it. If the bundle's config tree diverges from OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_TRACES_SAMPLER and the resource attribute conventions, your platform-level collector and sampling configuration stops being the source of truth. Test an env-var-only setup explicitly rather than assuming it works. For a Laravel adapter, prefer SDK-level configuration so the setup stays portable.
- How do I propagate trace context across queue workers and console commands?
- The bundle instruments Messenger and Console, but the real check is whether context is serialized into job payloads or message headers and restored in the worker. Long-running console processes need spans ended explicitly, or batches may flush late or not at all. Verify trace continuity end to end in the backend, not just on the request path. This is the same problem you would solve in Laravel with middleware and job lifecycle hooks.
- What is the performance overhead of running OpenTelemetry in Symfony or Laravel?
- With the batch span processor and modest head sampling the per-request overhead is usually small, but measure it against your own endpoints instead of trusting generic benchmarks. Start with a conservative sampling ratio and tune from real data. Watch for unbounded span attributes and for tracing high-volume, low-value routes. Gate each rollout phase on measured overhead and confirmed trace continuity.
- Is friendsofopentelemetry/opentelemetry-bundle actively maintained and safe for production?
- It is a young project with roughly 68 GitHub stars, no dependents and a small maintainer pool, so bus factor is effectively one or two people. That is not a quality verdict, but it does mean unproven operational history, so pin exact versions and keep a fallback plan. Sanity-check the repository tags directly rather than trusting any stated last-release date. If you need a Laravel setup, prefer a maintained Laravel-specific package or own the thin adapter yourself.