Logging
To help you learn more about what's happening within your application, Laravel provides robust logging services that allow you to log messages to files, the system error log, and even to Slack to notify your entire team.
Under the hood, Laravel utilizes the library, which provides support for a variety of powerful log handlers. Laravel makes it a cinch to configure these handlers, allowing you to mix and match them to customize your application's log handling.
All of the configuration for your application's logging system is housed in the configuration file. This file allows you to configure your application's log channels, so be sure to review each of the available channels and their options. Of course, we'll review a few common options below.
By default, Laravel will use the stack
channel when logging messages. The stack
channel is used to aggregate multiple log channels into a single channel. For more information on building stacks, check out the .
Configuring The Channel Name
By default, Monolog is instantiated with a "channel name" that matches the current environment, such as production
or local
. To change this value, add a name
option to your channel's configuration:
Available Channel Drivers
Configuring The Slack Channel
The slack
channel requires a url
configuration option. This URL should match a URL for an that you have configured for your Slack team.
As previously mentioned, the stack
driver allows you to combine multiple channels into a single log channel. To illustrate how to use log stacks, let's take a look at an example configuration that you might see in a production application:
'channels' => [
'stack' => [
'driver' => 'stack',
'channels' => ['syslog', 'slack'],
],
'syslog' => [
'driver' => 'syslog',
'level' => 'debug',
],
'slack' => [
'driver' => 'slack',
'url' => env('LOG_SLACK_WEBHOOK_URL'),
'username' => 'Laravel Log',
'emoji' => ':boom:',
'level' => 'critical',
],
Let's dissect this configuration. First, notice our stack
channel aggregates two other channels via its channels
option: syslog
and slack
. So, when logging messages, both of these channels will have the opportunity to log the message.
Log Levels
So, imagine we log a message using the debug
method:
Log::debug('An informational message.');
Given our configuration, the syslog
channel will write the message to the system log; however, since the error message is not critical
or above, it will not be sent to Slack. However, if we log an emergency
message, it will be sent to both the system log and Slack since the emergency
level is above our minimum level threshold for both channels:
Log::emergency('The system is down!');
You may write information to the logs using the Log
. As previously mentioned, the logger provides the eight logging levels defined in the RFC 5424 specification: emergency, alert, critical, error, warning, notice, info and debug:
Log::emergency($message);
Log::alert($message);
Log::critical($message);
Log::error($message);
Log::warning($message);
Log::notice($message);
Log::info($message);
Log::debug($message);
So, you may call any of these methods to log a message for the corresponding level. By default, the message will be written to the default log channel as configured by your config/logging.php
configuration file:
Contextual Information
An array of contextual data may also be passed to the log methods. This contextual data will be formatted and displayed with the log message:
Log::info('User failed to login.', ['id' => $user->id]);
Sometimes you may wish to log a message to a channel other than your application's default channel. You may use the channel
method on the Log
facade to retrieve and log to any channel defined in your configuration file:
Log::channel('slack')->info('Something happened!');
If you would like to create an on-demand logging stack consisting of multiple channels, you may use the stack
method:
Log::stack(['single', 'slack'])->info('Something happened!');
To get started, define a tap
array on the channel's configuration. The tap
array should contain a list of classes that should have an opportunity to customize (or "tap" into) the Monolog instance after it is created:
'single' => [
'driver' => 'single',
'tap' => [App\Logging\CustomizeFormatter::class],
'level' => 'debug',
],
Once you have configured the tap
option on your channel, you're ready to define the class that will customize your Monolog instance. This class only needs a single method: __invoke
, which receives an instance. The Illuminate\Log\Logger
instance proxies all method calls to the underlying Monolog instance:
{tip} All of your "tap" classes are resolved by the , so any constructor dependencies they require will automatically be injected.
Monolog has a variety of . In some cases, the type of logger you wish to create is merely a Monolog driver with an instance of a specific handler. These channels can be created using the monolog
driver.
When using the monolog
driver, the handler
configuration option is used to specify which handler will be instantiated. Optionally, any constructor parameters the handler needs may be specified using the handler_with
configuration option:
'logentries' => [
'driver' => 'monolog',
'handler' => Monolog\Handler\SyslogUdpHandler::class,
'handler_with' => [
'host' => 'my.logentries.internal.datahubhost.company.com',
'port' => '10000',
],
],
Monolog Formatters
When using the monolog
driver, the Monolog LineFormatter
will be used as the default formatter. However, you may customize the type of formatter passed to the handler using the formatter
and formatter_with
configuration options:
'browser' => [
'driver' => 'monolog',
'handler' => Monolog\Handler\BrowserConsoleHandler::class,
'formatter' => Monolog\Formatter\HtmlFormatter::class,
'formatter_with' => [
'dateFormat' => 'Y-m-d',
],
],
If you are using a Monolog handler that is capable of providing its own formatter, you may set the value of the formatter
configuration option to default
:
'newrelic' => [
'driver' => 'monolog',
'handler' => Monolog\Handler\NewRelicHandler::class,
'formatter' => 'default',
],
If you would like to define an entirely custom channel in which you have full control over Monolog's instantiation and configuration, you may specify a custom
driver type in your config/logging.php
configuration file. Your configuration should include a via
option to point to the factory class which will be invoked to create the Monolog instance:
'channels' => [
'custom' => [
'driver' => 'custom',
'via' => App\Logging\CreateCustomLogger::class,
],
],
Once you have configured the channel, you're ready to define the class that will create your Monolog instance. This class only needs a single method: __invoke
, which should return the Monolog instance: