Newrelic Logger Bundle Laravel Package

Product Decisions This Supports

• Observability consolidation — one pane of glass or two? This package is a concrete data point on whether application logs should land in New Relic Logs beside traces and metrics, or stay in a separate stack (CloudWatch, Datadog Logs, ELK). Its existence answers the "how hard is this?" question: it's a thin Monolog handler that POSTs to the New Relic Logs API, i.e. configuration and glue, not a platform project.
• Build vs. buy vs. borrow. For a Laravel roadmap, this reframes the decision from "do we build a New Relic log shipper?" to "which maintained path do we standardize on, and who owns the config, PII policy, and ingest budget around it?" The package itself does not enter the answer; the pattern does.
• Log-in-context as a scoped feature commitment. Trace/span correlation (trace.id, span.id, entity linking) is what turns log search into a debugging workflow. That's a decision about incident MTTR and on-call ergonomics with a measurable target — not an infra footnote.
• Roadmap sizing for platform/observability work. Use it to enumerate the real line items: agent rollout, channel wiring, log level and sampling policy, PII redaction, ingest cost guardrails, fallback behavior. The library is the smallest item on that list, which is itself the useful finding.
• Ecosystem-fit evidence (a corrective). This is a Symfony bundle, not a Laravel package — no service provider, no config/logging.php driver, no auto-discovery. Its decision value for a Laravel team is largely negative: it confirms the integration is framework-agnostic at the Monolog layer, so the Laravel answer is a Monolog handler plus the official New Relic PHP agent.

When to Consider This Package

Consider reading it — not adopting it. With zero stars, zero dependents, and an archived repository, this is a reference implementation worth about fifteen minutes: it documents the New Relic Logs ingestion contract (payload shape, endpoint/region variants, entity enrichment, handler construction). Treat it as a specification, never as a dependency.

Adoption criteria it fails — and that any replacement must pass:

• Maintenance. Archived means no security patches, no PHP/Monolog compatibility fixes. For code in the request path of every service, that is a standing liability.
• Framework match. Symfony bundle ≠ Laravel package. There is no ServiceProvider, no logging channel driver, no Laravel ergonomics.
• Supported alternative exists. The New Relic PHP agent (or newrelic/monolog-enricher plus agent forwarding) covers the same ground with a vendor support contract and a security response process.
• Governance gaps. PII redaction, sampling and ingest cost caps, backpressure when the Logs API is slow or down, and multi-tenant routing have no home in a dormant micro-bundle.

Look elsewhere if: you're on Laravel (use the official agent-based path), you need Logs-in-Context correlation, you require vendor support or a security SLA, or you need any of the governance controls above. Consider the pattern only as a baseline when evaluating a polyglot estate that still runs legacy Symfony services.

How to Pitch It (Stakeholders)

To executives: We evaluated a community bundle for shipping application logs into New Relic. Recommendation: do not adopt it. It is archived, has no users, and receives no security updates — the cost of owning abandoned code in our request path far exceeds the one to two engineer-days it might save. The underlying integration is small and well understood: we can reach the same outcome on the vendor-supported path (New Relic PHP agent plus a standard Monolog handler) for a bounded, one-to-two-day effort per service. That delivers the actual business outcome — logs correlated with traces in a single tool, faster incident diagnosis, lower MTTR — without adding an unmaintained dependency.

To engineering: Keep the pattern, drop the dependency. The value here is the specification: a Monolog handler that batches records to the New Relic Logs API and stamps them with trace and span identifiers so logs link back to APM entities. Implement that against the official agent and the vendor's handler — or, only if agent installation is genuinely blocked, port the handler class into app/Logging/ behind a Laravel custom channel with a StreamHandler fallback, a sub-second timeout, a circuit breaker, and tests asserting the JSON envelope. Own the config in-repo, pin PHP and Monolog 3 versions, and treat log level, sampling, credential rotation, and PII redaction as first-class review items rather than defaults inherited from a dead library.