Introduction

Logging is a tool that helps record the activity history of the nginx system, very useful for debugging later.

Learn about log files

By default, nginx will automatically save logs, use the following command to view the default log files

ls -lh /var/log/nginx/

result

# -rw-r----- 1 www-data adm     0 Apr 25 07:34 access.log
# -rw-r----- 1 www-data adm     0 Apr 25 07:34 error.log

These are the default log files of nginx, now we will delete the contents of the 2 files through the following commands

Step 1: delete the file

sudo rm /var/log/nginx/access.log /var/log/nginx/error.log

Step 2: create a new file

sudo touch /var/log/nginx/access.log /var/log/nginx/error.log

Step 3: restart nginx

sudo nginx -s reopen

Now let's try to check if the system has successfully logged by the following commands:

Step 1: Call any URL

curl -I http://nglearns.test

Step 2: Open the log file

sudo cat /var/log/nginx/access.log 

Result

# 192.168.20.20 - - [25/Apr/2021:08:35:59 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.68.0"

As you can see, we can see that the log has been written to the correct file.

Control logging

We can control which file to log to as desired. Please refer to the following example:

events {
}

http {
  include /etc/nginx/mime.types;
  server {
    listen 80;
    server_name nglearns.test;

    location / {
      return 200 "this will be logged to the default file.\n";
    }

    location = /admin {
      access_log /var/logs/nginx/admin.log;
        
      return 200 "this will be logged in a separate file.\n";
    }
    
    location = /no_logging {
      access_log off;
      
      return 200 "this will not be logged.\n";
    }
  }
}

Here, we can see that we use access_log in /admin to request nginx to write logs to the admin.log file. In /no_logging, we request nginx to stop logging on the requested file with the access_log off command

To verify, we will practice as follows:

curl http://nginx-handbook.test/no_logging
# this will not be logged

sudo cat /var/log/nginx/access.log
# empty

curl http://nginx-handbook.test/admin
# this will be logged in a separate file.

sudo cat /var/log/nginx/access.log
# empty

sudo cat /var/log/nginx/admin.log 
# 192.168.20.20 - - [25/Apr/2021:11:13:53 +0000] "GET /admin HTTP/1.1" 200 40 "-" "curl/7.68.0"

curl  http://nginx-handbook.test/
# this will be logged to the default file.

sudo cat /var/log/nginx/access.log 
# 192.168.20.20 - - [25/Apr/2021:11:15:14 +0000] "GET / HTTP/1.1" 200 41 "-" "curl/7.68.0"

With this example, we can see how the logging operation works correctly with the settings.

Log errors

Alternatively, nginx error logging is by default written to the error.log file.

Follow the example below

events {
}

http {
  include /etc/nginx/mime.types;

  server {
    listen 80;
    server_name nglearns.test;
    return 200 "..." "...";
  }
}

In this case, we have returned 2 values instead of one, for this reason, the nginx system will not work correctly and will return an error.

Experiment:

Step 1: reload the system

sudo nginx -s reload

Step 2: Check log file

sudo nginx -s reload

Immediately, the system will display the error message as follows

# nginx: [emerg] invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Step 3: check if the error has been logged

sudo cat /var/log/nginx/error.log 

result

# 2021/04/25 08:35:45 [notice] 4169#4169: signal process started
# 2021/04/25 10:03:18 [emerg] 8434#8434: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Priority

Encountering error logs mostly does not harm the system, however, when encountering emerg errors, it needs to be handled immediately as this is a serious error.

Here are some levels that need to be known when working with error logs:

• debug: basic error logs that usually come with the line number of the error
• info: information that is not really necessary, but it's good to know about it
• notice: common errors that need attention
• warn: unexpected errors, but not worth worrying about
• error: errors of a failed behavior, need to be fixed to ensure system stability
• crit: errors that need to be seriously addressed
• alert: errors that need to be fixed as soon as possible
• emerg: extremely dangerous errors, need to be fixed immediately

In fact, controlling the priority of logs is entirely possible, please refer to the following example

events {
}

http {
  include /etc/nginx/mime.types;
  server {
    listen 80;
    server_name nglearns.test;
  error_log /var/log/error.log warn;
    return 200 "..." "...";
  }
}

In this example, we have successfully logged with a priority of warn