Configuring the Nginx Error and Access Logs

Introduction

Before we begin talking about Configuring the Nginx Error and Access Logs, let's briefly understand – What is Nginx?

Nginx is an open-source, high-performance HTTP and reverses proxy server that helps some of the world's most popular websites handle their traffic. Checking the log files is one of the most common jobs you'll conduct when operating NGINX web servers.

When troubleshooting server or application difficulties, knowing how to configure and read the logs comes in handy because they contain detailed debugging information.

Nginx keeps track of its activities in two logs: access logs and error logs. Client requests are recorded in access logs, whereas server and application errors are recorded in error logs.

In this tutorial, you will configure the Nginx Error and Access Logs. We will also address a few FAQs on Configuring the Nginx Error and Access Logs.

Configuring the Access Log

Nginx creates a new event in the access log whenever a client request is handled. Each event record includes a timestamp as well as different details about the client and the resource requested. Access logs can reveal a visitor's location, the page they view, the amount of time they spend on the page, and much more.

You can specify the format of logged messages using the log format directive. The access log directive enables and configures the log file's location and format.

The access log directive's most basic syntax is as follows:

access_log log_file log_format;

Where log_file is the whole path to the log file and log format is the log file's format.

In the http, server, or location directives blocks, the access log can be enabled.

The access log is enabled worldwide by default in the http directive of the main Nginx configuration file.

http {
  ...
  access_log  /var/log/nginx/access.log;
  ...
}

Setting up a distinct access log file for each server block is advised for better reading. The server directive's access_log directive overrides the http (higher level) directive's access log directive.

http {
  ...
  access_log  /var/log/nginx/access.log;
  ...

  server {
    server_name domain.com
    access_log  /var/log/nginx/domain.access.log;
    ...
  }
}

If there isn't a log format provided, Nginx employs a predetermined combined format that looks something like this:

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Override the default logging format or define a new one to change the logging format. Add the following specification to the http or server directive to specify a new logging format named custom that will extend the combined format with the value showing the X-Forwarded-For header:

log_format  custom  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

To utilize the new format, type its name after the log file, as demonstrated in the example below:

access_log  /var/log/nginx/access.log custom;

While the access log is extremely valuable, it consumes disc space and may have an impact on server performance. If you have a busy website and your server is low on resources, you may want to disable the access log. Set the value of the access log directive off to do this:

access_log  off;

Configuring the Error Log

In the error log file, Nginx records messages about the application as well as common server failures. If you're having problems with your online application, the error log is the first place to go for solutions.

The error_log directive enables and configures the error log's location and severity level. It can be set in a http, server, or location block and takes the following form:

error_log log_file log_level

The log_level argument determines the logging level. Levels are mentioned below in order of severity (from low to high):

  • debug - Message debugging.
  • info - Messages that provide information.
  • notice - Notices.
  • warn - Warnings.
  • error - Errors that occur while processing a request.
  • crit - Critical issues. Needs prompt action.
  • alerts - Alerts are a type of notification. Immediate action is required.
  • emerg - A situation that requires immediate attention. The system is now unusable.

The higher levels are included in each log level. Nginx, for example, will log the error, crit, alert, and emerg messages if the log level is set to warn.

The log_level argument defaults to error if it is not supplied.

In the main nginx.conf file, the error_log directive is defined by default in the http directive:

http {
  ...
  error_log  /var/log/nginx/error.log;
  ...
}

Set a separate error log file for each server block, similar to access logs, as it overrides the setting inherited from higher levels.

To set the domain.com error log to warn, for example, type:

http {
  ...
  error_log  /var/log/nginx/error.log;
  ...

  server {
    server_name domain.com
    error_log  /var/log/nginx/domain.error.log warn;
    ...
  }
}

If you make changes to the configuration file, you must restart the Nginx service for them to take effect.

Location of the Log Files

Access and error logs are stored by default in the /var/log/nginx directory on most Linux distributions, such as Ubuntu, CentOS, and Debian.

Reading and Understanding the Nginx Log Files

Standard commands such as cat, less, grep, cut, awk, and others can be used to open and interpret log files.

Here's an example record from the access log file, which utilizes the default Nginx log format of combine:

192.168.33.1 - - [15/Oct/2019:19:41:46 +0000] "GET / HTTP/1.1" 200 396 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"

Let's take a look at what each record field means:

  • $remote_addr - 192.168.33.1. - The IP address of the client making the request.
  • $remote_user - - - User who has been authenticated over HTTP. This field displays - when the username is not specified.
  • [$time_local] - [05/April/2022:19:41:46 +0000] - The time on the local server.
  • "$request" - "GET / HTTP/1.1" - The type, path, and protocol of the request.
  • $status - 200 - The server response code.
  • $body_bytes_sent - 396 - The size of the server response in bytes.
  • "$http_referer" - "-" - The referral's URL.
  • "$http_user_agent" - Mozilla/5.0... - Client's user agent (web browser).

To view the log file in real-time, use the tail command:

tail -f  access.log 

FAQs to Configuring the Nginx Error and Access Logs

Where are the Nginx error logs typically located?

By default, Nginx error logs are often located in /var/log/nginx/error.log. However, the actual path may vary depending on the system configuration.

How can I configure the access log in Nginx? 

To configure the access log in Nginx, find the http block in the Nginx configuration file and add or modify the access_log directive to specify the desired log file path and log format.

Where are the Nginx access logs usually stored? 

By default, Nginx access logs are typically stored in /var/log/nginx/access.log. However, the exact location can differ depending on the operating system and configuration.

Can I enable logging for specific server blocks or locations? 

Yes, you can enable logging for specific server blocks or locations by adding or modifying the access_log or error_log directives within those blocks.

What options can I specify in the access_log directive? 

The access_log directive allows you to specify options such as log file path, log format, buffering options, conditions for logging, and more.

How can I rotate Nginx logs to prevent large file sizes?

Nginx log rotation can be achieved using log rotation utilities like logrotate. Configure logrotate to compress and rotate log files at regular intervals based on your requirements.

How can I enable real-time logging in Nginx? 

Nginx does not provide built-in real-time logging functionality. However, you can achieve real-time logging by using tools like tail, grep, or monitoring applications that monitor the log files continuously.

Conclusion

Log files might help you figure out what's wrong with your server and how users interact with your site.

If you have any queries, please leave a comment below and we’ll be happy to respond to them.