Laravel in Production – Logging

Tram Ho

LARAVEL – Logging

Following the series about laravel in production , this article I will share about the implementation of log on laravel server.

1. Introduction to laravel logging

Imagine, one fine day, you are sipping a cup of coffee and chill to the tune you love. BOOM , you received an error điều tra ticket and you need to answer: why did it happen, how much impact is it, how do you handle it? Okie, that’s simple, let’s check the log . After reading the logs on the server, filter the types. You realize, there is no log required to investigate cái lỗi này

The above is just one case có thể have encountered while working. And after ticket investigation, almost all of us realize the importance of log and ghi lại the necessary information to serve investigation as well as tracing errors.

Fortunately, in laravel, logging is quite simple.

Log level

By default, laravel supports the following log levels: emergency , alert , critical , error , warning , notice , info , debug Depending on mức độ you will choose the appropriate level to log.

Log driver

According to laravel documentation, laravel supports the following channels:

stackA wrapper to facilitate creating “multi-channel” channels
singleA single file or path based logger channel (StreamHandler)
dailyA RotatingFileHandler based Monolog driver which rotates daily
slackA SlackWebhookHandler based Monolog driver
papertrailA SyslogUdpHandler based Monolog driver
syslogA SyslogHandler based Monolog driver
errorlogA ErrorLogHandler based Monolog driver
monologA Monolog factory driver that may use any supported Monolog handler
customA driver that calls a specified factory to create a channel

Note: You can understand that the driver is the method that we will record the log

For example:

  • single: you will write the log of each day to 1 file
  • slack: you will send log into a slack channel

2. Logging in production

How to use log is quite simple, however, where to put the log, what information to log, we have a headache. If we log all information, it will be too wasteful of the system’s resources. Log is incomplete, in the wrong place, we do not have enough data for investigation.

Here are some of the things that I have learned in the process of working with logs in real projects


Oh, there is nothing wrong with permission to pay attention: lol:

Setting permissions for the incorrect log files will significantly affect a number of tasks related to log files. Eg:

  • Saving. For some projects, you store logs on the server, not using 3rd party services to manage logs. So to optimize system resources, we often have to run tasks to zip, move files to another server for storage.
  • Deploying. The deployment of the current system, we often use the tool support like rocketeer , deployer , capistrano . The storage directory – usually where you store logs – is the directory that is usually shared between releases and servers (in case the system runs multiple servers). So, if you don’t set the right permissions, you will get an error when doing auto-deploy, creating a symbolic link or copying the storage directory, for example.
  • Viewing. "Em ơi, có lỗi rồi! lên server check giúp anh/chị" , do you think this sentence is familiar: lol: Ssh on the server and check log is usually inevitable. If the user you use to ssh does not have permission to read the log file, you will lose the chmod to chmod it. Even if you don’t have sudo privileges, there’s nothing you can do about it =))

Log channel

Using the default channel takes a lot of work to investigate, especially when logging data is large. Everything will be mixed together and you need to filter a lot to get the data you want.

For my project, my team performs functional logging. Like the login / logout function, I will use a separate channel. Or the feature of tagging and tagging, I also use my own channel. This helps me quite a lot when you need to investigate a specific feature.

Exception handler

This is pretty much what you already know, and it’s obvious when it comes to recording errors when an exception occurs.

Laravel has a Handler to handle whenever an exception occurs. This class contains two methods: report and render . The render method will let us choose how the exception is logged, usually we use the default. The report method also converts the exception and writes it back to the log file.

However, we usually do the reporting right after the exception has occurred to get the necessary responses. Depending on the project, you can post information on sentry , bugsnag or slack , chatwork

There is quite a bit of useful information included in the exception that you can get for logging and reporting. Here is the example that we use (send messages to slack and chatwork ):

If you don’t want to report some exception , you can add it to the $dontReport variable in Handler . It will automatically filter and report only the appropriate exceptions.

Database logging

Above we have done the saving of the action logs on the laravel system. However, sometimes incorrect logic leads to improper data storage. It is also possible that the query is too large and the query’s execution will cause errors. So what do we need to do?

Record log before manipulating database? This can be done but you need to repeat the code in rất rất nhiều places, and maybe forget some places. There is a more optimal way, we will use the available method DB::listen() so that every time we have a database action, we will record the query. You can also filter to avoid logging unnecessary queries

Log Formatter

The nice thing about laravel is that laravel allows us to change the default format when logging to logs and you can format it theo ý của mình . This one I never used, found it nice, so I added it: 3

You need to create 1 CustomizeFormatter and update config of channel , add 'tap' => [AppLoggingCustomizeFormatter::class] as below:

Log Viewing

Each of you, each project will have a different way of đọc logs. How do you normally read the log? Here are some of the ways that I used to get log and read.

  • ssh to the server, read each file. If the number of servers is large or the number of files to check is large, this is not reasonable. Also you need to have ssh permission to the server and know how to use vim
  • Download log from server to local computer and use some editor to find . This is fine, but like the one above, you need to have ssh permission to the server to download the file. We can automate it by writing script (using rsync or scp ) or using tools like ansible
  • Use third-party apps like sentry , bugsnag . I just need to login and see it.
  • Use FILE_DRIVER party FILE_DRIVER (such as aws s3 , …). Similar to above, just go to the amazon console and filter.


Above, I just mentioned how to log, not to mention how to set the log. How to set the log, the proper position it depends on a lot of developers as well as their experience. It doesn’t have a standard. There’s only one thing I think we should adhere to: chỉ log những thông tin cần thiết

Share the news now

Source : Viblo