Weave Code
Symfony Sdk Bundle Laravel Package
open-telemetry/symfony-sdk-bundle
Symfony bundle for integrating the OpenTelemetry PHP SDK into Symfony applications. It provides bundle configuration and container wiring for tracing, metrics, and logs, making it easier to instrument services and export telemetry through configured OpenTelemetry exporters such as OTLP.
A Symfony bundle that integrates the OpenTelemetry PHP SDK into Symfony applications, making it easy to add vendor-neutral observability to your services. It wires OpenTelemetry configuration, instrumentation, and exporters into the Symfony container so you can collect traces, metrics, and logs with minimal boilerplate.
- Automatic service/provider configuration via Symfony DI
- Support for OTLP exporters and custom span processors
- Auto-instrumentation hooks for requests, console commands, and HTTP clients
- Environment-driven settings for endpoints, headers, and resource attributes
- PSR-3 logging and context propagation integration
Frequently asked questions about Symfony Sdk Bundle
- Can I use open-telemetry/symfony-sdk-bundle in a Laravel application?
- No. The package is a Symfony bundle: it ships a Bundle class, a DI Extension::load() with a semantic configuration tree, compiler passes, and kernel.request/kernel.response/console event subscribers, none of which Laravel provides or consumes. Installing it would drag Symfony HttpKernel and its event lifecycle into your app, adding dependency weight and conflict risk. Laravel teams should depend on open-telemetry/sdk and the OpenTelemetry Laravel instrumentation packages instead.
- What does open-telemetry/symfony-sdk-bundle actually do?
- It integrates the OpenTelemetry PHP SDK into Symfony by exposing a configuration surface (service name, resource attributes, sampler, propagators, OTLP endpoint, headers, protocol, and batch processor tuning) and wiring the resulting tracer, meter, and logger providers as services. It also auto-registers framework instrumentation through kernel and console event subscribers. Its real value is that config-to-builder mapping and auto-registration, not the SDK itself, which is framework-agnostic.
- How do I install and configure the bundle in a Symfony app?
- Install it with composer require open-telemetry/symfony-sdk-bundle, register the bundle in config/bundles.php, then add its configuration key under config/packages/. The README is the source of truth for exact config key names and available options. Check the resolved open-telemetry/sdk version after install, since the bundle's constraint must line up with your other instrumentation packages.
- What is the Laravel equivalent of this bundle?
- There is no official Laravel port of this specific bundle. The correct stack is the upstream open-telemetry/sdk, open-telemetry/exporter-otlp, and open-telemetry/sem-conv packages, plus the Laravel instrumentation published by the OpenTelemetry PHP contrib org. Wire those into a single TelemetryServiceProvider backed by a config/telemetry.php file modeled on this bundle's configuration schema.
- Which exporters and protocols does it support, and do I need ext-grpc?
- Configuration typically covers OTLP over HTTP with protobuf and OTLP over gRPC, including the endpoint, headers, and protocol settings needed for a sidecar or collector topology. The gRPC transport requires the ext-grpc PHP extension, which affects your base image and deployment plan. Confirm the exact supported combinations in the bundle's configuration tree before you design infrastructure around it.
- What OpenTelemetry SDK version does it require, and how stable is the API?
- Check the bundle's composer.json for its open-telemetry/sdk constraint and verify it matches what your other instrumentation packages require, because a split constraint forces you to abandon one of them. The PHP SDK has historically shipped breaking changes across exporters, instrumentation registration, and propagator APIs. Pin versions tightly and treat upgrades as planned engineering work rather than routine maintenance.
- Does it instrument HTTP clients, PDO or Doctrine, and Messenger, and how does it behave in CLI and long-running workers?
- The bundle registers Symfony-side instrumentation that typically includes HTTP client middleware, Doctrine/PDO spans, and Messenger or console hooks, but verify exact coverage in the source. Those integrations depend on Symfony's event dispatcher and kernel lifecycle guarantees. If you port the ideas to Laravel you must handle middleware priority, Octane's long-lived workers with static state and span leakage between requests, and queue worker lifecycles yourself.
- Is this package production-ready, and how is it maintained?
- Signals are weak: roughly a dozen GitHub stars and zero dependents means effectively no production evidence and no de facto compatibility testing against real applications. Contrib repositories in the OpenTelemetry PHP org are volunteer-maintained with frequent turnover, so assume you own any fork you rely on. Also verify release dates on Packagist, because the scraped metadata for this package has been inconsistent.
- How do I configure sampling, resource attributes, and context propagation?
- The configuration tree exposes sampler selection such as parent-based or always-on, resource attributes like service.name and deployment environment, and propagators such as tracecontext and baggage. In Laravel you would mirror this in config/telemetry.php and build the SDK once in a singleton bound from a service provider. Set propagators explicitly, otherwise trace context will not cross HTTP or queue boundaries.
- How do I verify that traces, metrics, and logs actually reach my backend?
- Point the OTLP exporter at a local collector or an all-in-one Jaeger, Tempo, or Grafana stack and confirm spans appear end to end. For automated tests, use an in-memory or console exporter and assert on exported span names and attributes, and confirm batch processors flush on shutdown or on request and job termination. Always run one production-like check with real sampling enabled, since always-on sampling in tests hides tail-sampling and rate-limit problems.
Weaver
How can I help you explore Laravel packages today?