Newrelic Bundle Laravel Package

Technical Evaluation

Architecture fit. Low for a Laravel codebase. Despite the "Laravel/PHP package" framing, this is a Symfony2 bundle (EkinoNewRelicBundle, forked by Webgriffe). Its structure is bundle-native: a Bundle subclass, a DependencyInjection extension with a Configuration tree, compiler passes, and a set of event subscribers (kernel.request, kernel.exception, kernel.console.*, Doctrine, Twig, Guzzle). None of that maps onto Laravel's ServiceProvider / middleware / event dispatcher model. Critically, the durable value is not the framework glue — it is roughly a dozen calls into the New Relic PHP agent (newrelic_name_transaction, newrelic_add_custom_parameter, newrelic_add_custom_tracer, newrelic_notice_error, newrelic_set_appname). Those are one-liners; ~80% of the package is Symfony2 wiring that would be discarded on a Laravel port.

Integration feasibility. Composer-installable in principle, not in practice. Expect hard constraints on symfony/symfony in the 2.x range, likely old Guzzle and sensio/framework-extra-bundle transitive requirements. composer require into a modern Laravel app will either fail resolution or pin dependencies we do not want. Realistic path is fork-and-rewrite, not consume-as-is.

Technical risk: high.

• Symfony 2.x has been end-of-life since 2018; the package has received no security or compatibility work for PHP 7.4+/8.x.
• 0 stars and 0 dependents is a strong orphan signal: no community testing surface, no downstream bug reports, no one to notice regressions.
• The package executes global newrelic_* functions. If the PHP extension is absent, unguarded calls fatal the request — a package-level outage vector in dev/CI or on a host where the agent was missed.
• Configuration-driven instrumentation fails silently: a misconfigured tree produces correct-looking requests with no telemetry, which is the worst failure mode for observability.

Key questions for the vendor/platform team.

1. Is this an intentional fork of ekino/EkinoNewRelicBundle with internal patches, or an untouched mirror? If untouched, the upstream project status is the real answer.
2. Is the New Relic PHP agent (and license) already provisioned in every environment, including CI and preview apps?
3. What is the actual requirement — APM transaction tracing, error aggregation, or log correlation? New Relic's own Laravel auto-instrumentation plus the OpenTelemetry bridge may cover it without a package.
4. Do we have a standing precedent for owning a fork of a third-party observability package, or is the policy "vendor-supported only"?
5. Who on the team has debugged the New Relic daemon and agent INI configuration before?

Recommendation. Treat this as a reference implementation, not a dependency. Harvest its transaction-naming conventions and listener coverage, then implement a thin in-house Laravel package or rely on native agent instrumentation. Adopting a zero-adoption Symfony2 bundle into a Laravel stack imports maintenance liability with no offsetting benefit.

Integration Approach

Stack fit. Poor by construction. Laravel's HTTP kernel, container bindings, exception handler, queue worker, and console kernel each need a different hook than the Symfony equivalents this package targets. Reusing the code is a rewrite with the original as a spec.

Migration path. Recommended sequence for porting the ideas rather than the code:

1. Extract the instrumentation inventory: which framework boundaries get a transaction name, which get custom parameters, which errors get reported with tags versus newrelic_notice_error.
2. Map each to the Laravel equivalent — HTTP route/controller naming in middleware, Illuminate\Contracts\Debug\ExceptionHandler for error reporting, Queue::before/after and JobProcessing/JobProcessed events for background transactions, Artisan::starting / command events for CLI, HTTP client middleware for outbound calls.
3. Wrap every agent call in function_exists() guards so absence of the extension degrades to a no-op rather than a 500.
4. Ship it as an internal package with a pinned agent API surface, not a fork we patch ad hoc.

Compatibility. The New Relic PHP agent function surface is stable and long-lived; the risk is the package's PHP/Symfony constraints, not the agent API. If the estate is mid-migration from Symfony to Laravel, matching transaction naming conventions matters — otherwise dashboards and alert policies split into two unrelated app names during the cutover.

Sequencing.

• Phase 0: confirm the agent is installed and reporting on every environment; verify the daemon is reachable and the app name is per-environment.
• Phase 1: enable native agent auto-instrumentation and measure coverage before writing any custom code. Many teams stop here.
• Phase 2: close gaps only where naming or business context is genuinely missing (tenant ID, customer tier, job class).
• Phase 3: if a Symfony estate still exists, keep the bundle there for consistency and align naming to the new Laravel instrumentation.

Do not attempt a dual-run where the bundle exists in a Laravel app "for reference." Dead code in a dependency tree still gets scanned, patched, and audited.

Operational Impact

Maintenance. The package is unmaintained; adopting it means we own the fork outright. Estimate one to two engineer-weeks for an initial Laravel port and roughly 0.1 FTE per quarter thereafter for agent upgrades, PHP version bumps, and Laravel major-version compatibility — a real cost against a ~50-line-per-concern internal package that would need less.

Support. No upstream to escalate to, no vendor SLA, no CVE feed. MIT license at least permits forking and internal redistribution. If something breaks during an incident, the on-call engineer debugs agent internals alone.

Scaling. Agent-side overhead is modest and largely off the request path, but two scaling concerns are real: (a) transaction-name cardinality — naming transactions on raw route templates with IDs, query strings, or job payloads explodes the metric namespace and inflates New Relic ingest cost; (b) custom parameters and custom metrics count against per-host data limits and can hit licensing ceilings in high-throughput services. Enforce a naming convention in code review, not in configuration.

Failure modes to design against.

• Extension missing or agent daemon unreachable → no telemetry, silent, discovered during the incident that needed it. Alert on "no data" per app, not just on error rates.
• Unguarded newrelic_* call → fatal error in dev, CI, or a host missed by provisioning.
• Wrong app name or environment suffix → split metrics, false-green dashboards.
• Config tree typo → no-op instrumentation with no error surfaced; validate configuration at boot.
• High-cardinality naming → cost spike, dashboard unusability.

Ramp-up. Low for the agent API itself (an afternoon for anyone who has read the New Relic PHP docs); medium for the bundle's listener topology and configuration tree; low for the Laravel replacement. A Laravel engineer can reproduce the useful 20% of this package in two to three days. A Symfony engineer can read the original in an hour but gains nothing transferable to a Laravel target beyond naming conventions. Net: the ramp-up cost exceeds the value of the dependency, which reinforces the reference-implementation approach.