如何監控 NGINX（第一篇）

NGINX 是什么?

NGINX (發音為 “engine X”) 是一種流行的 HTTP 和反向代理服務器。作為一個 HTTP 服務器，NGINX 可以使用較少的內存非常高效可靠地提供靜態內容。作為反向代理，它可以用作多個后端服務器或類似緩存和負載平衡這樣的其它應用的單一訪問控制點。NGINX 是一個自由開源的產品，并有一個具備更全的功能的叫做 NGINX Plus 的商業版。

NGINX 也可以用作郵件代理和通用的 TCP 代理，但本文并不直接討論 NGINX 的那些用例的監控。

NGINX 主要指標

通過監控 NGINX 可以 捕獲到兩類問題：NGINX 本身的資源問題，和出現在你的基礎網絡設施的其它問題。大多數 NGINX 用戶會用到以下指標的監控，包括每秒請求數，它提供了一個由所有最終用戶活動組成的上層視圖；服務器錯誤率 ，這表明你的服務器已經多長沒有處理看似有效的請求；還有請求處理時間，這說明你的服務器處理客戶端請求的總共時長（并且可以看出性能降低或當前環境的其他問題）。

更一般地，至少有三個主要的指標類別來監視：

• 基本活動指標
• 錯誤指標
• 性能指標

下面我們將分析在每個類別中最重要的 NGINX 指標，以及用一個相當普遍但是值得特別提到的案例來說明：使用 NGINX Plus 作反向代理。我們還將介紹如何使用圖形工具或可選擇的監控工具來監控所有的指標。

本文引用指標術語來自我們的“監控 101 系列”,，它提供了一個指標收集和警告框架。

基本活躍指標

無論你在怎樣的情況下使用 NGINX，毫無疑問你要監視服務器接收多少客戶端請求和如何處理這些請求。

NGINX Plus 上像開源 NGINX 一樣可以報告基本活躍指標，但它也提供了略有不同的輔助模塊。我們首先討論開源的 NGINX，再來說明 NGINX Plus 提供的其他指標的功能。

NGINX

下圖顯示了一個客戶端連接的過程，以及開源版本的 NGINX 如何在連接過程中收集指標。

connection, request states

Accepts（接受）、Handled（已處理）、Requests（請求）是一直在增加的計數器。Active（活躍）、Waiting（等待）、Reading（讀）、Writing（寫）隨著請求量而增減。

*嚴格的來說，丟棄的連接是 一個資源飽和指標，但是因為飽和會導致 NGINX 停止服務（而不是延后該請求），所以，“已丟棄”視作 一個工作指標 比較合適。

NGINX worker 進程接受 OS 的連接請求時 Accepts 計數器增加，而Handled 是當實際的請求得到連接時（通過建立一個新的連接或重新使用一個空閑的）。這兩個計數器的值通常都是相同的，如果它們有差別則表明連接被Dropped，往往這是由于資源限制，比如已經達到 NGINX 的worker_connections的限制。

一旦 NGINX 成功處理一個連接時，連接會移動到Active狀態，在這里對客戶端請求進行處理：

Active狀態

• Waiting: 活躍的連接也可以處于 Waiting 子狀態，如果有在此刻沒有活躍請求的話。新連接可以繞過這個狀態并直接變為到 Reading 狀態，最常見的是在使用“accept filter（接受過濾器）” 和 “deferred accept（延遲接受）”時，在這種情況下，NGINX 不會接收 worker 進程的通知，直到它具有足夠的數據才開始響應。如果連接設置為 keep-alive ，那么它在發送響應后將處于等待狀態。

• Reading: 當接收到請求時，連接離開 Waiting 狀態，并且該請求本身使 Reading 狀態計數增加。在這種狀態下 NGINX 會讀取客戶端請求首部。請求首部是比較小的，因此這通常是一個快速的操作。

• Writing: 請求被讀取之后，其使 Writing 狀態計數增加，并保持在該狀態，直到響應返回給客戶端。這意味著，該請求在 Writing 狀態時， 一方面 NGINX 等待來自上游系統的結果（系統放在 NGINX “后面”），另外一方面，NGINX 也在同時響應。請求往往會在 Writing 狀態花費大量的時間。

