Opentelemetry Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for observability. This bundle is a thin Symfony integration over the OpenTelemetry PHP SDK. It answers the "do we instrument ourselves, buy an APM agent, or adopt an open standard?" question in favor of the standard. The PM decision it unlocks is whether to standardize telemetry on OTLP now and defer (or avoid) a proprietary APM commitment.
• Vendor lock-in strategy. Because the bundle emits traces/metrics/logs through OTel rather than a vendor SDK, the backend (Datadog, Grafana/Tempo, Honeycomb, New Relic, self-hosted Collector) becomes a swappable decision rather than a three-year contract. This is a roadmap-level decision, not just an engineering one.
• Instrumentation scope for the roadmap. Auto-instrumentation of HTTP, DB, cache, and console gives you a baseline of golden signals without per-feature instrumentation tickets. As of v1.0.0-beta.7 this now extends to Symfony Messenger workers and middleware, which matters strategically: most PHP estates do their expensive, failure-prone work asynchronously. Queue/job tracing closes the last big blind spot in the baseline and moves observability from "we can see requests" to "we can see work." That reframes observability from "each squad adds their own logging" to "platform provides the baseline, squads add spans for business events."
• Async reliability is now in scope, not a later phase. Because worker and middleware spans ship in the same pipeline, "trace a slow checkout end-to-end across web and worker tier" becomes a near-term deliverable rather than a follow-on project. This is the single most useful change in this release for planning purposes: it collapses two roadmap items (baseline instrumentation, async visibility) into one.
• SLO and incident-response readiness. Traces + metrics + logs from one pipeline make it feasible to define SLIs/SLOs, run error-budget reviews, and cut mean-time-to-resolution. Queue-level spans materially improve MTTR for background-job failures, which are typically the slowest incidents to diagnose. These are prerequisites for any reliability roadmap item.
• Cost attribution and capacity planning. Metrics at the request/queue/job level feed per-tenant or per-feature cost and load analysis — useful input for pricing and scaling decisions. Worker-level instrumentation is what makes per-job cost visible at all.
• Maturity signal worth recording. The release is still beta.7 and consists mostly of CI/dependency chores, including a PHPUnit upgrade to clear security advisories. Read that as: maintained, security-hygienic, but explicitly pre-1.0. Budget for version pinning and API churn; do not plan a contract or a "set and forget" rollout on it yet.
• Important framework caveat for a Laravel shop. This package is Symfony-only; it is not a Laravel package and will not drop into a Laravel app. If your estate is Laravel, the real decision is "adopt open-telemetry/opentelemetry-php plus a Laravel adapter," and this bundle is at most a reference implementation for how a framework integration should look — including, now, a reference for how queue/worker instrumentation should behave. Do not let the "PHP package" label create a false fit, and do not assume the Messenger feature transfers to Laravel's queue worker model.

When to Consider This Package

Consider it when:

• The application is Symfony (5.4+/6.x/7.x era), not Laravel, and you want framework-level auto-instrumentation without writing a service provider by hand.
• You run asynchronous workloads on Symfony Messenger. This release's worker and middleware instrumentation is the strongest reason to look now: it gives you trace continuity from HTTP request through dispatched message to worker consumption, which is the hardest part of PHP tracing to build yourself.
• You already have, or plan to have, an OTel Collector and an OTLP-compatible backend. Without a collector/backend, this bundle produces telemetry nobody reads.
• Vendor neutrality is a stated requirement — multi-cloud, regulated procurement, or an active desire to avoid re-instrumenting during an APM migration.
• You want a low-commitment pilot: MIT-licensed, thin surface, easy to remove. Exit cost is roughly "delete the bundle and the exporter config."
• You have platform/ops capacity to own collector deployment, sampling policy, and retention costs.

Look elsewhere when:

• You are on Laravel. Evaluate open-telemetry/opentelemetry-php directly or a Laravel-specific adapter; this bundle is not the artifact you ship. Use the new Messenger instrumentation only as a design reference for your queue-worker spans.
• You need turnkey APM with curated dashboards, alerting, and support SLAs on day one. A managed APM buys you that; this bundle assumes you build it.
• Maturity risk is unacceptable. Still in beta (v1.0.0-beta.7), small community, no dependents: expect API churn, thin documentation, and a bus-factor concern. If you need a vendor to call during an outage, this is not that.
• Your team has no observability practice. Instrumentation without sampling strategy, cardinality discipline, or a query workflow reliably produces a large bill and no insight. Worker instrumentation increases span volume — plan sampling before rollout.
• You need deep, framework-specific auto-instrumentation for a complex or non-standard stack; a bundled commercial agent will cover more ground out of the box.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed integration that lets us emit industry-standard telemetry (traces, metrics, logs) from our PHP services into whatever monitoring backend we choose. The strategic value is optionality: we instrument once against an open standard and keep the ability to change vendors without a re-instrumentation project. It also gives us the data foundation for reliability targets and incident response. The latest release adds background-worker tracing, which means we can follow a single customer action across both the web request and the async jobs it triggers — typically where slow and failing work hides. Cost to trial is low and reversible. Two caveats to state plainly: the project is still pre-1.0, so we pin versions and avoid betting a contract on it; and this specific package targets Symfony, so if our services are Laravel we would adopt the same underlying standard through a different adapter — the strategic argument holds, the package does not.

To engineering: It is a thin Symfony bundle over the OpenTelemetry PHP SDK — no proprietary agent, no bytecode patching, standard OTLP export. You get auto-instrumentation for HTTP, database, cache, and console, plus manual spans where business context matters. New in beta.7: Messenger worker and middleware instrumentation, giving request-to-worker trace propagation out of the box — the piece you would otherwise hand-roll. The rest of the release is dependency and CI hygiene, including a PHPUnit bump to clear security advisories; no breaking changes called out, but the artifact is still beta, so pin exact versions and read changelogs before minor bumps. Risks to accept knowingly: small community (no dependents), so expect breaking changes and thin docs; we own the Collector, sampling, and cardinality policy, and worker spans will raise volume. Upside: a few lines of config and an exporter endpoint, and removing it is equally cheap. Recommend a single-service pilot with a defined success criterion — for example, "we can trace a slow checkout end-to-end from the HTTP request through the Messenger worker that fulfills it" — before any estate-wide rollout.