Weave Code
Sdk Laravel Package
open-telemetry/sdk
OpenTelemetry PHP SDK implements the OpenTelemetry API for generating and exporting traces, metrics, and logs. Use manual setup or the SDK builder, or enable autoloading via OTEL_PHP_AUTOLOAD_ENABLED to auto-register providers.
SDK for OpenTelemetry PHP.
Frequently asked questions about Sdk
- What does open-telemetry/sdk do in a Laravel application?
- It implements the OpenTelemetry API and SDK pipeline: providers, processors, samplers, exporters, and resource detectors for traces, metrics, and logs. In a Laravel app it is the vendor-neutral telemetry engine, not the Laravel integration. You still add instrumentation glue such as request middleware, queue or job hooks, and database query spans.
- Is open-telemetry/sdk a Laravel package or a framework integration?
- No. It is the vendor-neutral OpenTelemetry PHP SDK and has no framework coupling. Laravel-specific work such as a root span for the request kernel, queue and job spans, DB query spans, and exception recording is scope you own. That layering keeps instrumentation portable across frameworks and backends.
- How do I install open-telemetry/sdk in a Laravel project?
- Install it with Composer alongside an exporter and any instrumentation packages you need, because the SDK alone does not export telemetry. It has no PHP extension requirements and no framework coupling. Register the bootstrap code in bootstrap/app.php or a dedicated service provider.
- How does OTEL_PHP_AUTOLOAD_ENABLED work with the OpenTelemetry PHP SDK?
- Set OTEL_PHP_AUTOLOAD_ENABLED=true and provide all required SDK configuration through environment variables, php.ini, or OTEL_CONFIG_FILE. Composer's autoloader then attempts to create and register the SDK providers automatically. If autoloading is incomplete, Globals::tracerProvider() and Globals::meterProvider() can return no-op implementations.
- Do I need an exporter package in addition to open-telemetry/sdk?
- Yes. The SDK generates telemetry but delegates transport to separately versioned contributed exporters such as OTLP, console, or file exporters. Without an exporter and instrumentation, the SDK pipeline has nowhere to send spans, metrics, or logs. Plan adoption as API plus SDK plus exporter plus instrumentation glue.
- How do I configure open-telemetry/sdk manually or with the SDK Builder?
- Use manual setup when you want explicit control, or use the SDK Builder for programmatic wiring of providers, processors, samplers, exporters, and resources. In Laravel, put that wiring in a service provider or bootstrap/app.php. Environment-driven autoloading is the zero-application-code alternative when your configuration is complete.
- Why am I getting no traces even though open-telemetry/sdk is installed?
- The SDK can silently fall back to no-op implementations when autoloading fails or required configuration is incomplete. Nothing breaks, but you get no telemetry, so verify the OTEL_PHP_AUTOLOAD_ENABLED setting, required SDK variables, exporter setup, and instrumentation. Also confirm spans are flushed at request shutdown.
- Does open-telemetry/sdk handle Laravel Octane, queues, and PHP-FPM request lifecycles?
- In PHP-FPM each request is a fresh process, so batch processors and export queues only help if they are flushed at request shutdown; unflushed telemetry is dropped. Octane and Swoole change flush semantics, so validate behavior per worker and request. The SDK provides hooks such as onEnding, but Laravel queue and job span creation remains custom work.
- Which Laravel and PHP versions are supported, and how should I manage OpenTelemetry upgrades?
- The SDK is Composer-only and not tied to a Laravel version, so your application's PHP constraints and the OpenTelemetry family compatibility matter most. Upgrade open-telemetry/api, open-telemetry/sdk, exporters, and contributed instrumentation as a set because the SDK pins API and semantic convention versions. Expect periodic code sweeps for API churn such as removed propagators, deprecated event logging, and regenerated semantic conventions.
- How can I test or validate OpenTelemetry instrumentation in a Laravel app?
- Start with a console or local OTLP exporter and a collector you control, then assert that expected spans, metrics, and logs arrive. Confirm Globals::tracerProvider() and Globals::meterProvider() are not returning no-op implementations. For Laravel flows, test request middleware, queued jobs, and exception paths end to end, including the shutdown flush.
Weaver
How can I help you explore Laravel packages today?