Zipkin Instrumentation Symfony Laravel Package

Product Decisions This Supports

• Observability build-vs-buy: Still a "buy" (free, MIT) shortcut to distributed tracing in PHP — but the real decision it informs remains whether Zipkin is our tracing backend at all, or whether we standardize on OpenTelemetry from day one. Release 3.1.0 does not change that strategic question; it only lowers the short-term cost of the Zipkin side of the comparison.
• Framework-fit / platform decision: It is a Symfony bundle, not a Laravel package — unchanged by this release. For a Laravel-first product this is still a "no" for direct adoption, but a useful data point when deciding whether to invest in a framework-agnostic tracing layer (OTel) versus framework-specific instrumentation per stack.
• Roadmap input for SLO/latency work: Distributed traces remain the prerequisite for cross-service latency SLOs, error-budget dashboards, and root-cause analysis on multi-service request paths — this package scopes that work for Symfony services in a mixed PHP estate.
• Reference design, not a dependency: The kernel/request-listener approach is a cheap template for our own tracing middleware if we build rather than adopt — worth a read even if we never install it.
• Vendor/backend flexibility: Choosing a Zipkin-compatible collector keeps Jaeger/Tempo options open, which affects procurement and infra roadmap decisions later.
• Maintenance-risk signal (updated): 3.1.0 is the first release since December 2021. That is a meaningful signal in both directions: the project is not fully abandoned, but a single low-cadence release after a multi-year gap is still not something to build a platform commitment on.

When to Consider This Package

Consider it when:

• The service is genuinely Symfony (not Laravel). The version pair has improved — 3.1.0 explicitly adds PHP 8.0 and 8.1 support and moves to Zipkin 3.0 for PHP 7.4/8.0/8.1 — so the 2021-era constraint is now less severe than previously assessed, though still behind current PHP.
• A Zipkin-compatible collector is already running in the estate — this is instrumentation, not a backend.
• You need minimal-effort request/HTTP-client spans for a short-lived internal service, and a small team can absorb the risk. The PHP 8.0/8.1 support makes this a more viable spike target than it was before.
• You want a low-cost spike to validate whether tracing produces actionable signal before committing budget to OTel.

Look elsewhere when:

• Laravel is the target — there is still no Laravel integration here; you'd need a custom middleware or a Laravel-specific/OTel path.
• You need current PHP 8.2/8.3 or Symfony 6/7 support. 3.1.0 tops out at PHP 8.1, and the release notes make no claim about Symfony 6/7 — verify the Symfony constraint in composer.json before planning around it.
• You need active maintenance, security patching, or an SLA — one maintainer, 0 dependents, 27 stars, and a ~multi-year release gap remains near-zero community validation; adopting makes us the de facto maintainer of a fork.
• You need OpenTelemetry (vendor-neutral SDK, auto-instrumentation, broader ecosystem, backend portability) — still the current industry default and the safer long-term bet.
• You need coverage of queues, console commands, or async workers, or trace propagation across non-HTTP boundaries — verify before assuming; the scope here is HTTP-request-shaped.

How to Pitch It (Stakeholders)

To executives: A small, free (MIT) Symfony add-on that emits distributed traces, so we can see where latency comes from in multi-service request flows instead of guessing. Cost to trial is a few engineering days. The release picture has improved slightly — a new version (3.1.0) landed adding PHP 8.0/8.1 support after a long quiet period — but the caveat is still material: single maintainer, no downstream users, and a release cadence measured in years. This remains a spike, not a platform commitment. Recommendation: run a short evaluation and benchmark it against OpenTelemetry PHP, which is the vendor-neutral industry default — we get the same answers with less long-term maintenance exposure and no lock-in to a specific tracing backend.

To engineering: Thin Zipkin instrumentation wired into the Symfony kernel/request lifecycle; gives us spans without hand-rolling a listener. 3.1.0 bumps the PHP matrix to 8.0/8.1 and pins Zipkin 3.0 for PHP 7.4/8.0/8.1 — so it is no longer frozen at a 2021 dependency set. Risks are still concrete: nothing above PHP 8.1, no stated Symfony 6/7 support, low cadence, and we'd be its first real adopter. Mitigation: either fork it or replicate the listener pattern on top of openzipkin/zipkin-php, and in all cases hide tracing behind our own internal interface so swapping to OTel later is a config change rather than a refactor across call sites.