Magento Logger: A Better Way to Understand Your Application and Make Better Decisions for It

1. How to View Magento 2 Logs
   1. Understanding Magento Log
   2. View Magento Logs
2. Types Of Magento Logs and How to Study them
   1. Magento PHP Logs
   2. Magento Apache Logs
   3. Magento NGINX Logs
3. Get Starting with Magento 2 Logging
   1. Method: 1 Create Magento Log with Custom File
   2. Method: 2 How to Define Magento Logger Class
   3. Method: 3 Working With Magento Logger Through Object Manager
4. Magento 2 Debug Logging
5. Magento 2 Database Logging
6. Magento 2 Cron Logging
7. Improve Store Performance with Magento Store Logs
8. Magento Log Monitoring Through Cloudways
   1. Magento PHP Logs
   2. Magento Apache Logs
   3. Magento NGINX Logs
   4. Magento Apache Error Logs
9. Conclusion

During development, the Magento 2 logger logs the maximum amount of information for later use, and it helps with debugging as well. It detects and analyzes errors including Magento 503, Magento 500 and other warnings that cause concern.

It can be challenging to write the piece of code and capture the information during the event – for example, to log order information during checkout. Magento 2 uses a library to write and store the logs in. This is Monolog, with built-in handler methods and parameters for advanced logging strategies.

Magento 2 comes with the PSR-3 standard, and uses the Monolog as an interface Psr\Log\LoggerInterface. The Monolog Logger comes with its own set of handlers, as well as custom-created handlers that can be reused for logging into files and databases, and to make it easier to send. 

In this article, we will show you how to work with Magento’s Monolog Logger Class, and other methods to write the logs.

How to View Magento 2 Logs

Magento Loggers maintain all records of Magento activity, and so help troubleshoot problems related to Magento commerce.

Understanding Magento Log

Let’s start with how the process works.

When a visitor generates a request, it is initially handled by the server (Apache), which communicates with the app (Magento/PHP). Magento then sends the query to the database (MySQL). During this flow, there are chances of errors. That’s why the Magento logger maintains a complete log of all the activities to help with error identification and resolution.

By default, Magento does not send error & exceptions messages and so developers do not get notified if anything happens. I recommended that developers and store owners continuously check Magento 2 logs and take timely action before there’s any damage.

View Magento Logs

Log Directories: By default, all Magento logs are maintained in var/log directory which can be accessed via SSH/CLI or through FTP.

Via FTP structure

/applications/[application folder]/public_html/var/log

To view a specific Magento log, download it on a local drive.

Via CLI

Use the following command to access the Magento 2 logger file:

cd public_html/var/log

Once in the folder, use the following command to view the Magento log file:

ls -l 

Project web UI: For Magento 1, you need to enable the Magento log from the Magento admin panel. If you would like to see the log in the Magento 2 admin panel, check out this article: How To Debug A Magento 2 Store With Ease.

Types Of Magento Logs and How to Study them

Magento Access log contains a record of client requests. When a client generates a request, Apache records several parameters associated with the request. The list includes the IP address of the client, the parameters of the client request, the HTTP status code, and the timestamp of the request.

Magento PHP Logs

PHP logs contain detailed information about PHP requests, like files/routes, CPU and memory usage.

Since Magento 2 is a full-stack ecommerce platform that uses Monolog logging framework as its main logging functionality, it complies with the PSR-3 logging implementation standards and namespaces.

Magento PHP built-in error logs usually display information related to:

• Failure of a core function or code parsing (these errors are generally generated by the PHP engine)
• PHP custom errors triggered in the application (such errors are usually generated when wrong or incomplete information is provided)
• Activities performed in the Magento application which may be helpful in the analysis of potential problems

When log_errors are enabled but are not properly defined, these Magento errors are logged in the web server error log, which is maintained in the Apache and NGINX logs. I’ll discuss this later.

Magento PHP Logging Functions

Magento utilizes several core PHP error functions to report errors.

error_log()

This function is used to send a message to the recently configured error log. The most common use is:

error_log(‘Your message’);

An Apache server will display the error like this:

[20-Jul-2020 18:20:02 Europe/Malta] Your message

If you wish, you can send the error to a different file. But this could be confusing and is not recommended:

error_log(‘Invalid input on user login’, 3, ‘/var/www/example.com/log/error.log’);

trigger_error()

This function is a great way to deal with custom errors. In fact, the recommended practice is to use trigger_error() with a descriptive message at every point where the code could break. This function displays two parameters: the error message, and an error level.

syslog()

Another way of managing the error log is to send it directly to the system using the syslog() function. It takes the error level as the first parameter (LOG_INFO, LOG_DEBUG, and many other parameters), with the second parameter being the actual error message.

