opentelemetry-php
OpenTelemetry PHP is the official PHP instrumentation library for the OpenTelemetry observability framework. It provides distributed tracing, metrics, and logging capabilities via a vendor-neutral API and SDK architecture, enabling integration with multiple telemetry backends.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | open-telemetry/opentelemetry-php |
| Owner | open-telemetry |
| Primary language | PHP |
| License | Apache-2.0 — OSI-approved |
| Stars | 901 |
| Forks | 227 |
| Open issues | 93 |
| Latest release | has-been-moved (2023-09-07) |
| Last updated | 2026-07-07 |
| Source | https://github.com/open-telemetry/opentelemetry-php |
What opentelemetry-php is
A monorepo-structured PHP library implementing the OpenTelemetry specification, offering core components (API, SDK, Context), exporters (OTLP, gRPC transport), and propagators (B3). Distributed as Composer packages with support for currently-supported PHP versions per php.net policy.
Get the opentelemetry-php source
Clone the repository and explore it locally.
git clone https://github.com/open-telemetry/opentelemetry-php.gitcd opentelemetry-php# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- This is a monorepo with multiple read-only package repositories; use Packagist for dependency management and version tracking of individual components (API, SDK, exporters).
- Instrumentation requires explicit API calls or auto-instrumentation via contrib packages; manual integration points across application code are common.
- SDK configuration (tracer providers, exporters, samplers) must be established early in application bootstrap; lazy initialization can complicate context propagation.
- Exporter choice (OTLP, gRPC, etc.) and backend selection (Jaeger, DataDog, Tempo) drive cost and latency; test export performance under load.
- PHP version support follows php.net EOL timeline; plan upgrades to avoid unsupported versions.
When to avoid it — and what to weigh
- Simple single-service applications — If you have a standalone PHP application with no service-to-service calls, the overhead of OpenTelemetry instrumentation may not justify the complexity.
- Existing monolithic logging pipeline — If your organization has a mature, proprietary logging and monitoring system with no plans to adopt OpenTelemetry ecosystem standards, this adds integration overhead.
- Minimal observability requirements — If basic error logs and application metrics suffice, OpenTelemetry's distributed tracing and context propagation are unnecessary infrastructure.
- PHP versions nearing end-of-life — The project drops support for PHP versions within 12 months of EOL; older versions may lack security updates and tooling support.
License & commercial use
Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved open-source license.
Apache-2.0 permits commercial use, modification, and distribution with standard liability disclaimers. Consult legal counsel for specific commercial deployment scenarios (e.g., bundling, SaaS offerings) to ensure compliance with attribution and notice requirements.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Strong |
| Assessment confidence | High |
As a telemetry library, consider that traces and metrics may contain sensitive data (credentials, PII, internal IPs). Implement proper span filtering, attribute redaction, and secure transport (gRPC/TLS) to backend collectors. Dependency security: audit transitive dependencies in exporters and transports. No security disclosures or audit information provided in data.
Alternatives to consider
Monolog + custom instrumentation
Simpler for single-service logging; does not provide distributed tracing or vendor-neutral metrics. Requires custom integration logic for multi-service scenarios.
DataDog APM PHP agent
Vendor-specific, often requires minimal code changes; tight integration with DataDog backend but introduces vendor lock-in and proprietary API.
New Relic PHP agent
Turnkey APM with auto-instrumentation; vendor lock-in and licensing costs, less flexible for polyglot or multi-backend observability stacks.
Build on opentelemetry-php with DEV.co software developers
Adopt OpenTelemetry PHP to gain vendor-neutral observability across your microservices. Start with official documentation and Packagist packages—no vendor lock-in.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
opentelemetry-php FAQ
Do I need to modify all my PHP code to use OpenTelemetry?
Which PHP versions are supported?
What is the performance impact of tracing?
How do I export traces to my backend (Jaeger, DataDog, etc.)?
Work with a software development agency
DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If opentelemetry-php is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.
Ready to instrument your PHP services?
Adopt OpenTelemetry PHP to gain vendor-neutral observability across your microservices. Start with official documentation and Packagist packages—no vendor lock-in.