PHP Observability from the team behind Pydantic: trace request-per-process apps, keep Composer vendor-neutral, and query everything in plain SQL. Standard OpenTelemetry, no lock-in.
Fetch and follow the instructions at https://pydantic.dev/agent-setup.md to set up Logfire for this project.
composer require open-telemetry/sdk open-telemetry/exporter-otlp php-http/guzzle7-adapterexport OTEL_PHP_AUTOLOAD_ENABLED=true
export OTEL_SERVICE_NAME=hello-php
export OTEL_EXPORTER_OTLP_ENDPOINT='https://logfire-us.pydantic.dev'
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=your-write-token'
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf<?php
require __DIR__ . '/vendor/autoload.php';
\OpenTelemetry\API\Globals::tracerProvider()
->getTracer('hello-php')
->spanBuilder('Hello World')
->startSpan()
->end();Full details are in the PHP setup guide.
Trusted by teams building production software and AI
What lands in Logfire:
{closure} that handles it, from the Slim auto-instrumentationcalculate-quote span, nested where it ran
The framework spans need the opentelemetry extension: pecl install opentelemetry, add
extension=opentelemetry.so to your php.ini, then install the auto-instrumentation package for your framework (open-telemetry/opentelemetry-auto-slim here). Your own spans work without it.
Start free with 10 million spans, logs, and metrics each month. No credit card required.
With OTEL_PHP_AUTOLOAD_ENABLED set to true, the SDK builds a tracer provider from your environment when the app loads and flushes it when the script ends. That last part matters more in PHP than anywhere else: the request-per-process model means a missed flush is lost telemetry, and autoloading removes that failure mode instead of leaving it to you.
Configuration is OTEL_ environment variables against the standard OpenTelemetry PHP SDK. Your composer.json contains OpenTelemetry packages and nothing of ours, so moving to a different backend is a config change rather than a migration.
Bring PHP request traces and any OTLP metrics or logs from the surrounding stack into one Logfire project. Shared service attributes keep the signals connected instead of splitting one incident across separate backends.
Use PostgreSQL-compatible SQL to compare PHP routes, status codes, database spans, and any attributes your instrumentation records. Turn the same query into a dashboard or alert when the question becomes part of operating the service.
If you can ask it, SQL can find out
select
attributes->>'http.route' as route,
count(*) as requests,
avg(duration) as avg_seconds
from records
where duration > 1
group by route
order by avg_seconds desc;You can tell that Pydantic Logfire was built by people who use it.
No. PHP uses the standard OpenTelemetry PHP SDK, and Logfire is the OTLP backend it exports to, so nothing proprietary enters your composer.json. First-party Logfire SDKs exist for Python, TypeScript, and Rust.
The OpenTelemetry OTLP exporter needs a PSR-18 HTTP client and does not bundle one. Install php-http/guzzle7-adapter, or any other PSR-18 implementation you prefer, alongside the SDK and exporter packages.
Autoloading is almost always the cause. With OTEL_PHP_AUTOLOAD_ENABLED set to true, the SDK builds a tracer provider from your environment variables when the app loads and flushes it when the script ends. Without it, no tracer provider is created and spans go nowhere.
PHP's HTTP client does not trust a private CA and ignores the OpenTelemetry certificate environment variable. Set openssl.cafile to your CA bundle in php.ini, or pass php -d openssl.cafile=/path/to/ca.pem when running.
No. Configuration is standard OTEL_ environment variables against the standard OpenTelemetry PHP SDK, and your code references OpenTelemetry APIs only. Repoint the endpoint at another OpenTelemetry-compatible backend, or at your own collector, whenever you want.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.