Opentelemetry Logger Monolog Laravel Package

Product Decisions This Supports

• Observability platform consolidation (build vs. buy). This package is the plumbing that lets a Laravel/PHP service emit logs into the same OpenTelemetry (OTel) pipeline already carrying traces and metrics. That makes "do we standardize on OTel + a backend (Grafana/Tempo, Datadog, Honeycomb, New Relic) or keep per-tool agents?" a decision you can actually cost out, because PHP logging is no longer the blocker.
• Log↔trace correlation as a roadmap item. Today most Laravel stacks give you logs with a request ID and traces with a trace ID that never meet. Adopting this handler is the cheapest credible path to attaching trace_id/span_id to every log record, which directly improves MTTR and reduces "which request caused this error?" triage time — a metric you can put in front of leadership.
• Vendor lock-in reduction. Monolog is the default logging abstraction in Laravel and Symfony. Routing it through OTel instead of a vendor SDK means the backend becomes a swappable export target rather than a code-level dependency.
• Buy-vs-build for an in-house handler. A competent PHP engineer can write a Monolog handler in a day. The decision this package informs is whether to own that code (and the OTel spec churn around the logs signal) or take the contrib package and accept its maturity risk. Useful input: it is a contrib package — community-maintained, not part of the OTel PHP core release guarantees.
• Use cases where this is the right lever: multi-service Laravel estates doing distributed tracing; teams already running an OTel Collector; regulated environments that want telemetry to leave the app through one standardized, auditable channel; migrations off a legacy APM agent where rewriting instrumentation is out of budget.
• What it should not drive: pricing negotiations with an APM vendor. At 9 stars and zero listed dependents, this is not evidence of market consensus — it's evidence of an early ecosystem.

When to Consider This Package

Consider it when:

• You have already committed to OpenTelemetry for traces (or are about to) in a PHP/Laravel service, and logs are the missing third signal.
• You run — or plan to run — an OTel Collector. Without a collector, a handler alone buys you very little.
• You need log-trace correlation and are unwilling to pay an APM vendor's per-host agent price to get it.
• You can absorb a contrib-tier dependency: pin the version, own a thin wrapper interface, and expect breaking changes as the OTel PHP logs signal stabilizes.
• Your team already debugs PHP observability issues; adding one more hop (Monolog → OTel SDK → exporter → collector → backend) is not a new operational burden class.

Look elsewhere when:

• You need a supported, SLA-backed dependency. Nine stars and zero dependents means no meaningful community escape hatch when you hit an edge case; a vendor agent or a maintained first-party SDK is the safer call.
• Logs are your only observability need. Plain Monolog with a structured JSON formatter gets you most of the value for none of the pipeline complexity.
• You are on a legacy PHP version or a framework with an older Monolog major — verify compatibility against your pinned Monolog version first; that is the single most likely integration failure.
• Your organization has no collector, no OTel owner, and no on-call story for the new pipeline. Tooling without ownership is a liability, not a capability.
• You need high-volume, high-cardinality log analytics today. OTel logs in PHP are comparatively young; validate throughput and cost-per-GB with a spike before committing a production service.

Recommended posture: time-boxed spike (1–2 sprints) on one non-critical service, behind a logging interface you control. Promote to a platform standard only after the OTel PHP logs signal and this package both show a stable release cadence.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our PHP services emit logs and traces into separate systems, so engineers manually stitch them together during incidents — that is real minutes-to-hours of downtime cost per event. This is a small open-source adapter that lets our existing Laravel logging library feed the same open standard (OpenTelemetry) our traces already use, so every log line carries the trace it belongs to and we can point that data at whichever vendor is cheapest. The strategic value is optionality: it turns our observability backend into a purchasing decision rather than an engineering rewrite. The risk is maturity — it is a low-adoption community package — so we propose validating it on one internal service before any wider commitment. Ask: two engineering weeks, no license cost.

For engineering (the practical case): Monolog is already our logging abstraction; this handler routes records into the OTel PHP SDK so logs join the same pipeline as traces and metrics, with trace context attached automatically. That means no per-vendor logging SDK, no bespoke correlation code, and a single Collector to configure, redact, and sample at. Accept the trade-offs explicitly: pin the version, wrap it behind our own LoggerInterface so a swap is a one-file change, and budget for churn — the OTel PHP logs signal and this contrib package are both pre-stable, and the near-zero dependent count means we are early adopters, not followers.

What I would want before signing off: a compatibility matrix against our Monolog and PHP versions, a measured overhead figure (CPU/latency per 1k log records) from the spike, and confirmation that whoever owns the Collector is funded.