Laravel's Integrated Monolog library configures logs and records instances-PHP source code

This article introduces an example of how Laravel's Integrated Monolog library configures and records logs. This article introduces an example of how Laravel's Integrated Monolog library configures and records logs.

Script ec (2); script

For large systems, log is an indispensable module, and Laravel naturally provides complete support for logs. Laravel currently integrates a powerful Monolog library for logging. Next, let's take a general look at how to configure and use logs in Laravel.

1. Log processor Configuration

First, let's look at the configuration of the log processor. Laravel currently supports four log processors:

Single -- record logs to a single file. The log processor corresponds to the StreamHandler of Monolog.
Daily -- logs are archived by date. A new log file is created every day to record logs. The log processor corresponds to the RotatingFileHandler of Monolog.
Syslog -- logs to syslog. The log processor corresponds to SyslogHandler of Monolog.
Errorlog -- Record the log to the error_log of PHP. The log processor corresponds to the ErrorLogHandler of Monolog.

The actual log processor of the Project is determined by the log configuration item in config/app. php. The default configuration value is single. Here we use the default value without modifying it:

'Log' => 'singles ',

Of course, if these four methods cannot meet your needs, you can also use the configureMonologUsing method to completely control the Monolog log processor:

$ App-> configureMonologUsing (function ($ monolog ){
$ Monolog-> pushHandler (...);
});

Note: The above code must be placed before the bootstrap/app. php file returns $ app to take effect.
2. Use Log to record logs
After the configuration is complete, you can use the Log facade in the code to record logs. The Log facade is actually Illuminate \ Log \ Writer, and Monolog \ Logger is injected into the Writer constructor. The generated log files are stored in the storage/logs directory.

Currently, the Log facade supports eight Log levels (using the RFC 5424 standard ):

Log: emergency ($ error); // emergencies, such as system failure
Log: alert ($ error); // problems that require immediate action, such as full-site downtime and database exceptions, should be notified via SMS
Log: critical ($ error); // serious problem. For example, the application component is invalid and unexpected exceptions occur.
Log: error ($ error); // runtime error. It does not need to be processed immediately but must be recorded and monitored.
Log: warning ($ error); // warning but not an error. For example, an abandoned API is used.
Log: notice ($ error); // common but noteworthy events
Log: info ($ error); // events of interest, such as logon or logout
Log: debug ($ error); // detailed debugging information

Below we will demonstrate the log records at these log levels respectively, and we will test in the log method of TestController:

Public function log (){
Log: emergency ("system down ");
Log: alert ("database access exception ");
Log: critical ("unknown system error ");
Log: error ("the specified variable does not exist ");
Log: warning ("this method has been deprecated ");
Log: notice ("remote user logon ");
Log: info ("xxx login successful ");
Log: debug ("debugging information ");
}
Access the http://laravel.app in a browser: 8000/test/log, corresponding to the log information recorded in storage/logs/laravel. log is as follows:

[14:24:05] local. EMERGENCY: The system has crashed.
[14:24:05] local. ALERT: Database Access exception
[14:24:05] local. CRITICAL: The system encountered an unknown error.
[14:24:05] local. ERROR: the specified variable does not exist
[14:24:05] local. WARNING: This method has been deprecated
[14:24:05] local. NOTICE: users log on remotely
[14:24:05] local. INFO: User xxx logon successful
[14:24:05] local. DEBUG: debugging information

The corresponding log records include the log record time, log level, log message, and other information. Of course, we can also transmit context information when logging:

Log: info ("user xxx logon succeeded", ['user _ id' => 1]);
The corresponding log records are:

[14:25:47] local. INFO: User xxx login successful {"user_id": 1}

You can use the following method to access the underlying Monolog instance:

$ Monolog = Log: getMonolog ();
Dd ($ monolog );

We can view the attributes of the current Monolog object instance on the browser page:

We can see the currently used log processor, location of the log record, log record format, and other information.