- How do I install and configure overtrue/laravel-open-telemetry in a Laravel app?
- Install it with composer require overtrue/laravel-open-telemetry, then publish the package config with artisan vendor:publish and set your OTLP endpoint and headers through environment variables. Laravel package auto-discovery wires the service provider, and you need either ext-grpc with protobuf or an HTTP/protobuf exporter depending on your transport choice. Keep the integration behind an env flag so telemetry can be disabled in one place.
- Which Laravel and PHP versions does laravel-open-telemetry support?
- The package targets PHP 8.1+ and Laravel 9, 10, and 11, but confirm the current CI matrix and composer.json constraints before adopting it. Because it is pre-1.0, pin an exact version such as 0.0.32 instead of using a caret constraint like ^0.0. Check the repository release notes for any version-specific Laravel or PHP requirement changes.
- How do I send telemetry to Jaeger, Grafana Tempo, SigNoz, or Datadog via OTLP?
- The package emits OTLP telemetry, so point it at an OpenTelemetry Collector or an OTLP-compatible backend such as Grafana Tempo, Jaeger, SigNoz, or Datadog's OTLP endpoint. Configure the endpoint and headers through environment variables, and run the Collector as a sidecar or DaemonSet if you want backend-agnostic fan-out without re-instrumenting later.
- What Laravel features does the package instrument automatically?
- It wires the official OpenTelemetry PHP SDK into Laravel lifecycle events for HTTP kernel requests, DB and Redis activity, and queue jobs, emitting traces, metrics, and logs. Coverage is still settling: release 0.0.32 fixes export of monitoring information at the end of queue job execution, so validate scheduler, broadcasting, and long-running worker surfaces for your pinned version.
- How do I verify that traces, metrics, and logs are being exported?
- Send traffic to an instrumented route and inspect your OTLP backend or Collector logs for spans carrying your configured service.name resource attribute. For local checks, run a Collector with a debug or logging exporter and confirm that HTTP, DB, and queue spans arrive, then verify that disabling the package via env stops export.
- What is the performance overhead of OpenTelemetry in Laravel?
- Overhead depends on sampling rate and span volume, and DB query plus queue instrumentation can multiply spans quickly. Measure latency at 100% sampling for a representative endpoint mix, then use sampling and Collector-side processing to control both CPU cost and observability spend.
- Does laravel-open-telemetry work with Laravel Octane and long-running queue workers?
- The package is intended to work with standard Laravel and Octane, but long-lived processes need explicit validation. Test that spans are flushed and memory is released per request or job, and watch for state accumulation in queue workers under Octane or Swoole.
- Does it propagate trace context across queued jobs and nested dispatches?
- It instruments queue lifecycle events, and 0.0.32 specifically fixes export of monitoring information at the end of queue job execution. Confirm in your version that trace context propagates across dispatch() to worker to nested jobs, and test scheduler-invoked jobs separately because auto-instrumentation coverage may still have gaps.
- How do I configure sampling to control span volume and cost?
- Sampling is handled through the OpenTelemetry SDK configuration, so confirm which samplers such as parent-based, trace ID ratio, or custom are exposed in your pinned package and SDK version. Per-surface sampling for HTTP versus queue may require a custom sampler or Collector-side sampling, so start with a conservative ratio and tune using real span volume.
- Is overtrue/laravel-open-telemetry production-ready, how should I pin versions, and what are the alternatives?
- Treat it as pre-1.0 software: 0.0.32 is actively maintained but has no semver stability guarantee, and the upstream OpenTelemetry PHP SDK is not GA, so pin exact versions and be ready to fork or vendor if needed. It fits best when you already run an OTel Collector; if you already have a proprietary APM agent with auto-instrumentation, running both can add overhead. Also test exporter behavior when the Collector is unreachable to confirm whether it blocks, buffers, or drops and whether the batch queue is bounded. Alternatives include using the OpenTelemetry PHP SDK directly, a vendor APM agent, or Laravel Telescope for local debugging.