Example (using openlog() for the connection): Aug 4 11:42:10 vaprobash php: User #5 is logged from three different locations.

Magento PHP Log Format

When logging data, the proper formatting convention should be followed. The Magento log should contain essential fields such as date/time, filename and message. This simplifies the analysis process and helps you better understand the data.

PHP Error Log Types

PHP provides different types of Magento error logs that define the severity of error for your Magento store. These error levels define which PHP statement can’t be compiled or parsed, and whether the Magento application could access all the required resources or the errors caused because of typos and related issues.

PHP error levels are integer values where each error is assigned a constant. These constants make the code easy to read and compatible enough that new error levels could be introduced. Here are some common error levels:

• E_ERROR – These are fatal run-time errors that stop code execution. A good example would be calling a function that does not exist.
• E_WARNING – These errors do not stop the execution of code, but the code might not work as expected.
• E_PARSE – These are compile-time parse errors, like missing parentheses or semicolons.
• E_NOTICE – This indicates possible bugs, such as using a variable that doesn’t exist in an expression. This means that either the variable is a typo or is not assigned the right way.

Here is a detailed guide that describes PHP logs in detail.

Magento Apache Logs

Magento Apache error logs are further categorized into the following two subsections.

Magento Apache Error Logs

This is the place where Apache maintains a record of any errors encountered in processing requests received by the server. In case of a problem with the server, this contains the details of what went wrong (and, often, how to fix it).

The format of Magento Apache logs is often in the following format:

[Sat Oct 10 11:45:39.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.184] File does not exist: /usr/local/apache2/htdocs/favicon.ico

Reading the Error Entry

• The first item in the log entry is the date and time of the message: [Sat Oct 10 11:45:39.902022 2011]
• The next is the module producing the message and the severity level of that message: [core:error]
• This is followed by the process ID and, if appropriate, the thread ID of the process that experienced the condition: [pid 35708:tid 4328636416]
• Next is the client address that generated the request: [client 72.15.99.184] 
• And finally, the detailed error message: File does not exist: /usr/local/apache2/htdocs/favicon.ico

Magento Apache Access Logs

The server access log records all requests processed by the server. Storing the log is only the start of log management. The next step is to analyze this information to come up with an actionable correction course.

The format of the access log is highly configurable. It is specified using a format string that looks much like a C-style printf(1) format string.

Common Log Format

A typical configuration for the access log might look as follows.

LogFormat “%h %l %u %t \”%r\” %>s %b” common

The configuration above will record log entries in a format known as the Common Log Format (CLF). This standard format can be produced by many different web servers and read by many log analysis programs. The log file entries produced in CLF will look something like this:

127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0” 200 2326

Each part of this log entry is described below.

127.0.0.1 (%h)

This is the IP address of the client (remote host) which made the request to the server. It is best to use a log post-processor such as logresolve to determine the hostnames. These IP addresses are not always the IP of the user, particularly in cases when the user is behind a proxy server.

– (%l)

The “hyphen” in the output indicates that the requested piece of information is not available.

frank (%u)

This is the user ID of the person requesting the document as determined by HTTP authentication.

[10/Oct/2000:13:55:36 -0700] (%t)

The time that the request was received. The format is:

[day/month/year:hour:minute:second zone]

“GET /apache_pb.gif HTTP/1.0″ (\”%r\”)

The request line from the client is given in double quotes. The request line contains a great deal of useful information. First, that the method used by the client is GET. Second, the client requested the resource /apache_pb.gif. Third, the client used the protocol HTTP/1.0.

200 (%>s)

This is the status code that the server sends back to the client. This information is very important because it reveals whether the request resulted in a successful response (codes beginning in 2), a redirection (codes beginning in 3), an error caused by the client (codes beginning in 4), or an error in the server (codes beginning in 5).

2326 (%b)

The last part indicates the size of the object returned to the client, not including the response headers. If no content was returned to the client, this value will be “-“. To log “0” for no content, use %B instead.

Combined Log Format

Another commonly used format string is called the Combined Log Format. It can be used as follows.

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”” combined

CustomLog log/access_log combined

This format is exactly the same as the Common Log Format, with the addition of two more fields. Each of the additional fields uses the percent-directive %{header}i, where the header can be any HTTP request header. The access log under this format will look like:

127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] “GET /apache_pb.gif HTTP/1.0” 200 2326 “http://www.example.com/start.html” “Mozilla/4.08 [en] (Win98; I ;Nav)”

Magento NGINX Logs

NGINX is a popular proxy and web server that speeds up the response of the website.

NGINX Error Logs

When NGINX faces any issue, such as in the configuration file, it will be recorded in the NGINX error log. So if NGINX is unable to start or abruptly stops, you should check the NGINX error logs. Chances are that you may also find a few warnings in the error log. However, this does not mean that a problem has occurred; rather, this alert points to a potentially serious issue in the near future.