通常，一個連接在同一時間只接受一個請求。在這種情況下，Active 連接的數目 == Waiting 的連接 + Reading 請求 + Writing 。然而，較新的 SPDY 和 HTTP/2 協議允許多個并發請求/響應復用一個連接，所以 Active 可小于 Waiting 的連接、 Reading 請求、Writing 請求的總和。 （在撰寫本文時，NGINX 不支持 HTTP/2，但預計到2015年期間將會支持。）

NGINX Plus

正如上面提到的，所有開源 NGINX 的指標在 NGINX Plus 中是可用的，但另外也提供其他的指標。本節僅說明了 NGINX Plus 可用的指標。

connection, request states

Accepted （已接受）、Dropped，總數是不斷增加的計數器。Active、 Idle（空閑）和處于 Current（當前）處理階段的各種狀態下的連接或請求的當前數量隨著請求量而增減。

*嚴格的來說，丟棄的連接是 一個資源飽和指標，但是因為飽和會導致 NGINX 停止服務（而不是延后該請求），所以，“已丟棄”視作 一個工作指標 比較合適。

當 NGINX Plus worker 進程接受 OS 的連接請求時 Accepted 計數器遞增。如果 worker 進程為請求建立連接失敗（通過建立一個新的連接或重新使用一個空閑），則該連接被丟棄， Dropped 計數增加。通常連接被丟棄是因為資源限制，如 NGINX Plus 的worker_connections的限制已經達到。

Active 和 Idle 和如上所述的開源 NGINX 的“active” 和 “waiting”狀態是相同的，但是有一點關鍵的不同：在開源 NGINX 上，“waiting”狀態包括在“active”中，而在 NGINX Plus 上“idle”的連接被排除在“active” 計數外。Current 和開源 NGINX 是一樣的也是由“reading + writing” 狀態組成。

Total 為客戶端請求的累積計數。請注意，單個客戶端連接可涉及多個請求，所以這個數字可能會比連接的累計次數明顯大。事實上，（total / accepted）是每個連接的平均請求數量。

開源 和 Plus 之間指標的不同

提醒指標: 丟棄連接

被丟棄的連接數目等于 Accepts 和 Handled 之差（NGINX 中），或是可直接得到標準指標（NGINX Plus 中）。在正常情況下，丟棄連接數應該是零。如果在每個單位時間內丟棄連接的速度開始上升，那么應該看看是否資源飽和了。

Dropped connections

提醒指標: 每秒請求數

按固定時間間隔采樣你的請求數據（開源 NGINX 的requests或者 NGINX Plus 中total） 會提供給你單位時間內（通常是分鐘或秒）所接受的請求數量。監測這個指標可以查看進入的 Web 流量尖峰，無論是合法的還是惡意的，或者突然的下降，這通常都代表著出現了問題。每秒請求數若發生急劇變化可以提醒你的環境出現問題了，即使它不能告訴你 確切問題的位置所在。請注意，所有的請求都同樣計數，無論 URL 是什么。

Requests per second

收集活躍指標

開源的 NGINX 提供了一個簡單狀態頁面來顯示基本的服務器指標。該狀態信息以標準格式顯示，實際上任何圖形或監控工具可以被配置去解析這些相關數據，以用于分析、可視化、或提醒。NGINX Plus 提供一個 JSON 接口來供給更多的數據。閱讀相關文章“NGINX 指標收集”來啟用指標收集的功能。

錯誤指標

NGINX 錯誤指標告訴你服務器是否經常返回錯誤而不是正常工作。客戶端錯誤返回4XX狀態碼，服務器端錯誤返回5XX狀態碼。

提醒指標: 服務器錯誤率

服務器錯誤率等于在單位時間（通常為一到五分鐘）內5xx錯誤狀態代碼的總數除以狀態碼（1XX，2XX，3XX，4XX，5XX）的總數。如果你的錯誤率隨著時間的推移開始攀升，調查可能的原因。如果突然增加，可能需要采取緊急行動，因為客戶端可能收到錯誤信息。

Server error rate

關于客戶端錯誤的注意事項：雖然監控4XX是很有用的，但從該指標中你僅可以捕捉有限的信息，因為它只是衡量客戶的行為而不捕捉任何特殊的 URL。換句話說，4xx出現的變化可能是一個信號，例如網絡掃描器正在尋找你的網站漏洞時。

收集錯誤度量

雖然開源 NGINX 不能馬上得到用于監測的錯誤率，但至少有兩種方法可以得到：

• 使用商業支持的 NGINX Plus 提供的擴展狀態模塊
• 配置 NGINX 的日志模塊將響應碼寫入訪問日志

關于這兩種方法，請閱讀相關文章“NGINX 指標收集”。

性能指標

提醒指標: 請求處理時間

請求處理時間指標記錄了 NGINX 處理每個請求的時間，從讀到客戶端的第一個請求字節到完成請求。較長的響應時間說明問題在上游。

收集處理時間指標

NGINX 和 NGINX Plus 用戶可以通過添加 $request_time 變量到訪問日志格式中來捕捉處理時間數據。關于配置日志監控的更多細節在NGINX指標收集。

反向代理指標

反向代理是 NGINX 最常見的使用方法之一。商業支持的 NGINX Plus 顯示了大量有關后端（或“上游 upstream”）的服務器指標，這些與反向代理設置相關的。本節重點介紹了幾個 NGINX Plus 用戶可用的關鍵上游指標。

NGINX Plus 首先將它的上游指標按組分開，然后是針對單個服務器的。因此，例如，你的反向代理將請求分配到五個上游的 Web 服務器上，你可以一眼看出是否有單個服務器壓力過大，也可以看出上游組中服務器的健康狀況，以確保良好的響應時間。

活躍指標

每上游服務器的活躍連接的數量可以幫助你確認反向代理是否正確的分配工作到你的整個服務器組上。如果你正在使用 NGINX 作為負載均衡器，任何一臺服務器處理的連接數的明顯偏差都可能表明服務器正在努力消化請求，或者是你配置使用的負載均衡的方法（例如round-robin 或 IP hashing）不是最適合你流量模式的。

錯誤指標

錯誤指標，上面所說的高于5XX（服務器錯誤）狀態碼，是監控指標中有價值的一個，尤其是響應碼部分。 NGINX Plus 允許你輕松地提取每個上游服務器的 5xx 錯誤代碼的數量，以及響應的總數量，以此來確定某個特定服務器的錯誤率。

可用性指標

對于 web 服務器的運行狀況，還有另一種角度，NGINX 可以通過每個組中當前可用服務器的總量很方便監控你的上游組的健康。在一個大的反向代理上，你可能不會非常關心其中一個服務器的當前狀態，就像你只要有可用的服務器組能夠處理當前的負載就行了。但監視上游組內的所有工作的服務器總量可為判斷 Web 服務器的健康狀況提供一個更高層面的視角。

收集上游指標

NGINX Plus 上游指標顯示在內部 NGINX Plus 的監控儀表盤上，并且也可通過一個JSON 接口來服務于各種外部監控平臺。在我們的相關文章“NGINX指標收集”中有個例子。

結論

在這篇文章中，我們已經談到了一些有用的指標，你可以使用表格來監控 NGINX 服務器。如果你是剛開始使用 NGINX，監控下面提供的大部分或全部指標，可以讓你很好的了解你的網絡基礎設施的健康和活躍程度：

• 已丟棄的連接
• 每秒請求數
• 服務器錯誤率
• 請求處理數據

最終，你會學到更多，更專業的衡量指標，尤其是關于你自己基礎設施和使用情況的。當然，監控哪一項指標將取決于你可用的工具。參見相關的文章來逐步指導你的指標收集，不管你使用 NGINX 還是 NGINX Plus。

在 Datadog 中，我們已經集成了 NGINX 和 NGINX Plus，這樣你就可以以最少的設置來收集和監控所有 Web 服務器的指標。 在本文中了解如何用 NGINX Datadog來監控，并開始免費試用 Datadog吧。

誠謝

在文章發表之前非常感謝 NGINX 團隊審閱這篇，并提供重要的反饋和說明。

via: https://www.datadoghq.com/blog/how-to-monitor-nginx/

作者：K Young 譯者：strugglingyouth 校對：wxy

本文由 LCTT 原創翻譯，Linux中國 榮譽推出