Opentelemetry Auto Symfony Laravel Package

Product Decisions This Supports

• Observability stack: build vs. buy. This package is the "build" half of the OTel-native vs. commercial-APM decision. It gives you framework-level traces (HTTP kernel, routing, console) without writing instrumentation, which is the main reason teams cave and buy a per-host agent (Datadog, New Relic, Sentry). Having a credible zero-code OTel path lets you price the buy option honestly.
• Vendor and exit-cost decisions. OTLP-native instrumentation means the backend becomes a swappable component (Collector → any vendor). This is a real lever in renewal negotiations and an argument against multi-year agent contracts.
• Roadmap sequencing for a PHP estate. Determines whether "distributed tracing across services" is a Q1 or Q4 item. With auto-instrumentation the cost drops from "instrument every controller" to "install extension, set env vars, validate spans" — typically a spike, not an epic.
• Monolith decomposition / strangler-fig migrations. Cross-service traces are the cheapest way to prove a extracted service is actually faster and to attribute latency regressions during cutover. This package covers the Symfony side of that comparison with near-zero engineering time.
• Incident-response investment (MTTR). Traces shorten "which of the 40 services is slow" from hours to minutes. That is a support-cost and on-call-burn decision, not just a tooling one.
• Standardization decision. Choosing OTel over a vendor SDK sets a durable internal standard for tracing/metrics/log correlation across polyglot teams (PHP, Go, Node), which matters more as the estate grows.

When to Consider This Package

Adopt when:

• You run a standard Symfony HttpKernel app (5.4 / 6.x / 7.x) behind a normal front controller, and you want traces without touching application code.
• You already have, or plan to stand up, an OpenTelemetry Collector — this package emits OTLP, it is not a backend.
• You can tolerate experimental status: PHP auto-instrumentation is younger than the Go/Java equivalents, span coverage is generic (framework-level), and you will still need manual spans for domain logic.
• You want a low-cost pilot on one non-critical service to build an internal case for broader tracing.

Look elsewhere or add scope when:

• You're on Laravel. This is Symfony-specific. Laravel reuses Symfony components but has its own kernel, container bootstrapping, and queue/scheduler lifecycle — this package will not give you framework-level Laravel spans. Budget for manual instrumentation or a Laravel-specific integration; do not let "it's PHP" collapse the distinction in planning.
• You run non-standard runtimes. RoadRunner, Swoole, FrankenPHP worker mode, or long-lived kernels need explicit validation — auto-instrumentation assumptions about request lifecycle often break there.
• You need vendor-backed SLAs. 58 stars and 0 dependents is a thin support surface; there is no commercial entity behind this repo. If a broken span is a P1, that risk is yours.
• You need deep domain observability (query-level DB insight, queue/job traces, business spans). You'll still write manual instrumentation; this only removes the boilerplate.
• Contribution is on your roadmap. The repo is READONLY — it's a subtree split of opentelemetry-php/contrib. PRs go upstream, and your release cadence is tied to that monorepo, not to this package.

Also worth flagging in diligence: the stated last release (2026-10-25) is ahead of wall-clock time, which suggests a metadata/automation artifact rather than a real ship date. Verify actual tag history before you commit to a version pin.

How to Pitch It (Stakeholders)

To executives: This is a free, open-standard instrumentation library that lets us collect performance traces from our Symfony services without buying per-host APM agents or writing code into every controller. It doesn't replace a monitoring vendor — it makes the vendor replaceable, which is where the leverage is at renewal. The realistic ask is a one-service, one-sprint pilot; the decision it informs is whether we standardize on OpenTelemetry across the PHP estate or renew an agent contract.

To engineering: composer require plus the OTel PHP extension and a few env vars gets you framework-level spans — request handling, routing, console commands — exported over OTLP to our Collector. It's zero-code and framework-native. Be clear-eyed: it's experimental, community-maintained with a small user base, the repo is a read-only mirror (fixes land upstream), and coverage is generic — anything domain-specific is still a manual span. So the pitch is "remove the boilerplate," not "observability is solved."

Rollout shape: pin a version, deploy to one low-risk service behind a feature flag, keep the existing agent running in parallel for a sprint, compare traces for coverage and overhead, then decide on the standard. Success criteria: end-to-end trace visible in the backend, <2% latency overhead, and at least one real incident where the trace cut diagnosis time.