‍

‍

In the realm of web server management, having a proper logging system in place can be a lifesaver. This article aims to provide a comprehensive guide on how to configure logging and log rotation in Nginx, thus enabling you to effectively troubleshoot and manage your server. We’ll be using an Ubuntu 22.04 virtual private server (VPS) for demonstration, but the principles should apply across most modern distributions.

1. Preliminary Requirements

To follow along, you’ll need:

1. An Ubuntu 22.04 server with a non-root sudo-enabled user and a firewall.
2. Nginx installed on the server.

Once you have Nginx running on your Ubuntu 22.04 server, you’re ready to delve into the world of log management.

2. Understanding the error_log Directive

Nginx uses several directives to manage system logging. The most basic one is the error_log directive which is included in the core module.

2.1 Syntax of error_log Directive

The error_log directive is utilized to manage logging of general error messages. If you’ve worked with Apache before, you’ll find it similar to Apache’s ErrorLog directive.

The syntax for the error_log directive is as follow:/etc/nginx/nginx.conf
error_log log_file log_level

Here, log_file specifies the file where the logs will be recorded, and log_level specifies the lowest level of logging you want to capture.

2.2 Understanding Logging Levels

The error_log directive can be configured to log various levels of information. The logging level can be any one of the following:

1. emerg: Emergency situations where the system is in an unusable state.
2. alert: Severe situations requiring immediate action.
3. crit: Critical issues that need to be addressed.
4. error: An error has occurred; something was unsuccessful.
5. warn: Something unusual happened, but it’s not a cause for concern.
6. notice: Normal occurrences worth noting.
7. info: Informational messages that might be good to know.
8. debug: Debugging information useful for pinpointing a problem.

Higher up the list implies higher priority. If you specify a level, the log captures that level and any level higher than the specified level.

For instance, if you specify error, the log will capture messages labeled error, crit, alert, and emerg.

A practical usage example of this directive can be found in the main configuration file:sudo nano /etc/nginx/nginx.conf
/etc/nginx/nginx.conf

. . .
### Logging Settings ##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
. . .

To prevent the error_log from logging anything, redirect the output into /dev/null:/etc/nginx/nginx.conf
. . .
error_log /dev/null crit;
. . .

3. Grasping the HttpLogModule Logging Directives

While the error_log directive is part of the core module, the access_log directive is part of the HttpLogModule, which allows for log customization. This module also includes other directives to assist in configuring custom logs.

3.1 The log_format Directive

The log_format directive is used to describe the log entry format using plain text and variables. Nginx comes with a predefined format called combined, commonly used by many servers.

Here’s an example of the combined format if it wasn’t defined internally and needed to be specified with the log_format

directive:/etc/nginx/nginx.conf
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

The lines starting with a dollar sign ($) indicate variables, while characters like -, [, and ] are interpreted literally.

The general syntax of the directive is:/etc/nginx/nginx.conf
log_format format_name string_describing_formatting;

You can use variables supported by the core module to formulate your logging strings.

3.2 Understanding the access_log Directive

The access_log directive bears a similar syntax to the error_log directive but offers more flexibility. It is used to configure custom logging.

The access_log directive uses the following syntax:/etc/nginx/nginx.conf
access_log /path/to/log/location [ format_of_log buffer_size ];

The default value for access_log is the combined format mentioned in the log_format section. You can use any format defined by a log_format definition.

The buffer size is the maximum size of data that Nginx will hold before writing it all to the log. You can also specify compression of the log file by adding gzip into the definition:/etc/nginx/nginx.conf
access_log /path/to/log/location format_of_log gzip;

Unlike the error_log directive, if you do not want logging, you can turn it off by updating it in the configuration file:/etc/nginx/nginx.conf

. . .
### Logging Settings ##
access_log off;
error_log /var/log/nginx/error.log;
. . .

In this case, it is not necessary to write to /dev/null.

4. Managing Log Rotation

As log files grow, it becomes crucial to manage the logging mechanisms to avoid filling up your disk space. Log rotation is the process of switching out log files and possibly archiving old files for a set period.

Nginx doesn’t provide tools to manage log files, but it does have mechanisms to assist with log rotation.

4.1 Manual Log Rotation

To manually rotate your logs, you can create a script to rotate them. For example, move the current log to a new file for archiving. A common scheme is to name the most recent log file with a suffix of .0, and then name older files with .1, and so on:mv /path/to/access.log /path/to/access.log.0

The command that actually rotates the logs is kill -USR1 /var/run/nginx.pid. This doesn’t kill the Nginx process, but sends it a signal causing it to reload its log files. This results in new requests being logged to the refreshed log file:kill -USR1 `cat /var/run/nginx.pid`

The /var/run/nginx.pid file is where Nginx stores the master process’s PID. It is specified at the top of the /etc/nginx/nginx.conf configuration file with the line that starts with pid:

sudo nano /etc/nginx/nginx.conf/etc/nginx/nginx.conf
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
...

After the rotation, execute sleep 1 to allow the process to complete the transfer. You can then zip the old files or perform whatever post-rotation processes you prefer:sleep 1
[ post-rotation processing of old log file ]

4.2 Log Rotation with logrotate

The logrotate application is a program used to rotate logs. It is installed on Ubuntu by default, and Nginx on Ubuntu comes with a custom logrotate script.

The first line of the file specifies the location that the subsequent lines will apply to. Keep this in mind if you switch the location of logging in the Nginx configuration files.

The rest of the file specifies that the logs will be rotated daily and that 52 older copies will be preserved.

The postrotate section contains a command similar to the manual rotation mechanisms previously employed: /etc/logrotate.d/nginx

. . .
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
. . .

This section instructs Nginx to reload the log files once the rotation is complete.

5. Conclusion

Proper log configuration and management can save you a lot of time and energy when dealing with server issues. Access to information that can help diagnose a problem can mean the difference between a quick fix and a persistent headache.

It’s important to keep an eye on server logs to maintain a functional site and ensure that sensitive information isn’t exposed. This guide serves as an introduction to your journey with logging.

For more tips on troubleshooting common Nginx errors, refer to our tutorial here.

Remember, a reliable server is crucial to the success of your web services. If you’re looking for efficient, scalable, and secure cloud hosting solutions, consider Shape.host’s Linux SSD VPS services, known for their robustness and superior performance.