There are logs and there are LOGS. Some logs can be noisy and pretty useless while others might indicate a serious issue that you have to respond to right away.
The volume of logs we manage as administrators can make it difficult to differentiate from those that are noisy and those that are important. To help with this, we are starting a series that will focus on critical logs. This will hopefully help administrators make sense of the log noise, providing enough details that help make managing and monitoring those logs a lot easier.
Today's critical logs are: PHP Fatal Errors.
Fatal errors are reserved for events that crash a PHP application. There are three types of Fatal Errors to be aware of in PHP:
Type | Description |
---|---|
Startup | When the system can’t run when initiatlized |
Compile | When a programmer tries to use nonexistent data |
Runtime | Happens while the program is running, causing the code to stop working completely |
If your PHP application / script fails you should always expect some entry in your error log file.
Here is a simple example of a PHP Fatal Error:
[Wed Jul 06 23:20:21.408213 2022] [php:error] [pid 1556524] [client 1.2.3.4:64739] PHP Fatal error: Uncaught DivisionByZeroError: Division by zero in /var/www/html/test.php:5\nStack trace:\n#0 /var/www/html/test.php(5)...
Let's explode this log so that we can make sense of what it is telling us
Log Element | Description |
---|---|
Wed Jul 06 23:20:21.408213 2022 | Occurred on Wednesday, July 6th 2022, at 23:20 (11 pm) |
[php:error] | This was a PHP fatal error. |
pid 1556524 | The process ID was 1556524 |
client 1.2.3.4:64739 | The client IP was 1.2.3.4 |
PHP Fatal error: Uncaught DivisionByZeroError: | Confirms it is a PHP Fatal error, and tells you the exact error. In this case it was Uncaught Division by Zeror. |
Division by zero in /var/www/html/test.php:5\nStack | The error is occurring in Line 5 of the test.php file located in the /var/www/html/ directory.. |
Depending on the error you can typically find information about the error using search engines. This is a great example because PHP offers a page for the DivisionByZeroError error. In laymans terms, it occurred because of broken math. The application was trying to divide a number by zero.
It's a fatal error because it's not allowed, which means the PHP function making the wrong request is being killed, likely killing your application.
Another popular error has to do do with default configurations that sets maximum memory allocation. It shows up as a "Allowed memory size exhausted" error and almost always requires and update to your config file to allow PHP to use more memory per request. Here is an example of what that might look like:
[Mon Jul 11 16:19:29.370423 2022] [php:error] [pid 1641515] [client 1.2.3.4:61346] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/test.php on line 10, referer: http://127.0.0.1/test-login/
Using a similar breakdown to above, we can see it occurred on Monday, July 11th, and it occurred when the application tried to allocate 134 MB of memory to the process. This became an issue because in most PHP configurations the default is 128 MB of memory allowed for allocation. That makes fixing this type of error extremely easy, it requires updating the PHP.ini file with an increased value for memory allocation.
Here is an example of what that configuration might look like after updating it to 256 MB:
; Maximum amount of memory a script may consume
; https://php.net/memory-limit
memory_limit = 256M
Be aware, however, that this entry could be indicative of an issue with the code. While increasing the memory allocation in PHP fixes the problem, it doesn't fix the cause of the need for the application to consume more memory.
As important at PHP Fatal Errors are, we find they are often ignored or under utilized. While they are not always as descriptive as the examples above, they are an invaluable resource when trying to understand why something is not working. This is especially true in PHP based CMS applications like WordPress, Joomla!, Drupal, and many others.
An easy way to check your fatal errors is to set up a schedule to check your logs. Frequency wholly dependent on the criticality of the application. Using basic tools like terminal and grep you can quickly parse your logs for critical instances like PHP Fatal Errors:
Using NGINX as an example. You can look for those errors by grepping the /var/log/nginx error logs
# zgrep "PHP Fatal error" /var/log/nginx/error.log*.gz
# grep "PHP Fatal error" /var/log/nginx/error.log
If you are using Trunc for log management, we classify PHP Fatal errors as web_fatal and provide a quick navigation option to show any related errors across all server assets.