Example: error_log /var/log/nginx/error.log warn;

• Error_log: Defines the directive (error_log)
• Log_file: Defines the absolute path of your log file ( /var/log/nginx/error.log)
• Log_level: Defines the severity level for which you want error messages to be logged (warn)

When defining the severity level, NGINX will log all errors that are equal to or above the defined level.

NGINX Error Log Severity Levels

Several severity levels can be defined in the error_log directive. The following is a list of all severity levels ranging from low to high.

• debug – Useful debugging information to help determine where the problem lies.
• info – Informational messages that might add value for the developers.
• notice – Something normal happened that is worth noting.
• warn – Something unexpected happened, but it is not a cause for concern.
• error – Something was unsuccessful.
• crit – There is a serious problem that needs your attention.
• alert – Prompt action is required.
• emerg – The system is in an unusable state and requires immediate attention.

What is an NGINX Access Log?

The NGINX access log is similar to the error log in that it logs information. However, NGINX maintains the log of every request made by the client. The access_log directive uses the following syntax:

access_log log_file log_format;

• Access_log: Defines the directive
• Log_file: Defines the location of the access.log file
• Log_format: Can be defined using variables (default format is combined)

Example: access_log /var/log/nginx/access.log log_file combined;

Get Started with Magento 2 Logging

Custom logs can make debugging easier, as they simplify identifying a mistake and its cause. With Magento 2 logger, there are different methods to write and log the necessary information to save and print on the website.

Method: 1 Create Magento Log with Custom File

Magento 2 logs can be saved into the custom-created file with Zend and Laminas Writing Streams to record data at the backend.

For Magento Version 2.4.2 before: 

$writer = new \Zend\Log\Writer\Stream(BP . ‘/var/log/logfile.log’);

$logger = new \Zend\Log\Logger();

$logger->addWriter($writer);

$logger->info(‘Simple Text Log’);

$logger->info(‘Array Log’.print_r($myArrayVar, true));

For Magento Version 2.4.2 after:

$writer = new \Laminas\Log\Writer\Stream(BP . ‘/var/log/cloudwayscustom.log’);

$logger = new  \Laminas\Log\Logger();

$logger->addWriter($writer);

$logger->info(‘text message’);

$logger->info(print_r($object->getData(), true));

For Magento Version 2.4.3 or later:

$writer = new \Zend_Log_Writer_Stream(BP . ‘/var/log/custom.log’);

$logger = new \Zend_Log();

$logger->addWriter($writer);

$logger->info(‘text message’);

$logger->info(print_r($object->getData(), true));

Method 2: Define Magento Logger Class

Magento 2 Logger uses dependency injection so you must create an instance and declare the \Psr\Log\LoggerInterface into the constructor to write data to log files.

     2.2 How to Print Magento 2 Logs In Custom Module

In your custom module app/code/Cloudways/Extension/Block/Printlog.php, you need to pass the Magento 2 Logger Interface as a parameter in our constructor. You can also use 8 different kinds of functions such as critical, alert, notice and debug in the following code. 

namespace Cloudways\Extension\Block;

use Psr\Log\LoggerInterface;

class  Printlog

{

    protected $logger;

    public function __construct(LoggerInterface $logger)

 {

        $this->logger = $logger;

 }

  public function logData()

    {  

        $this->logger->info('Testing Info');

 

        $this->logger->debug('Testing Debug');




        $this->logger->notice('Testing Notice');




        $this->logger->alert('Testing Alert');




        $this->logger->error('Testing Error'); 




        $this->logger->critical('Testing Critical Error');




    }

Flush Magento cache and check your result.

     2.3 Logger Class Method Parameters

Magento 2 Logger uses each of the Logger class methods that take two arguments. The first one is the message string, and the other is an optional array for logging the object such as Order Object.

  $this->_logger-> alert($message, array $context = array())

      2.4 Create the Custom Logger Handler

Developers sometimes write data to the custom log file when the application is getting larger in size with more and more lines of code day by day. This lets them log the most useful information, as it becomes difficult to target the event. Here are the steps for this.

Create the Magento 2 Logger Class:

App/code/Cloudways/CustomLog/Logger/Logger.php

<?php

namespace Cloudways/CustomLog\Logger;

class Logger extends \Monolog\Logger

{

}

Create the Handler Class and Mention the Log File:

<?php

namespace Cloudways\CustomLog\Logger;

use Monolog\Logger;

class Handler extends \Magento\Framework\Logger\Handler\Base

{

   protected $loggerType = Logger::NOTICE;

   /* Filename */

