What are error logs?

Error logs are text files containing lists of errors that occur during application run. They are generated by computer systems to identify and correct issues.

Web server logs

On the web, developers count on error logs from various sources to track down problems and find solutions. A web developer or network administrator may keep a close eye on error logs generated by a web server and its underlying operating system. In addition, all websites and applications run on a software stack using applications that may create different error logs containing valuable information for developers and admins.

Commonly monitored error logs include those produced by:

• Linux-based or Windows operating systems
• Web servers – Apache, Nginx, or IIS
• Databases – MySQL, MariaDB, MongoDB, etc.
• Content Management Systems – WordPress, Joomla, Drupal, etc.
• PHP or other programming languages

With multiple applications producing error logs, it’s best to begin at the top of the software stack when troubleshooting. Since each application may have dependencies that affect other parts of the software stack, an error in one application may trigger another elsewhere in the system.

What’s included in an error log?

The exact details included in an error log may vary depending on the system that generated it and its configuration. Typically, it contains basic information about each error such as the time of the error, user data, and any available error codes or messages. For example, Apache can be configured to write specific information to the error log, including:

• Time and date the error occurred
• Software version
• HTTP status code
• IP address of the client making the request
• User-agent details
• The page requested
• The page referring the client

Web server error logs should not contain any user-identifying data or sensitive information such as passwords. Still, they do often include user-agent details about the browser or client software making a request to the server. All of this information helps IT professionals like website managers, devops engineers, and server administrators identify areas where errors may hinder performance or impact security. 

Entries in the Apache error.log file can also be brief mentions of warnings or other non-error events. In the example below, the error log shows a warning about improper SSL configuration.

[Mon Aug 02 11:02:37.537152 2021] [ssl:warn] [pid 11648:tid 580] 
AH01909: www.example.com:443:0 server 
certificate does NOT include an ID which matches the server name

Warnings are different from errors, and can provide additional information to aid development and testing. Properly configuring warning messages and error logs can help drill down to the source of issues. For example, PHP can be customized to show certain types of log entries, such as only displaying warning messages, or a custom combination of warnings, errors, and notices.

WordPress can produce its own debug file, but the Apache error log also has a lot of details that can help troubleshoot any application-level issues. In this example, a much more detailed entry in the Apache error log points to problems with the MySQL database during a WordPress installation.

[Mon Aug 02 11:07:53.238639 2021]

[pid 7476:tid 1856] [client ::1:65335] WordPress database error 
Table 'nitrop.wp_options' doesn't exist for query INSERT INTO `wp_options`
 (`option_name`, `option_value`, `autoload`) VALUES ('nonce_salt',
 'AJPtFcc-SqX-af(<)8f=laFR5E.egVj%y.FRP-1iY{POs8.(<XpTGe:U)V)W{Noq', 'no')
 ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), 
`option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) 
made by wp_print_scripts, wp_scripts, WP_Scripts->__construct,
 WP_Scripts->init, do_action_ref_array('wp_default_scripts'), 
WP_Hook->do_action, WP_Hook->apply_filters, wp_default_scripts,
 wp_create_nonce, wp_hash, wp_salt, update_site_option, update_network_option,
 add_network_option, add_option, referer: http://localhost/nitrop/wp-admin/install.php?step=1

WordPress debug mode

WordPress can also create an error log, although this option is turned off by default. The wp-config.php file provides the option to enable the WP_DEBUG constant that puts WordPress in debug mode. 

To enable debug mode in WordPress, locate the WP_DEBUG line in the wp-config.php file and set its value to true.

define( 'WP_DEBUG', true );

With debug mode turned on, error messages can display on web pages in a browser window or a log file. To display error messages on web pages, add the line below and set the WP_DEBUG_DISPLAY option to true.

define( 'WP_DEBUG_DISPLAY', true);

The WordPress file must be enabled in order to write errors and warnings to a log file. You can enable the debug.log file by adding the line below and setting the WP_DEBUG_LOG option to true. 

define( 'WP_DEBUG_LOG', true );

Once enabled, the debug.log file contains all errors, warnings, and messages from WordPress. The log file is located in the wp-content directory. To view it, users must first access their website’s files via file manager, FTP, or SSH, then open the debug.log file with a text editor. 

As in the Apache error log example above, the WordPress debug file contains specific details like the time of the event and any error codes or messages. While attempting to read through a densely packed error log doesn’t make for easy reading, the WordPress debug log usually provides enough insight to begin troubleshooting common errors like:

• Pages that return a 404 status
• Internal server error messages
• “Too many redirects” error message
• Broken pages
• Incorrectly displayed content like images, media, etc.
• 502 Bad Gateway error

WordPress recommends against using debug mode on a live website as it’s designed for testing and development. It’s a good idea to disable debug mode when not in use. You can turn it off in the wp-config.php file by switching the same options above back to false.

Various plugins are available to help enable WordPress debug mode and the debug.log file. Using a plugin eliminates the need to edit the wp-config.php file manually and may provide some other features to help users with debugging.

PHP error log

While server error logs and the WordPress debug file can provide some detail regarding PHP errors, the PHP error log can offer additional information about coding issues or runtime problems.

In a testing or development environment, it’s best to see as many errors and warnings as possible. Once a project is in its production, or live environment, most error messages are turned off for a better user experience. PHP includes several functions to help gather error information in practical formats for each scenario.

In a live environment, developers may not want users to see error messages as they occur. Instead, errors can be stored in an error log file so they can be analyzed at a later time. To log errors to a file, the log_errors directive must be enabled in php.ini.

Log_errors = 1

The error message is defined by error_log. This function allows parameters for a specified error message, where the message should go, or any additional headers to include.

error_log(“There’s been an error!”, 0)

With the error log file enabled, data can be collected and analyzed to help track down bugs, produce useful reports, or identify areas in need of improvement. By default, log_errors logs error messages to the server’s error log. The error log’s file location may vary depending on your server and its configuration. 

ApacheNginx/var/log/apache2/error.log/var/log/nginx/error.log