Nginx log and monitoring

Nginx log and monitoring

Address: http://nginx.com/resources/admin-guide/logging-and-monitoring/

Logging and Monitoring
Log and monitoring

This section describes how to configure logging of errors and processed requests, as well as how to use the runtime monitoring service of NGINX and NGINX Plus.

This article describes how to configure error logs and process requests, and how to use the real-time monitoring service of NGINX and NGINX +.

In This Section, we have

• Setting up the error log build error log
• Setting up the access log
• Logging to syslog records to system logs
• Live activity monitoring real-time activity monitoring Setting Up the Error Log
  Build 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 partifular 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.

  Nginx writes the problem information of different levels to the error log. The error_log command configuration records specific files, stderr, or syslog, and the minimum level of information written to the log. By default, the error log is located in logs/error. log (the absolute path depends on the operating system and installation method), and more advanced information than the specified level will be recorded.

  The configuration below changes the minimal severity level of error messages to log fromErrorToWarn.

  In the following configuration, the minimum error information recorded in the log is changed from error to warn.

  Error_log logs/error. log warn;

  In this case messagesWarn,Error,Crit,Alert, AndEmergLevels will be logged.

  In this way, information at the warn, error, crit, alert, and emger levels will be recorded.

  The default setting of the error log works globally. To override it,Error_logDirective shocould be placed inMainContext. The settings ofMainContext are always inherited by other levels.Error_logDirective can be specified on other levels too, canceling the effect inherited from the higher levels. in case of an error, the message will be written to only one error log. this log will be the closest to the level where the error has occurred. however, if severalError_logDirectives are specified on the same level, the message will be written to all logs specified.

  The default error log settings are global. To overwrite it, The error_log command must be placed in the main environment. All settings in the man environment are inherited by other layers. The error_log command can also be specified in other layers to cancel inheritance from higher layers. If an error occurs, only one error log is written. This log is written to the layer closest to the error. However, if multiple error_log commands are defined on the same layer, the information will be written to all specified log files.

  Note: Using several error log directives at the same level are supported in NGINX versions 1.5.2 and greater.

  Note: To use multiple error logs at the same layer, the Nginx version must be 1.5.2 or later.

  
  

  Setting Up the Access Log
  Set access logs

  To the access a log, NGINX writes information about client requests 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 configure a format of logged messages, as well as the access_log directive to specify the location of the log and the format. the format is defined using variables.

  After Nginx processes the request, it writes the information about the client request to the access log. By default, access logs are stored in logs/access. log. The information written to the log is in a predefined and combined format. To override the default configuration, use the log_format command to configure a record information format. Similarly, use the access_log command to set the log and format and location. The format definition uses variables.

  The following examples define a format that extends the standard combined format with the value indicating the ratio of gzip compression of the response. The format is then applied to a virtual server that enables compression.

  The following example defines a format in which gzip compression ratio is added to the response in the standard combination format. This format is applied to a virtual server with compression enabled.

  http {    log_format compression '$remote_addr - $remote_user [$time_local] '                           '"$request" $status $body_bytes_sent '                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';    server {        gzip on;        access_log /spool/logs/nginx-access.log compression;        ...    }}

  
  

  Logging can be optimized by enabling the buffer for log messages and the cache of descriptors of frequently used log files whose names contain variables. To enable buffering useBufferParameter of the access_log directive to specify the size of the buffer. the buffered messages are then written to the log file when the next log message does not fit into the buffer as well as in some other cases. to enable caching of log file descriptors, use the open_log_file_cache direve ve.

  Enable log information caching and cache operations on files that are frequently used and whose names contain variables to optimize log records. To start buffering, use the buffer parameter of the access_log command to specify the buffer size. The information in the buffer zone is written into the log file when the buffer zone is insufficient to write the next information. To enable the file operation cache, use the open_log_file_cache command.

  Similar toError_logDirective,Access_logDirective defined on a level overrides the settings from the previous levels. when processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. if one level defines multiple access logs, the message is written to all of them.

  Similar to the error_log command, the layer that defines the access_log command overwrites the settings inherited from the previous layer. After a request is processed, the information is written to the log file defined by the current layer or inherited from the upper layer. If multiple access logs are defined in a layer, the information is written to all logs.

  Enabling Conditional Logging
  Enable conditional Logging

  Conditional logging allows excluding trivial or non-important log entries from the access log. In NGINX, conditional logging is enabled by the if parameter of the access_log directive.

  The condition-based log records do not record minor and unimportant log entries to the access log. In Nginx, conditional logging is enabled using the if parameter of the access_log command.

  For example, it makes possible to exclude requests with HTTP status codes 2XX (Success) and 3XX (Redirection ):

  For example, you can ignore HTTP requests whose status codes start with 2 and 3:

  map $status $loggable {    ~^[23]  0;    default 1;}access_log /path/to/access.log combined if=$loggable;

  
  
  
  Logging to Syslog
  System logs recorded

  Syslog is a standard for computer message logging and allows collecting log messages from different devices on a single syslog server. in NGINX, logging to syslog is configured with the syslog: prefix in error_log and access_log ctictives.

  A system log is a computer information record standard that records logs from different devices to a single system log server. In Nginx, the prefix syslog must be added to the error_log and access_log commands to record system logs.

  Syslog messages can be sent to a server = which can be a domain name, an IP address, or a UNIX-domain socket path. A domain name or IP address can be specified with a port, by default port 514 is used. a unix-domain socket path can be specified afterUnix:Prefix:

  System log information can be sent to a server =, server = followed by a domain name, an IP address, or a unix-domain socket path. You can specify a port for the domain name or IP address. The default port is 514. the unix-domain socket path follows the prefix unix:

  error_log server=unix:/var/log/nginx.sock debug;access_log syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,severity=info;

  
  

  In the example, NGINX error log messages will be written to UNIX domain socket withDebugLogging level, and the access log will be written to a syslog server with IPv6 address and port 1234.

  In this example, the Nginx Error Log message is recorded to the UNIX domain socket at the debug log level, and the access log is recorded to a system log server with the IPv6 address commodity 1234.

  The facility = parameter specifies the type of program which is logging the message. The default value isLocal7. Other values may be:Auth,Authpriv,Daemon,Cron,Ftp,Lpr,Kern,Mail,News,Syslog,User,Uucp,Local0... Local7.

  Parameter facility = specifies the program type for logging messages. The default value is local7. Other available values include:Auth,Authpriv,Daemon,Cron,Ftp,Lpr,Kern,Mail,News,Syslog,User,Uucp,Local0... Local7.

  The tag = parameter will apply a custom tag to syslog messages, in our example the tag isNginx.

  Parameter tag = Apply a custom tag to the System Log message. In the preceding example, the tag is nginx.

  The severity = parameter sets the severity level of syslog messages for access log. Possible values in order of increasing severity are:Debug,Info,Notice,Warn,Error(Default ),Crit,Alert, AndEmerg. In our example, the severity levelErrorWill also enableCrit,Alert, AndEmergLevels to be logged.

  Parameter severity = sets the severity Level of the System Log message of the access log. The values that can be used increase sequentially by severity level:Debug,Info,Notice,Warn,Error(Default ),Crit,Alert, AndEmerg.In our example, critical level error will enable crit, alert, and emerg level records.

  Live Activity Monitoring
  Real-time activity monitoring

  NGINX Plus provides a real-time activity monitoring interface that shows key load and performance metrics of your upstream servers as well as other data including:

  Nginx + provides a real-time activity monitoring interface that displays the load of keys and performance metrics of upstream servers. Other data includes:

  • NIGNX basic version, uptime and identification information;
  • Basic Nginx version, running time, and authentication information;
  • Total and current numbers of connections and requests;
  • The current number and total number of connections and requests;
  • Request and response counts for each status_zone;
  • The number of requests and responses for each status_zone;
  • Request and response counts per server in each dynamically configured groups of servers, plus health-check and uptime statistics;
  • The number of requests and responses in each server dynamic configuration group, as well as health check and normal running time statistics;
  • Statistics per server, including its current state and total values (total fails etc .)
  • Count each server, including the current status and overall value (overall failure count, etc ).
  • Instrumentation for each named cache zone.
  • The detection table of each named cache space.

    The complete list of metrics is available here.

    Click here for a complete list of performance indicators.

    
    

    The statistics can be viewed fromStatus.htmlPage already embedded ded in each NGINX Plus package. The page polls status information and displays it in a simple table:

    Statistical data can be viewed on the status.html page, which is included in each Nginx + package. Page collects status information and displays it in a simple table: http://demo.nginx.com/status.html

    And using a simple RESTful JSON interface, it's easy to connect these stats to live dashboards and third-party monitoring tools.

    You can also use a simple RESTful JSON interface to easily connect to these statuses through a third-party monitoring platform for a real-time dashboard.

    Enabling Activity Monitoring
    Enable activity monitoring

    To enable real-time activity monitoring and the JSON interface, you must specify the location that checks the exact match of the URI/StatusAnd contains the status directive. To enableStatus.htmlPage, you must specify one more location that sets it:

    To enable real-time activity monitoring and JSON interfaces, you must include the status command in the location with exact match/status. To enable the status.html page, you must set it in at least one location:

    server {    listen 127.0.0.1;    root /usr/share/nginx/html;    location /status {        status;    }    location = /status.html {    }}

    
    With the following configuration, the webpageStatus.htmlLocated at/usr/share/nginx/html can be requested by the URL http: // 127.0.0.1/status.html.

    In this configuration, the webpage status.html is located in/usr/share/nginx/html and can be accessed through URL http: // 127.0.0.1/status.html.

    Using RESTful JSON Interface
    Use RESTful JSON Interface

    NGINX Plus stats can be easlily connected to third-party applications, such as performance dashboards. This can be done with the JSON interface.

    Nginx + statistics can be easily connected to third-party applications, such as performance dashboard. It can be implemented through the JSON interface.

    If you request/Status(Or whichever URI matches the location group), then NGINX Plus will respond with a JSON document containing the current activity data.

    If you request/status (or any URI that matches the location group), Nginx + will respond to a JSON file containing the current active data.

    The status information of any element in the JSON document can be requested by a slash-separated URL:

    The status information of each element in the JSON document can be requested by a URL separated by a slash after the request:

    Http: // 127.0.0.1/status
    Http: // 127.0.0.1/status/nginx_version
    Http: // 127.0.0.1/status/caches/cache_backend
    Http: // 127.0.0.1/status/upstreams
    Http: // 127.0.0.1/status/upstreams/backend
    Http: // 127.0.0.1/status/upstreams/backend/1
    Http: // 127.0.0.1/status/upstreams/backend/1/weight

    To learn more about NGINX Plus, please see the descriptions of our additional cial subscriptions.