   protected $fileName = '/var/log/cloudways _custom_log.log';

}

You can define any filename for your own purpose. Here we create the file with cloudways_custom_log.log.

Define custom Magento 2 logger handler in module’s di.xml file

<?xml version="1.0"?>






<config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation="../../../../../lib/internal/Magento/Framework/ObjectManager/etc/config.xsd">

   <type name="Cloudways\CustomLog\Logger\Handler">

       <arguments>

           <argument name="filesystem" xsi:type="object">Magento\Framework\Filesystem\Driver\File</argument>

       </arguments>

   </type>

   <type name="Cloudways\CustomLog\Logger\Logger">

       <arguments>

           <argument name="name" xsi:type="string">Cloudways_Custom_Log</argument>

           <argument name="handlers"  xsi:type="array">

               <item name="system" xsi:type="object">Cloudways\CustomLog\Logger\Handler</item>

           </argument>

       </arguments>

   </type>

</config>

Run the following commands:

php bin/magento setup:di:compile

php bin/magento cache:flush

Use Custom Magento 2 Log File in Your Module:

Create any block such as Cloudways/CustomLog/Block/Test.php

<?php

namespace Cloudways\CustomLog\Block;

class Test extends \Magento\Framework\View\Element\Template

{

    protected $_customLogger;

 

    public function __construct(

        \Magento\Backend\Block\Template\Context $context,

        \Cloudways\CustomLog \Logger\Logger $customLogger,

        array $data = []

    )

    {        

        $this->_customLogger = $customLogger;

        parent::__construct($context, $data);

    }

 

    public function LogData()

    {

        //save data in var/log/custom.log

        $this->_customLogger->info('Message goes here');




       //add array in log

       $this->_customLogger->info('API Params', $params); 

    }

}

Method 3: Working with Magento Logger through Object Manager

Magento 2 uses Object Manager i.e \Magento\Framework\App\ObjectManager class, which is responsible for creating and retrieving the external class objects like the Logger Interface. That said, it is not recommended to use Object Manager as it prohibits instantiation. Developers mostly use any new PHP file for logging valuable information.

Sample Code:

    $objectmanager = \Magento\Framework\App\ObjectManager::getInstance();

    $objectmanager->get(‘Psr\Log\LoggerInterface’)->info(‘Testing Log’); //Print log in var/log/system.log

    $objectmanager->get(‘Psr\Log\LoggerInterface’)->debug(‘Testing Log’); //Print log in var/log/debug.log

Magento 2 Debug Logging

Magento 2 comes with the built-in log files such as system.log, debug.log, and exception.log. Before implementing any of these methods, make sure your Magento store is in the default or develop mode, not in production mode. By default, Magento prints and writes the log to the debug log.

To change the default value in default and develop mode, use the following command:

1. bin/magento setup:config:set –enable-debug-logging=true|false
2. bin/magento cache:flush

Magento 2 Database Logging

Magento 2 has another functionality for logging the database activity using the Magento\Framework\DB\LoggerInterface Class. Developers can effortlessly code the application but find difficulty in tracking the data activity stored in the database. Logging the database query results is useful for optimizing the performance of the application.

Magento 2 logs the Database logs in var/debug/db.log

Use the following command to enable/disable database logging:

1. bin/magento dev:query-log:enable|disable
2. bin/magento cache:flush

Magento 2 Cron Logging

Magento 2.3 introduces a feature for logging more information by creating separate cron log files that make developer debugging easier. But it considerably increase the system log file size as the application goes live.

By default, Magento 2 cron logs the info in var/log/cron.log.

To enable Syslog logging, use the command:

bin/magento setup:config:set –enable-syslog-logging=true

Improve Store Performance with Magento Store Logs

Like any other ecommerce platform, Magento performance is also very much affected by the size of the database. All Magento logs are stored in the store database. To improve website performance and reduce the latency of query execution, these logs need to be cleared on a regular basis. 

Magento logs can occupy GBs of data, so regular cleaning saves a lot of resources. Here’s how you can clear the logs for optimized performance.

Magento Log Monitoring Through Cloudways

Cloudways offers a great monitoring feature that includes a log component users can leverage to identify problems in the application hosted on their managed Magento servers. The logs are available on the Cloudways Platform, but there is no need to download the logs via FTP or to view them through SSH access.

Here is the easy way to monitor your Magento Logs:

Magento Apache Logs

All Magento Apache logs can be further filtered to help discover specific issues.

Magento NGINX Logs

All Magento NGINX logs are displayed here without any need to get into your logs file or database. These logs can be further filtered to help find specific issues in Magento NGINX logs.

Magento PHP Logs

These logs can be further filtered to help us to find specific Magento PHP logs.

Magento Apache Error Logs

Magento Apache error related logs can be further filtered to find specific Magento Apache error logs entries.

For further details about application log management, read the Cloudways log management guide.