nginx 日誌和監控，nginx日誌監控

nginx 日誌和監控，nginx日誌監控

原文地址：http://nginx.com/resources/admin-guide/logging-and-monitoring/

Logging 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.

本文學習，如何配置錯誤記錄檔與處理請求，以及如何使用NGINX和NGINX+的即時監控服務。

In This Section  本章有

• Setting up the error log    搭建錯誤記錄檔
• Setting up the access log    搭建訪問日誌
• Logging to syslog      記錄到系統日誌
• Live activity monitoring     即時活動監控

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 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把遇到的不同層級的問題資訊寫到錯誤記錄檔。error_log 指令配置記錄到特定的檔案，stderr，或者syslog，配置寫到日誌的最低層級資訊。預設地，錯誤記錄檔位於logs/error.log(絕對路徑取決於作業系統和安裝方式），比指定層級更進階別的資訊都將被記錄。

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

下面這個配置把記錄到日誌的錯誤資訊的最低層級由 error 改為 warn。

error_log logs/error.log warn;

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

這樣warn, error, crit, alert, emger 層級的資訊都會被記錄。

The default setting of the error log works globally. To override it, the error_log directive should be placed in the main context. The settings of the main context are always inherited by other levels. The error_log directive can be specified on other levels too, cancelling 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 several error_log directives are specified on the same level, the message will be written to to all logs specified.

預設的錯誤記錄檔設定是全域的。要覆蓋它，error_log 指令必須放在main環境中。man環境裡的設定都會被其他層繼承。error_log指令也可以在其他層裡指定，以取消從更高層繼承下來的。如果發生一個錯誤，資訊只會被寫到一個錯誤記錄檔。這個日誌將寫到錯誤發生的最近的那一層。然而，如果在同一個層定義了多個error_log指令，資訊會被寫到所有指定的記錄檔。

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

注意：同一層使用多個錯誤記錄檔需要Nginx版本為1.5.2或更高。

Setting Up the Access Log
設定訪問日誌

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.

Nginx處理請求後把關於用戶端請求的資訊寫到訪問日誌。預設，訪問日誌位於 logs/access.log，寫到日誌的資訊是預定義的、組合的格式。要覆蓋預設的配置，使用log_format指令來配置一個記錄資訊的格式，同樣使用access_log 指令到設定日誌和格式和位置。格式定義使用變數。

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.

下面這個例子定義一個格式，這個格式在標準組合格式上進行擴充加入對響應進行gzip壓縮的比率的值。該格式被應用於一個開啟了壓縮的虛擬伺服器。

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 use the buffer parameter 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 directive.

開啟日誌資訊緩衝，被頻繁使用且名字包含變數的檔案的操作的緩衝，能夠最佳化日誌記錄。要開始緩衝，使用access_log指令的buffer參數來指定緩衝的大小。緩衝區裡的資訊在緩衝區不夠寫下一個資訊時以及另外的一些情況下寫入記錄檔。要開啟檔案操作的緩衝，使用open_log_file_cache指令。

Similar to the error_log directive, the access_log directive 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.

與error_log指令相似， 定義了access_log指令的層將會把從上一層繼承下來的設定覆蓋。當一個請求的處理完畢，資訊被寫到由當前層定義或者從上層繼承下來的記錄檔中。如果一個層裡定義了多個訪問日誌，資訊會被寫到所有日誌中。

Enabling 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.

根據條件的日誌記錄能不記錄細枝末節和不重要的日誌條目到訪問日誌中。在Nginx中，條件性日誌記錄使用access_log指令的 if 參數開啟。

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

例如，可以把狀態代碼以2和3開頭的HTTP請求忽略不計：

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

Logging to Syslog
記錄到系統日誌

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 directives.

系統日誌是一個電腦資訊記錄標準，能夠記錄來自不同裝置的日誌資訊到一個單一的系統Log Service器。在Nginx中，記錄到系統日誌要在error_log 和 access_log指令中加首碼 syslog: 來配置。

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 after the unix: prefix:

系統日誌資訊能被發送到一個server=，server=後面可以是一個網域名稱，一個IP地址或者一個unix-domain通訊端路徑。網域名稱或者ip地址能指定連接埠，預設連接埠為514，unix-domain通訊端路徑跟在首碼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 with the debug logging level, and the access log will be written to a syslog server with IPv6 address and port 1234.

本例中，Nginx錯誤記錄檔訊息以debug記錄層級記錄到 UNIX 域通訊端，訪問日誌將被記錄到一個IPv6地址商品為1234的系統Log Service器。

The facility= parameter specifies the type of program which is logging the message. The default value is local7. Other values may be: auth, authpriv, daemon, cron, ftp, lpr, kern, mail,news, syslog, user, uucp, local0 … local7.

參數facility=指定記錄日誌訊息的程式類型。預設值為local7，其他可用值有: 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 is nginx.

參數tag=在系統日誌訊息中應用一個自訂標籤，上例中標籤為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, and emerg. In our example, the severity level error will also enable crit, alert, and emerg levels to be logged.

參數severity=設定訪問日誌的系統日誌訊息的嚴重層級。可使用的值按嚴重層級順序遞增為：debug, info, notice, warn, error (default), crit, alert, and emerg。我們的例子中，嚴重層級error將開啟crit, alert, emerg 層級的記錄。

Live 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 + 提供一個即時活動監控介面，展示鍵的負載和上遊伺服器的效能指標，以及其他資料包括：

• NIGNX basic version, uptime and identification information;
• Nginx基礎版本，已耗用時間和認證資訊；
• total and current numbers of connections and requests;
• 串連和請求的當前數目以及總數目；
• request and response counts for each status_zone;
• 每個status_zone的請求和響應數；
• request and response counts per server in each dynamically configured groups of servers, plus health-check and uptime statistics;
• 每個伺服器動態配置組的請求和響應數，還有健康檢測和正常已耗用時間統計；
• statistics per server, including its current state and total values (total fails etc.)
• 統計每個伺服器，包含目前狀態和總體值（總體失敗次數等）。
• instrumentation for each named cache zone.
• 每個命名過的緩衝空間的檢測表。

The complete list of metrics is available here.

效能指標的完整列表點擊此處。

The statistics can be viewed from the status.html page already included in each NGINX Plus package. The page polls status information and displays it in a simple table:

統計資料可以從status.html頁面查看，該頁面已包含在每個Nginx+的包裡。頁面統計狀態資訊並且展示在一個簡單的表裡：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.

還可以使用一個簡單的 RESTful JSON 介面，可以通過第三方監控平台輕鬆串連這些狀態做一個即時儀錶盤。

Enabling 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 with /status and contains the status directive. To enable the status.html page, you must specify one more location that sets it:

要開啟即時活動監控和 JSON 介面，必須在精確匹配 /status 的 location 裡包含 status 指令。要啟用status.html頁面，你必須在至少一個location裡設定它：

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

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

根據這個配置，網頁status.html位於/usr/share/nginx/html能通過URL http://127.0.0.1/status.html 訪問到。

Using RESTful JSON Interface
使用 RESTful JSON 介面

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

Nginx+的統計能輕鬆串連到第三方應用，比如效能儀錶盤。可以通過JSON介面實現。

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.

如果你請求/status（或者任何一個能匹配這個location 組的URI），Nginx+將響應一個包含當前活動資料的JSON文檔。

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

JSON文檔的每一個元素的狀態資訊都可以通過在請求後用斜線分隔的URL來請求：

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 commercial subscriptions.