Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Opentelemetry Bundle

Opentelemetry Bundle Laravel Package

friendsofopentelemetry/opentelemetry-bundle

Symfony bundle integrating OpenTelemetry PHP for distributed tracing, metrics, and logs with sensible defaults, configurable exporters, and easy instrumentation of requests, console commands, and services.

View on GitHub
Deep Wiki
Context7

OpenTelemetry Bundle integrates the official OpenTelemetry PHP SDK into Symfony, giving your application distributed tracing, metrics, and logging with minimal setup. It wires the SDK into Symfony's DI container with sensible defaults, so you get auto-instrumentation for HTTP requests, console commands, and HTTP clients without modifying application code.

  • Zero-code auto-instrumentation for the Symfony runtime
  • Configurable exporters (OTLP, console, and more)
  • Monolog and Doctrine integrations
  • Standard environment-variable configuration
  • Symfony Flex recipe and bundle configuration
Frequently asked questions about Opentelemetry Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib