[Nginx Best Practices] Logging time in Nginx

Posted on Edited on In , , Views: Word count in article: 4.3k Reading time ≈ 4 mins.

Logging and Timing

The access logging in NGINX is very flexible that you can use to analyze the load and performance of your system. You can also define customized log formats for your application.

Setting Up the Access Log

NGINX writes information about client requests in the access log right after the request is processed. By default, the access log is located at logs/access.log, and the information is written to the log in the predefined combined format. To override the default setting, use the log_format directive to change the format of logged messages, as well as the access_log directive to specify the location of the log and its format. The log format is defined using variables.

NGINX timing variables

You can use the following variables to log the indicated time values:

  • $upstream_connect_time – The time spent on establishing a connection with an upstream server

  • $upstream_header_time – The time between establishing a connection and receiving the first byte of the response header from the upstream server

  • $upstream_response_time – The time between establishing a connection and receiving the last byte of the response body from the upstream server

  • $request_time – The total time spent processing a request

All time values are measured in seconds with millisecond resolution.

/images/Software-Package/Web-Server/Nginx/Nginx-Logging-and-Timing.jpg

Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
http {

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

    log_format upstream_time '$remote_addr - $remote_user [$time_local] '
                             '"$request" $status $body_bytes_sent '
                             '"$http_referer" "$http_user_agent"'
                             'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';

    log_format apm '"$time_local" client=$remote_addr '
                'method=$request_method request="$request" '
                'request_length=$request_length '
                'status=$status bytes_sent=$bytes_sent '
                'body_bytes_sent=$body_bytes_sent '
                'referer=$http_referer '
                'user_agent="$http_user_agent" '
                'upstream_addr=$upstream_addr '
                'upstream_status=$upstream_status '
                'request_time=$request_time '
                'upstream_response_time=$upstream_response_time '
                'upstream_connect_time=$upstream_connect_time '
                'upstream_header_time=$upstream_header_time';

    server {
        access_log /spool/logs/nginx-access.log debug_format;
        # ...
    }
}

Setting Up the Error Log

NGINX writes information about encountered issues of different severity levels to the error log. The error_log directive sets up logging to a particular file, stderr, or syslog and specifies the minimal severity level of messages to log. By default, the error log is located at logs/error.log (the absolute path depends on the operating system and installation), and messages from all severity levels above the one specified are logged.

The configuration below changes the minimal severity level of error messages to log from error to warn:

1
error_log logs/error.log warn;

In this case, messages of warn, error crit, alert, and emerg levels are logged.

The default setting of the error log works globally. To override it, place the error_log directive in the main (top-level) configuration context. Settings in the main context are always inherited by other configuration levels (http, server, location). The error_log directive can be also specified at the http, stream, server and location levels and overrides the setting inherited from the higher levels. In case of an error, the message is written to only one error log, the one closest to the level where the error has occurred. However, if several error_log directives are specified on the same level, the message are written to all specified logs.

Note: The ability to specify multiple error_log directives on the same configuration level was added in NGINX Open Source version 1.5.2.

References

[1] Using NGINX Logging for Application Performance Monitoring - https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/

[2] NGINX Docs | Configuring Logging - https://docs.nginx.com/nginx/admin-guide/monitoring/logging/

[3] log_format | Module ngx_http_log_module - https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format

[4] access_log | Module ngx_http_log_module - https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log

[5] Core functionality - https://nginx.org/en/docs/ngx_core_module.html#error_log

[6] NGINX | High Performance Load Balancer, Web Server, & Reverse Proxy - https://www.nginx.com/