New Relic Bundle Laravel Package

Getting Started

Read this first: despite the name, this is a Symfony bundle, not a Laravel package. It has 1 star, 0 dependents, and a composer.json that targets Symfony 2/3/4-era constraints. Treat it as a reference implementation for "how do I push Symfony exceptions into New Relic," not as a dependency you install and forget.

Minimal steps:

1. Confirm you actually need it. The bundle exists solely to bridge Monolog/Symfony exception handling into the New Relic PHP agent (newrelic_notice_error()). If you already run newrelic APM, uncaught exceptions are captured automatically — this bundle only adds value for handled exceptions you want to surface in the NR Errors inbox.
2. Install the agent, not just the bundle. newrelic-php-agent must be compiled and newrelic.ini loaded (newrelic.appname, newrelic.license). Verify with:

   php -m | grep newrelic
   php -r 'var_dump(function_exists("newrelic_notice_error"));'
   

3. Install the bundle (only worth attempting on a legacy Symfony app):

   composer require zrgisa/new-relic-bundle
   

4. Register it. Symfony 3/4: add to app/AppKernel.php or config/bundles.php. There is no Flex recipe — you will hand-edit files. Read Resources/config/services.xml / DependencyInjection/ in the repo before wiring config; the README is thin.
5. First use case: route production E_ERROR/E_EXCEPTION-level Monolog records through the bundle's handler so they land in New Relic's Errors page with a stack trace, while debug/info stay out of NR entirely.

Implementation Patterns

Monolog handler pattern (primary integration). The bundle's real surface is a Monolog handler. Wire it in config/packages/monolog.yaml rather than relying on auto-registration, so you control which channels and levels hit New Relic:

# Symfony 5.3+ syntax; use the `main`/`prod` split on older versions
when@prod:
    monolog:
        handlers:
            newrelic:
                type: service
                id: zrgisa.new_relic.handler   # verify exact service id in the bundle
                level: error
                channels: ["!event", "!doctrine"]

Gate by exception type, not just level. Blanket-shipping every error record floods New Relic with NotFoundHttpException, CSRF failures, and validation 400s. Either add a FingersCrossedHandler/WhatFailureHandler in front, or subclass the bundle's handler and bail early:

protected function write(array $record): void
{
    $e = $record['context']['exception'] ?? null;
    if ($e instanceof HttpExceptionInterface && $e->getStatusCode() < 500) {
        return; // client error, not an incident
    }
    parent::write($record);
}

Enrich the event before shipping. Raw stack traces are useless without request context. Add custom parameters in a kernel.exception listener before the handler fires — the NR agent attaches them to the current transaction:

public function onKernelException(ExceptionEvent $event): void
{
    if (function_exists('newrelic_add_custom_parameter')) {
        newrelic_add_custom_parameter('user_id', $this->tokenStorage->getToken()?->getUserIdentifier());
        newrelic_add_custom_parameter('route', $event->getRequest()->attributes->get('_route'));
    }
}

Pair with deployment markers. The bundle does nothing for correlation. Call newrelic_record_deployment_marker() from your CI deploy step so error spikes map to releases — without this the bundle's value collapses during triage.

For Laravel (the actual ask): do not install this. Use report() in app/Exceptions/Handler.php (or the new bootstrap/app.php withExceptions) calling newrelic_notice_error($e) guarded by function_exists(), plus the laravel-newrelic/nr1-* packages for traces. That is ~15 lines and avoids a dead Symfony dependency tree entirely. The pattern transfers; the package does not.

For modern Symfony (6/7): skip the bundle. A 30-line custom Monolog handler calling newrelic_notice_error() is more maintainable and will survive composer update. The bundle's composer.json almost certainly pins symfony/symfony: ^2|^3|^4 and will block your upgrade path.

Gotchas and Tips

• Laravel incompatibility is the headline gotcha. No service provider, no config/app.php registration, no facade. Symfony Bundle base class. A Laravel developer installing this will get a class-not-found at boot or nothing at all.
• Silent no-op without the extension. newrelic_notice_error() doesn't exist unless the agent is compiled in. Most handlers of this vintage call it unguarded — you get a fatal in dev or a swallowed error in prod, depending on Monolog's bubble setting. Always wrap in function_exists('newrelic_notice_error') in your own code.
• newrelic.enabled = false still means the function exists but discards data. Don't use function_exists alone to verify it works — check the NR UI for an actual error entry with a matching timestamp.
• Version constraints will fight you. Expect php: ^5.6|^7.0 and Symfony 2/3/4 bounds. On PHP 8.2+ / Symfony 6+ composer require fails on platform requirements. Use --ignore-platform-reqs only to read the code as reference, never to deploy.
• Double reporting. If you also run Sentry, Rollbar, or Bugsnag, you will ship every exception twice and pay for both. Pick one primary error tracker; use the other for traces only.
• Monolog bubbling and duplication. FingersCrossedHandler buffering plus a NR handler on the same channel sends the buffered records too. Set bubble: false on the NR handler if it's the last in the chain, or scope with channels.
• Handler signature drift. The internal method changed from write(array $record) to write(LogRecord $record) in Monolog 3. If the bundle targets Monolog 1.x, it will fatal on Monolog 3 — another reason to vendor a copy rather than depend on it.
• No maintenance signal. 1 star, 0 dependents, no recent releases. Assume no security patches and no Symfony 7 support. Fork it, or better, copy the ~40 lines of handler logic into your own src/Monolog/NewRelicHandler.php and own it.
• Extension point worth knowing: the only genuinely reusable piece is the idea of a Monolog handler wrapping newrelic_notice_error($message, $exception) — the two-arg form preserves the stack trace; the one-arg string form loses it. Get the signature right or your NR errors are just strings.