Newrelic Logger Bundle Laravel Package

Technical Evaluation

Architecture fit — not a Laravel package, and that is the decisive fact. ias/newrelic-logger-bundle is a Symfony bundle: a Bundle subclass, a DependencyInjection\Extension with a config tree, and a compiler pass that wires a Monolog handler into Symfony's monolog service definitions. Laravel has no bundle, extension, or compiler-pass concept. Composer-installing it into a Laravel app yields an inert package — no auto-discovery, no config/logging.php channel, no handler registration — while dragging symfony/http-kernel and symfony/dependency-injection into the dependency graph for a single handler class.

The one genuinely reusable artifact is the handler: an AbstractProcessingHandler subclass that formats records and POSTs them to the New Relic Logs API (log-api.newrelic.com/log/v1, EU variant log-api.eu.newrelic.com) with an ingest license key. That class is framework-agnostic and is the only thing worth extracting.

Integration feasibility — low for the package, medium for the pattern. For a TPM, the important move is to force a build-vs-buy-vs-configure decision before anyone writes code. New Relic's supported path for PHP logs is agent-based forwarding: emit structured JSON to stdout/file and let the New Relic PHP agent or infrastructure agent tail and forward it. That is zero custom code, vendor-supported, and inherits agent-side batching and backpressure. A second option is newrelic/monolog-enricher, which adds trace/span correlation to records rather than shipping them itself. A hand-rolled HTTP handler is defensible only when agent installation is impossible — locked-down containers, shared hosting, serverless.

Technical risk — high, concentrated in provenance. Archived status is decisive. Zero stars and zero dependents mean no downstream users have stress-tested it, no issue history exists to mine, no CVE feed covers it, and nobody will fix a Monolog 3 signature break or a New Relic API change. Secondary risks: synchronous per-record HTTP calls on the request path; license keys handled as plain config rather than secrets; regional endpoint mismatch silently dropping logs; PII leaving the perimeter into a third-party SaaS; and unbounded ingest cost absent sampling or level filtering.

Key questions for the team:

• Is there an actual observability gap, or does the New Relic PHP agent already cover log forwarding here?
• Do we have a hard constraint (container policy, hosting model) that prevents agent-based forwarding?
• Which New Relic region and account, and who owns license-key rotation and revocation?
• What is monthly log volume, and what is the acceptable ingest spend ceiling?
• Can the request path tolerate added latency, and what is the required degraded-mode behavior?
• Who is the named internal owner for a forked handler, and for how long?

Integration Approach

Stack fit. Target Laravel 9–11 on Monolog 3. Any port must be validated against Monolog 3's handler API (AbstractProcessingHandler::write() signature, LogRecord value object) — code written against Monolog 1/2 will not load. Confirm the transport (Guzzle vs. Symfony HttpClient) matches what the app already ships so the port does not introduce a second HTTP client.

Migration path. Do not add the bundle to composer.json. Three routes, in preference order:

1. Agent forwarding (recommended). Emit JSON to stderr/stdout via Laravel's Stderr/Single channel with a JSON formatter and let the New Relic agent forward. No custom code, vendor-supported, security-response coverage included.
2. Official enricher. newrelic/monolog-enricher plus agent forwarding, giving trace correlation without a bespoke sender.
3. Fork the handler. Copy the handler class into app/Logging/, wrap it in a Laravel custom channel driver registered via Log::extend(), add tests, and treat it as first-party code from that moment forward.

Compatibility. Pin PHP and Monolog versions in the fork's composer.json; add a contract test asserting a record reaches a mocked New Relic endpoint with the expected envelope (message, timestamp, service.name, attributes, trace.id/span.id). Verify TLS and proxy egress rules to the New Relic endpoint from every environment, including CI and staging.

Sequencing.

1. Confirm the observability gap and quantify current log volume per service.
2. Spike agent-based forwarding in staging; measure log-to-query latency and cost impact.
3. Only if the spike fails, port the handler behind a feature flag with a StreamHandler composed as a guaranteed fallback.
4. Canary one non-production service for a week; validate queryability, cost, and absence of latency regression.
5. Roll to production per service with an ingest-budget alarm and a documented kill switch to revert the channel.

Operational Impact

Maintenance. Archiving transfers all upkeep to us: an internal fork, a pinned version, vendoring or publication to a private registry, an assigned owner, and a calendar review tied to Monolog and PHP major upgrades. Small in hours, real in ownership — and it will be forgotten until it breaks at the worst possible time.

Support. No upstream maintainer, no escalation channel, no community to lean on. New Relic will support their Logs API; they will not debug our handler. MIT licensing permits the fork, which is the only reason this remains viable at all — and is exactly why the vendor-supported path is cheaper in practice.

Scaling. The dominant concern is that a synchronous HTTP POST per record couples request latency and reliability to a third-party SaaS. At meaningful volume this is untenable without batching (multi-record payloads), level filtering or sampling at the channel, async/queued flush, a sub-second timeout, and a circuit breaker that degrades silently to local logging rather than failing the request. Ingest volume also maps directly to spend — a runaway debug-level channel produces a surprising bill.

Failure modes to design for explicitly.

• New Relic API outage, 429 rate limiting, or 5xx — must never surface to the user request.
• License key rotation or expiry — currently a silent drop; alert on ingest volume falling to zero.
• Payload size limits — oversized records (stack traces, large context arrays) rejected; truncate before send.
• Memory growth from an unbounded in-process buffer.
• Regional endpoint misconfiguration — logs rejected or attributed to the wrong account.
• Log loss during deploy/restart when the buffer is in-process only.

Ramp-up. A senior Laravel engineer ports the handler and stands up the channel in one to two days including tests; the larger effort is New Relic agent and API configuration familiarity plus getting fallback and alerting right. The real constraint is evidential: a 0-star, 0-dependent, archived package carries no proof of having run in production anywhere, so every behavior must be verified rather than assumed. Recommendation to leadership: use it as a design reference for what the Monolog-to-New Relic contract looks like, and build or configure the real path on the vendor-supported route.