Opentelemetry Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy on observability plumbing. The package covers the unglamorous 80% of instrumentation — HTTP kernel, Console, Messenger, Scheduler, Mailer, Doctrine DBAL, Cache, Twig, and outbound HTTP via HttpClient/Guzzle/PSR-18 — as a drop-in bundle. That lets you scope the "build" option down to your domain-specific spans instead of rebuilding framework glue.
• Vendor-neutrality as an explicit roadmap bet. Because it emits OpenTelemetry with stable semantic conventions, the decision to instrument is decoupled from the decision of where traces go (Datadog, Grafana/Tempo, Honeycomb, New Relic OTLP, self-hosted). This is the strongest strategic argument: it preserves optionality at renewal time.
• APM cost modeling. Pure-PHP with no C extension required means you can instrument environments where you cannot install agents (restricted containers, shared infrastructure, some PaaS runtimes). Compare per-host proprietary agent pricing against OTLP egress + backend storage before committing.
• MTTR and incident tooling roadmap. Monolog log correlation plus Messenger/Scheduler tracing directly targets the two questions that dominate incident response: "which async job failed, and what was its upstream request?" Quantify this as reduced time-to-diagnosis on async failures, not as "we have tracing now."
• Prioritizing which surfaces get instrumented first. The bundle's breadth is a menu, not a requirement. Use it to rank order: outbound HTTP + DBAL first (usually the latency budget), Messenger second (usually the blind spot), Twig/Cache last.
• Standardization across a polyglot PHP estate. If part of the org is Symfony and part is Laravel, this package is the reference implementation for what "good PHP instrumentation" looks like — which spans, which attributes, which naming. Evaluate Laravel-side equivalents against that bar rather than against a vendor agent.

Caveat worth raising in the room: this is a Symfony bundle, not a Laravel package. If your estate is Laravel-first, treat it as ecosystem signal and a design template, not a dependency. Adoption risk is also real: 86 stars and 0 dependents means essentially no production cohort to lean on.

When to Consider This Package

Adopt or pilot when:

• Your service is Symfony-based and you have (or are planning) an OTLP-compatible backend.
• You need async and background coverage — Messenger, Scheduler, Console — not just request/response tracing.
• You want Doctrine DBAL and outbound HTTP spans without writing middleware yourself.
• You operate in a no-C-extension environment, or you want to defer the ext-protobuf build dependency until benchmarks justify it (the package itself flags ext-protobuf as recommended for production — treat that as a required perf validation step, not a footnote).
• Log-trace correlation matters to your on-call workflow and you're already on Monolog.
• You want a thin wrapper over OpenTelemetry PHP rather than a proprietary SDK, and your team can absorb a small amount of instrumentation-ownership risk.

Look elsewhere when:

• You are Laravel-first. There is no Laravel auto-instrumentation here; you'd be assembling open-telemetry/opentelemetry-php plus community Laravel glue yourself.
• You need continuous profiling, code-level flame graphs, or deep runtime APM — those remain vendor-agent territory.
• You require a commercial SLA, support contract, or security-reviewed vendor. Zero dependents plus a small star count implies single-maintainer concentration risk; plan for the fork-and-own contingency before it becomes urgent.
• You run Octane/Swoole or very high-throughput services where pure-PHP instrumentation overhead needs hard numbers first. Benchmark before rollout, don't assume.
• Your org's bottleneck is dashboards and alerting, not telemetry collection. Instrumentation without a backend and a query practice is a cost with no return.

How to Pitch It (Stakeholders)

For executives: This is a ~MIT-licensed, no-cost instrumentation layer that makes our PHP services observable using an open standard instead of a vendor agent. The business case is threefold: (1) no lock-in — we can change observability vendors without re-instrumenting; (2) cost leverage — we stop paying per-host agent fees for the collection tier and negotiate only on the backend; (3) faster incident resolution — engineers can follow a single trace from an HTTP request through a queued job into the database, instead of correlating logs by hand. The trade-off is honest: it's a young, low-adoption project, so we should pilot on one or two non-critical services, benchmark the overhead, and be prepared to own a fork.

For engineering: It's a Symfony bundle that gives us HTTP, Console, Messenger, Scheduler, Mailer, Doctrine DBAL, Cache, Twig, and outbound HTTP (HttpClient/Guzzle/PSR-18) tracing for free, with opt-in metrics and Monolog correlation, using stable semantic conventions. No C extension required; ext-protobuf is recommended for production, so our pilot needs a before/after benchmark on p95 latency and memory. Realistic sequencing: outbound HTTP and DBAL first, Messenger second, the rest opportunistically. Budget for one engineer to own instrumentation quality and version pinning — 0 dependents means we are early, and being early is a resourcing decision, not just a technical one.