Exporter Otlp Laravel Package

Product Decisions This Supports

• Observability strategy and roadmap: This package is the wire-format bridge that lets a PHP/Laravel service emit traces, metrics, and logs into any OTLP-compatible backend (Grafana, Honeycomb, Datadog, New Relic, AWS X-Ray via ADOT, Google Cloud Operations). Choosing it commits you to the OpenTelemetry standard rather than a vendor SDK, which is the single most consequential observability roadmap decision a PHP team makes.

• Build vs. buy (for instrumentation plumbing): You are deciding to buy into a spec rather than build a bespoke exporter. Writing your own OTLP client means maintaining protobuf serialization, HTTP/gRPC transport, retries, batching, and environment-variable conventions — all of which this package already implements and tracks against the OTLP spec. That is months of undifferentiated engineering avoided.

• Vendor flexibility / exit-cost reduction: Because OTLP is the interchange format, the collector layer (not the app) becomes the swapping point. Product can re-evaluate observability vendors on price or features without re-instrumenting the Laravel codebase — a genuine optionality argument for the roadmap.

• Feature prioritization: depth of tracing. Adoption unlocks decisions like "should we trace across our microservices?" and "do we instrument queue jobs, HTTP clients, and Eloquent queries?" — the package is a prerequisite for those conversations, not a substitute for them.

• Cost optimization of telemetry: Supports batch export and works with head/tail sampling configured upstream, which lets you control observability spend (per-span pricing is where vendors make margin) without per-request logging overhead.

• Compliance and audit trail scenarios: Structured, context-rich telemetry (user IDs, request IDs, resource attributes) supports audit and incident-forensics requirements typical of regulated SaaS and fintech products on Laravel.

• Make-vs-defer call on commercial APM: If the team is currently on a proprietary PHP APM, this package is the enabler for a "standardize first, choose backend second" migration path — worth sequencing before any 12-month vendor renewal.

When to Consider This Package

Adopt when:

• The Laravel app is already committed to the OpenTelemetry PHP SDK (open-telemetry/sdk, API packages) and needs the OTLP exporter to ship data to a collector or SaaS backend. This package is a component, not a standalone observability solution.
• You are running PHP 8.1+ (PHP 7.4 and 8.0 support has been dropped per the changelog) and can install the pecl install protobuf C extension in production. The pure-PHP protobuf fallback is documented as not recommended for production due to serialization cost — a real operational constraint for high-throughput Laravel apps.
• You want vendor-neutral, spec-compliant telemetry across more than one backend, or you plan to front it with an OpenTelemetry Collector.
• You value community-backed maintenance: Apache-2.0, part of the official open-telemetry/opentelemetry-php monorepo, with an active release cadence (the "last release 2023-09-07" metadata is stale — the changelog ships well beyond 1.4.0).

Look elsewhere (or add a wrapper layer) when:

• You want zero-config, Laravel-native observability — out of the box. This package is a transport/primitives library with a thin README and one usage example. You still need to wire the SDK, providers, spans, and instrumentation manually, or adopt a Laravel wrapper such as laravel-otel / a vendor Laravel package on top. For a small team without dedicated platform engineering, the wrapper is the real adoption unit.
• You cannot add a C extension to the production/runtime image (managed PaaS, locked-down shared hosting, restrictive PHP runtime) — performance will be a concern at scale.
• Your primary need is error tracking or product analytics, not distributed tracing — a purpose-built APM/tool is faster to value.
• The workload is a single monolith with no distributed context — the OTLP/collector architecture may be over-engineered versus simple application logs and a hosted error tracker.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is the piece that lets our Laravel applications report performance and reliability data in a standard format that every major observability vendor understands. It is free, open-source (Apache-2.0), and maintained by the OpenTelemetry project rather than a single vendor — meaning we can change monitoring providers later without re-instrumenting the product, and we avoid building and maintaining our own telemetry plumbing. The trade-off is a small amount of platform work (runtime dependency and configuration), so it should be sequenced as part of an observability initiative, not adopted in isolation.

For engineering: open-telemetry/exporter-otlp is the OTLP transport layer for the OpenTelemetry PHP SDK — it serializes traces, metrics, and logs to protobuf and ships them over HTTP/JSON or gRPC to a collector or OTLP endpoint. It is spec-compliant and part of the official monorepo, so behaviour follows the OpenTelemetry spec and environment-variable conventions (OTEL_EXPORTER_OTLP_*) rather than inventing its own. Plan for: (1) pecl install protobuf in the production image for acceptable performance, (2) an exporter + transport factory wired into the tracer/meter/logger providers and a Resource describing the service, and (3) a collector in the pipeline if we want backend flexibility. It is a library, not a framework — budget integration work or pick a Laravel wrapper if we want configuration-free adoption. The exporter-otlp package tracks the spec actively (recent releases include file exporters, timeout support, min/max histogram data, and config-file support); we should pin versions and watch the changelog for spec-version bumps.