- Is jcchavezs/zipkin-instrumentation-symfony compatible with Laravel?
- No. This is a Symfony bundle that ships a Bundle class, DI extension and compiler passes, and kernel event subscribers — the framework layer Laravel does not consume. Laravel uses Symfony components such as HttpFoundation and EventDispatcher, not the Symfony Kernel or Bundle system. The reusable part is the underlying openzipkin/zipkin-php tracer, which you can wire into Laravel yourself.
- How do I add Zipkin tracing to a Laravel application?
- Do not install this bundle as a drop-in; you would need to reimplement its roughly 200 to 400 lines of wiring as a Laravel service provider plus middleware. Install openzipkin/zipkin-php instead and start a span in middleware handle(), finishing it in a terminable middleware or a finally block. For a future-proof path, use the OpenTelemetry PHP SDK with the Zipkin exporter and send traces through an OTel Collector.
- Which Laravel and PHP versions does this package support?
- It has no Laravel support matrix at all because it is a Symfony bundle. The last release was December 2021, which predates PHP 8.2 and 8.3 and Symfony 6 and 7, so Composer constraints will likely block modern runtimes. Audit its composer.json before assuming it installs on your target PHP and Laravel versions.
- Can I use openzipkin/zipkin-php directly in Laravel instead?
- Yes. The zipkin-php library is framework-agnostic and gives you the tracer, spans, B3 and W3C propagation, and HTTP reporters without any Symfony dependency. You bind a tracer in a service provider, open a span per request in middleware, and finish it on response. Sibling instrumentation such as the Guzzle middleware and PSR-18 wrapper also works in Laravel.
- Does this bundle trace Laravel queue jobs and Artisan commands?
- No. It instruments Symfony kernel.request and kernel.response events, plus Guzzle and Doctrine DBAL, and has no concept of Laravel queues or Artisan. In Laravel you would hook JobProcessing and JobProcessed for queued work, and CommandStarting and CommandFinished for console commands. Those are net-new spans you must build regardless of this package.
- Is this package actively maintained?
- Maintenance risk is high: it has around 27 stars, zero dependents, a single maintainer, and no release in over three years. Treat it as an unmaintained artifact and either fork it or, preferably, avoid it. The tracer it depends on is more useful than the bundle itself.
- What are the best alternatives for distributed tracing in Laravel?
- The preferred option is the OpenTelemetry PHP SDK with the Zipkin exporter, feeding an OTel Collector that can fan out to Zipkin, Tempo, or Jaeger. That gives you the same wire format plus a migration path to OTLP and vendor-neutral instrumentation. If you must stay Zipkin-native, use openzipkin/zipkin-php directly with a small Laravel service provider.
- Will this bundle work under Laravel Octane, Swoole, or RoadRunner?
- Not safely. The bundle assumes Symfony's request-scoped container and kernel lifecycle, which do not hold in long-lived workers. Spans and tracer state can leak between requests unless you explicitly reset or scope them per request and per job. If you run Octane, plan on custom lifecycle handling no matter which tracer you choose.
- How do I instrument Laravel's HTTP client with Zipkin?
- Laravel's HTTP client is Guzzle-based, so you can push the Guzzle middleware from openzipkin instrumentation onto the handler stack. Use Http::globalMiddleware() or configure it per client. This is a low-lift change and one of the few places where this package's approach maps cleanly onto Laravel.
- How do I test that Zipkin spans are created correctly in Laravel?
- This bundle ships no Laravel testing helpers. With zipkin-php you can inject a fake or in-memory reporter into the tracer and assert on recorded span names, tags, and durations in a PHPUnit or Pest test. If you use the OpenTelemetry SDK, its in-memory exporter gives you similar assertions with less custom code.