Even if you're not a developer or a technical specialist, working with Magento requires certain knowledge both about the CMS itself and some basic things how web apps work.
Magento error log is a tool that lets you do basic troubleshooting and understanding the essence of your issues especially when you're seeing that something is going wrong, but you have no idea what exactly is not OK.
What is more, there can be cases when the apps write error logs without actually doing their job, which causes speed issues and gigabytes of error log files. You need to use error log to maintain your site and keep it healthy and issue-free.
Keep reading, and I'll guide you through retrieving this useful information. It might look a bit technical, but believe me or not, it is quite easy.
General error logs concept
Let me start from the very beginning and take a look at how a Magento website operates on the Internet:
You probably know that when a customer requests any website pages, the request is handled by several apps: first of all, it's a web-server, which communicates with Magento PHP application. Magento in its turn sends queries to the database. Sometimes, during this process things can go the wrong way. Then the responsible app writes the error and corresponding information into a special file called error log. Monitoring these log files might help you to discover and fix possible issues you may not be aware of for a long time.
For example, there is not enough memory to load all products in the orders, because it is a really huge order (lucky you are, by the way) and a customer wants to open the order overview page to proceed with re-order. What will they see in this case? It might be: In any case I bet you’d like to avoid such situations. But the trick is, when other customers preview small orders, the system works as it should and customers do not report any issues. This is when the errors log monitoring shines. You get a chance to see errors and undertake actions to remove their roots. Without looking into the error log, you won't be aware of this issue with huge orders.
Which error logs should we check? From the picture above you understand that in some cases, like a missing page or image, we need the web-server logs; and for the Magento system errors, like an invalid block type, we need to check the Magento error logs.
This article is focused on the Magento application, so we’ll skip the database and web-server logs review (we will still show an example in the tech section later) and cut to the chase, to the Magento error log. In the next paragraphs we’ll enable logging, find the log file, understand its structure and look through examples of some real-life errors. Moreover, there will be a very handy tip which will save you a lot of time in the end of the article, so stay tuned!
Enable error logging in Magento
First off, we need to tell the platform to save error logs for us to carry out Magento audit of the log. Fortunately, in Magento 2.x error logging is enabled by default, no special configuration needed. In Magento 1.x it is hidden under Admin > System > Configuration > Advanced > Developer section:
Find the errors log file in Magento
OK, we have the logging enabled and now it is time to find the log files. So what's the Magento log location? For Magento 1.x website they are located in the <magento-folder>/var/log/ folder. If you see no files here please make sure the folder has enough of writing permissions, so the web server can create and modify files inside. Our primary files are system.log with all PHP warnings and issues with XML files and exception.log with all the exceptional cases when Magento fails to handle data for some reason.
Magento 2.x uses a slightly different approach. It splits errors by severity according to the Syslog Protocol into files like info.log, debug.log, system.log, etc. For more information, please see this page.
Magento log file structure
If we open the log file, we can find a bunch of lines like this:
16:02:21: 2021-03-13T15:12:23+00:00 ERR (3): Warning: key_exists() expects parameter 2 to be array, null given in /public_html /app/code/community/TIG/MyParcel2021/Model/Api/MyParcel.php on line 752
The pattern is quite straightforward. It is date tag - 16:02:21: 2021-03-13T15:12:23+00:00, followed by the error level - ERR (3): Warning, error description “key_exists() expects …” and the affected file MyParcel.php plus line 752. What does it mean? It means the module fails to calculate delivery cost for some data combination and it’s time to (warning! explicit advertising here! ) switch to some well tested shipping solutions ?
Here's another example.
2021-03-13T15:17:24+00:00 DEBUG (7): Security problem: newsletter/subscribe has not been whitelisted.
This one reports about issues with displaying a “subscribe to newsletter” block. Everything went fine, and then you updated Magento to 1.9.3 but was not aware of the new security feature. As a result you have hidden CMS blocks and lost subscribers.
One more example from the Magento 2.x error log:
[2020-04-07 17:39:30] main.CRITICAL: exception 'Magento\Framework\Exception\LocalizedException' with message 'The element 'product.info.options' already has a child with alias 'default'' in /var/www/html/ /vendor/magento/framework/Data/Structure.php:611
The same, we have the date, the error level (critical) the error message and the location. Here I assume something is wrong with the product view page and its info block.
If you have some errors in the log and do not know what they mean, then feel free to post them as comments, may be we can sort them out together. Also, it's a good idea to google the text of the error.
I want to stress out the following point: while being a store owner, not a developer, you don’t have to understand these messages in and out. It is more important to see there is an issue and to understand that the issue should be fixed.
Displaying Magento error messages
But what if you are a developer and you are working on a theme or a module? Then everything flips around and often it makes sense to display errors, not just log them in the file. This way you'll see the errors straight away, without looking into the error log files.
To do this in Magento 1, you can turn on the developer mode environmental variable in the .htaccess file like this
SetEnv MAGE_IS_DEVELOPER_MODE “1”
In Magento 2, please compile the whole Magento application in the developer mode.
php bin/magento deploy:mode:set developer
Read more about the Magento 2 modes here.
Finding Apache error log
Every developer eventually comes to the situation where he or she sees a blank page and there's nothing in the Magento error logs. It means the error had occurred even before Magento was launched. Such types of the errors are called fatal errors. I’ve put it in the developer section as I have a sheer belief it could happen on the dev server only. In this particular case it is worth to check the Apache error logs. They have no fixed locations, but you can run phpinfo() command to see the path. The following settings should be set in PHP.INI, or virtual host, or .htaccess file.
error_reporting = E_ALL | E_STRICT
log_errors = On
error_log = /var/log/php_errors.log
Here's a very simple example of the fatal error:
Fatal error: Class 'Mage_Compiler_Helper_Data' not found in /var/www/app/Mage.php on line 547
It means a required file is missing.
How to write in the Magento log file
This article is about reading and understanding logs, however, I feel compelled to show how to write something to the logs. It is useful when you debug an application with no frontend part, like cron tasks, or API calls, or whatever.
In Magento 1, all you need to do is to call static Mage::log() method, like this:
Mage::log($var); // simple values
Or:
Mage::log(“value: ” . print_r($var, 1), “mylogfile.txt”); // arrays or null values
You can find the full function signature in the app/Mage.php class:
public static function log($message, $level = null, $file = '', $forceLog = false)
The approach has been changed in M2 significantly. Magento 2 complies with the PSR-3 standard. As a default implementation of logger it uses Monolog. While the logging itself looks like $this->logger->debug(“some message”); a lot of additional logic is involved. See link 1 and link 2 for more details.
Getting notifications about Magento errors
And here is the useful tip I promised to present you. If the site is up and running, and there are no errors in the logs, then you can easily setup a cron job to send you a message if the files are not empty (and then remove the file).
0 23 * * * /usr/lib/sendmail [email protected] < /home/website.com/www/var/log/exception.log;
rm /home/website.com/www/var/log/exception.log
You will receive a message each time there's a new record in your Magento error log.
This is a simple to-start solution, but I do recommend going further and using any kind of tool to receive Magento error reports.
Conclusion
To wrap it up, I’d like to list the main points of the article:
- In the production mode all errors are hidden, if not - stop reading and disable them;
- During a page request an error may arise at a different level;
- Fatal errors are handled by the web server, not Magento logger, so see Apache logs as well;
- Exceptions are stored in /logs/ and in the /report/ folders, different for M1 and M2;
- All other errors are in logs, if logs are enabled;
- It’s easy to set up instant notifications about exceptional cases at your site.
If you need to go global with your store performance analysis, take a look at the Advanced Reports extension.
I hope you will watch out for hidden errors and keep your logs empty, and your Magento site - healthy and maintained.