Laravel New Relic
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
localin theconfig/new-relic.phpfile. 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
NewRelicMiddlewareon each request - CLI requests are filtered out for noise (so long-running calls like
php artisan horizonwon'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
- Improve the loggable transactions, make it clearer that HTTP transactions will end automatically
- Add some tests
- 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
License
The MIT License (MIT). Please see License File for more information.
5 May 21, 2022
11 Dec 7, 2022
2 Dec 15, 2017
24 Oct 4, 2022
4 May 8, 2022
5 Jun 1, 2023
2 Sep 30, 2022
28 Sep 3, 2022
726 Jan 1, 2023
0 Feb 22, 2022
442 Dec 8, 2022
71 Aug 12, 2022
188 Dec 28, 2022
356 Nov 26, 2022
48 Dec 30, 2022
12 Nov 13, 2022
1 Feb 25, 2022
5.8k Dec 20, 2022