To save yourself some trouble with your web server, you can configure logging. Logging information on your server gives you access to the data that will help you troubleshoot and assess situations as they arise.
In this tutorial, you will examine Nginx’s logging capabilities and discover how to configure these tools to best serve your needs. You will use an Ubuntu 22.04 virtual private server as an example, but any modern distribution should function similarly.
To follow this tutorial, you will need:
sudo-enabled user with a firewall. Follow our Initial Server Setup to get started.
With Nginx running on your Ubuntu 22.04 server, you’re ready to begin.
Nginx uses a few different directives to control system logging. The one included in the core module is called
error_log directive is used to handle logging general error messages. If you are familiar with Apache, this is very similar to Apache’s
error_log directive applies the following syntax:
error_log log_file log_level
log_file specifies the file where the logs will be written. The
log_level specifies the lowest level of logging that you would like to record.
error_log directive can be configured to log more or less information as required. The level of logging can be any one of the following:
emerg: Emergency situations where the system is in an unusable state.
alert: Severe situations where action is needed promptly.
crit: Important problems that need to be addressed.
error: An error has occurred and something was unsuccessful.
warn: Something out of the ordinary happened, but is not a cause for concern.
notice: Something normal, but worth noting what has happened.
info: An informational message that might be nice to know.
debug: Debugging information that can be useful to pinpoint where a problem is occurring.
The levels higher on the list are considered a higher priority. If you specify a level, the log captures that level, and any level higher than the specified level.
For example, if you specify
error, the log will capture messages labeled
An example of this directive in use is inside the main configuration file. Use your preferred text editor to access the following configuration file. This example uses
- sudo nano /etc/nginx/nginx.conf
Scroll down the file to the
# Logging Settings section and notice the following directives:
. . . ## # Logging Settings ## access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; . . .
If you do not want the
error_log to log anything, you must send the output into
. . . error_log /dev/null crit; . . .
The other logging directive,
access_log, will be discussed in the following section.
error_log directive is part of the core module, the
access_log directive is part of the
HttpLogModule. This provides the ability to customize the logs.
There are a few other directives included with this module that assist in configuring custom logs.
log_format directive is used to describe the format of a log entry using plain text and variables.
There is one format that comes predefined with Nginx called
combined. This is a common format used by many servers.
The following is an example of the combined format if it was not defined internally and needed to be specified with the
log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';
This definition spans multiple lines until it finds the semi-colon (;).
The lines beginning with a dollar sign (
$) indicate variables, while the characters like
] are interpreted literally.
The general syntax of the directive is:
log_format format_name string_describing_formatting;
You can use variables supported by the core module to formulate your logging strings.
access_log directive uses similar syntax to the
error_log directive, but is more flexible. It is used to configure custom logging.
access_log directive uses the following syntax:
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
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:
access_log /path/to/log/location format_of_log gzip;
error_log directive, if you do not want logging, you can turn it off by updating it in the configuration file:
. . . ## # Logging Settings ## access_log off; error_log /var/log/nginx/error.log; . . .
It is not necessary to write to
/dev/null in this case.
As log files grow, it becomes necessary 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 amount of time.
Nginx does not provide tools to manage log files, but it does include mechanisms to assist with 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 does not kill the Nginx process, but instead sends it a signal causing it to reload its log files. This will cause new requests to be logged to the refreshed log file:
- kill -USR1 `cat /var/run/nginx.pid`
/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 begins with
- sudo nano /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 do whatever post-rotation processes you like:
- sleep 1
- [ post-rotation processing of old log file ]
logrotate application is a program used to rotate logs. It is installed on Ubuntu by default, and Nginx on Ubuntu comes with a custom
Use your preferred text editor to access the rotation script. This example uses
- sudo nano /etc/logrotate.d/nginx
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.
Notice that the
postrotate section contains a command similar to the manual rotation mechanisms previously employed:
. . . postrotate [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid` endscript . . .
This section tells Nginx to reload the log files once the rotation is complete.
Proper log configuration and management can save you time and energy in the event of a problem with your server. Having access to the information that will help you diagnose a problem can be the difference between a trivial fix and a persistent headache.
It is important to keep an eye on server logs in order to maintain a functional site and ensure that you are not exposing sensitive information. This guide serves only as an introduction to your experience with logging. You can learn more general tips in our tutorial on How To Troubleshoot Common Nginx Errors.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.