README

This package makes it simple to set up and monitor your Laravel application with New Relic APM.

New Relic provides some excellent low-level insights into your application. The New Relic PHP agent is particularly useful in production environments, as it hooks in at a lower level than other monitoring services, and with little to no impact on performance.

New Relic has a fully-featured free plan which is ideal for growing Laravel applications. This package isn't affiliated with them — I just built it because I've found the service very helpful whilst scaling my app, and wanted a more tailored solution for Laravel.

Whilst New Relic can monitor a Laravel application out-of-the-box, this package reports transactions that are optimised for Laravel, and reported in a more consisted way.

Installation

To monitor your application in production you'll need a New Relic API account, and you should install the PHP monitoring agent. You don't need to install New Relic in your development environment (unless you really want to). If the extension isn't detected the package will simulate calls to the New Relic PHP agent, and log each one so you can test before deploying.

If you're installing this on a server which is already being monitored by New Relic, be aware this package reports transactions with different naming conventions than New Relic normally auto-detects. If your existing New Relic data is very important to you, don't install this.

To install the package, add it to your Laravel project with Composer:

composer require jackwh/laravel-new-relic

Then publish the config file:

php artisan vendor:publish --provider="JackWH\LaravelNewRelic\LaravelNewRelicServiceProvider"

That's it, you're done! The package is ready to go, and configured out-of-the-box.

How It Works

The Service Provider

Laravel will auto-discover the LaravelNewRelicServiceProvider class, which binds NewRelicTransactionHandler and NewRelicTransaction classes as scoped singletons to the service container.

New Relic's transaction API only allows a single transaction to be active at a time. That's why the classes are loaded as singletons. Generally speaking, don't try to start a new transaction mid-way through the request lifecycle.

Loggable Environments

The package checks if New Relic is installed. If it's not found, you can log simulated transactions.

In a loggable environment, the package will simulate calls it would normally make to New Relic's methods (e.g. newrelic_start_transaction()). These are loaded from the LoggableNewRelicFunctions.php helper file. You can check your logs to see what's happening under the hood.

Don't worry if your logs don't show a "transaction ended" item, as New Relic automatically finishes them at the end of a request. This is only really important for long-running processes, like the queue handler.

Once you're happy logging is working as expected, you can comment out local in the config/new-relic.php file. This is just intended to help you check the package is working before initial deployment, or when making changes which would affect New Relic transactions.

Live Environments

Assuming the New Relic extension is loaded, the package sets up hooks into Laravel to monitor requests at different stages of the lifecycle:

• HTTP transactions are handled with a global NewRelicMiddleware on each request
• CLI requests are filtered out for noise (so long-running calls like php artisan horizon won't skew your stats).
• Queued jobs record a transaction automatically as each one starts and ends.
• Artisan commands are recorded as individual transactions.
• Scheduled tasks are monitored as each one is executed.

The package also registers a php artisan new-relic:deploy command, to notify New Relic of changes as part of your deployment process.

Configuration

The configuration file is documented in detail — read through each comment to understand how it will affect transaction reporting. A few settings worth pointing out here are below:

HTTP Requests

'http'         => [
    'middleware' => \JackWH\LaravelNewRelic\Middleware\NewRelicMiddleware::class,

    // ...

    'rewrite' => [
        '/livewire/livewire.js'     => 'livewire.js',
        '/livewire/livewire.js.map' => 'livewire.js.map',
    ],

    // ...

    'ignore' => [
        'debugbar.**',
        'horizon.**',
        'telescope.**',
    ],
],

The built-in NewRelicMiddleware class should be fine for most use cases, but you can extend it with your own implementation if needed.

The rewrite key is useful for routes which don't have names defined (often the case with packages that expose public resources, like Livewire). You can rewrite their names for consistency here.

We've set some sensible ignore rules by default, feel free to adjust as required.

Queue Handling

'queue'        => [
    'ignore' => [
        'connections' => ['sync'],
        'queues'      => [],
        'jobs'        => [],
    ],
],

By default the sync connection will be ignored. This means a new job starting on this queue won't interrupt the existing transaction that started at the beginning of the request. You can also filter out specific queues and jobs, too.

Deployments

After each new deployment, you should notify New Relic so they can report on metric variances across multiple releases. The package includes a command to do this:

php artisan new-relic:deploy [description] [revision]

If you don't provide a git revision hash, the package can attempt to auto-detect it by calling git log --pretty="%H" -n1 HEAD

To-Do

1. Improve the loggable transactions, make it clearer that HTTP transactions will end automatically
2. Add some tests
3. Hopefully someone can confirm if this works with Octane?

Contributing

All contributions are welcome! And if you found this useful, I'd love to know.

Credits

• Jack Webb-Heller
• All Contributors

License

The MIT License (MIT). Please see License File for more information.