Logging is essential part which needs to be configured properly. This will save yourself from any unknown troubles which it could get. It provides you with the data that allow us to troubleshoot and resolve. If there is any complex problem, it gives the error description. The line on which the error is appearing you can go and then resolve it by using corrected steps for the same.
In this article, we will go through the configuring logging for the Nginx. This will help you out to troubleshoot any unknown problems which may arise at any time.
The Error_Log Directive for Nginx:
Nginx uses has different directives to control the nginx access log. One of that is core module called “error_log”
Syntax of Error_log file
It is used to logging the general error messages. It may seem while using the Nginx. If your background is from Apache then this is similar to Apache’s Error Log directive.
It takes following syntax for Nginx error log format:
error_log log_file [ log_level ]
The log file in the example specifies the file where the logs will be generated. The log level specifies the lowest level of logging that you need to record.
Different Types of Nginx Logging Levels:
The error_log directives can be configured using one or more log level:
- Emerg: it is for emergency situation where the system is in unstable state.
- Alert: server situation where action is needed promptly.
- Crit: Important problems that need to be addressed.
- Error: An Error has occurred. Something was unsuccessful.
- Warn: Something out of the usual happened, but not a why distress.
- Notice: Something normal, but worth noting has happened.
- Info: An informational note that might be nice to know.
- Debug: Debugging information that can be practical to find where a setback is occurring.
The levels which are higher in the list are considered to be higher priority. If you specify level then the log will capture that level.
If you specify error then log will capture messages labelled as error, crit, alert and emerg.
In order to verify this directive we need to look in main configuration file:
sudo nano /etc./nginx/nginx.conf . . . access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; . . .
If you do not want that error_log log anything then send the output to /dev/null
error_log /dev/null crit;
HttpLogModule Logging Directives:
While the error_log directive is part of the core module. Acces_log directive is part of the HttpLogModule. It also provides you with the customize logs.
Please find below some other directives included with this module. It assists in configuring the custom logs:
The Nginx Log_format Directive:
It is use to describe the format of a log entry using plain text or variables.
Combined is predefined format coming along with Nginx. It is widely used by many servers.
Below is the look of combined format
log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';
The above will spans for multiple lines until it finds semi-colon (;)
The parameters which begin with $ sign indicates variables, characters like “-“,”[“,”]” are interpreted literally.
General syntax is as follow:
log_format format_name string_describing_formatting;
The Nginx Access_Log Directive:
It uses some similar syntax to the error_log directives. It is more flexible and it is used to configure custom logging.
Access_log use below syntax:
access_log /path/to/log/location [ format_of_log buffer_size ];
The default value of access_log is in the combined format. The buffer size is the maximum size of the data that Nginx will hold before writing it all to the log. In order to compress the log file add gzip into the definition which will zip the same:
access_log location format gzip;
Unlike error_log which you cannot off, if you do not want to use this logging you can turn it off by specifying:
There is no necessity to write to /dev/null/ in this case.
Log Rotation in Nginx:
Generating log files is not difficult. The difficulties will arise when those log files will grow at that point. It will be necessary to manage the logging mechanisms to avoid the disk full up issue. Its for this issue the Log Rotation is used. It is the process that switch out the log files and archive those which are older one for a configured amount of time.
Nginx does not give such tools to manage log files. It include a mechanism that make log rotation simpler below is the information for the same:
Manual Log Rotation in Nginx :
In case you are interested in manually rotating the logs, you can do the same. Here is an example for Nginx:
mv /path/to/access.log /path/to/access.log.0 kill -USR1 `cat /var/run/nginx.pid`
[ post-rotation processing of old log file ]
First line depicts moving of current log to a new file for archiving
Commonly you can name the most recent log file with suffix as 0 and then name older file with 1 and so on.
kill -USR1 `cat /var/run/nginx.pid`
above command will actually rotates the logs. It does not kill the Nginx process but instead send signal causing it to reload the log files. Which in turn result into new requests to be logged to the refreshed log file.
The nginx.pid file is where Nginx stores the master process’s pid. The same is specified in the configuration file with a line that begins with pid specified in the configuration file with a line that begins with "pid":
sudo nano /etc/nginx/nginx.conf . . . pid /path/to/pid/file; . . .
After rotation we execute sleep 1. This allows the process to complete transfer. After that we can also zip the file or whatever steps we want to do for the same.
Ngnix Log Rotation with logrotate
It is a simple program to rotate logs. It is by default installed on the Ubuntu and Nginx on Ubuntu come with a custom logrotate script too. In order to see the same type
sudo nano /etc/logrotate.d/nginx
Hence now you must have felt Ngnix logging is simple. To manage the logging growing is hard. This could be done by such Log Rotation Mechanisms. Hope you have understood the concepts. Do stay connected for more topics to update your knowledge.