在Kubernetes中監控Nginx

1、為什麼選擇 Nginx

Nginx 是一個 web 伺服器，常用作反向代理、負載均衡以及 web 快取。天生具有高併發能力，並且具有速度快、功能豐富、可靠性高以及佔用資源少等諸多優點。

Nginx 在容器化/雲端部署方面十分普遍，並且根據最新的 Docker 使用報告，在 45000 個樣本容器中，使用量最大的就是 nginx。

Nginx 可以作為一個 Web 應用伺服器，也可以一組微服務的閘道器或負載，甚至可以作為網路入口(Internet-facing entrypoint)(就好像 Kubernetes 的 Ingress 控制器那樣)。當作為負載均衡器時，與 nginx 相似的其他可供選擇的方案有：HAProxy、新流行起來的 Linkerd、像 AWS ELB 那樣的公有云、或者負載均衡器硬體裝置。

2、Nginx的 stub_status 配置

為了能夠暴露出nginx 的內部執行情況(internal performance metrics)和連線狀態(connection status metrics)，需要啟用 stub_status 模組。付費版的 Nginx Plus 可以提供一些額外的監控維度，能夠通過 status 模組更好的展現連線狀態報告(connection status reporting )和 HTTP 返回碼計數(HTTP return code counters)，儘管如此，稍後 Sysdig 也能夠將為大家呈現其中的部分資訊。

預設情況下，nginx 的 Docker 官方映象 和常見的 linux 發行版的二進位制包中，已經包含了該模組。

執行 nginx -V，查詢其中的 –with-http_stub_status_module 來確定該模組是否被啟用。

$ docker exec -ti nginx nginx -V
 nginx version: nginx/1.11.13
 built by gcc 4.9.2 (Debian 4.9.2-10)
 built with OpenSSL 1.0.1t 3 May 2016
 TLS SNI support enabled
 configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
 ... --with-http_stub_status_module
 ...

如果你需要引入一些必要的額外的配置來啟用該模組，可以使用 kubernetes 的 ConfigMap。如果你需要一些自定義的配置，也可以直接自定義一個 Nginx 映象。

下面是 nginx 的預設配置檔案nginx.conf，在 /nginx_status 裡啟用 stub_status ，然後將請求代理到一個 Kubernetes 的 wordpress 服務中。

server {
 server_name _;

location /nginx_status {
 stub_status on;
 access_log on;
 allow all; # REPLACE with your access policy }

location / {
 proxy_pass http://wordpress:5000;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_redirect off; } }

[檢視完整的 nginx.conf 檔案]

下面建立 ConfigMap 來應用我們剛才建立的 nginx.conf 配置檔案：

$ kubectl create configmap nginxconfig --from-file nginx.conf

接下來就可以在 Kubernetes 中通過 Deployment, ReplicaSet 或者 ReplicationController 來建立 nginx 容器，然後通過 Service 暴露為一個 Kubernetes 服務：

$ kubectl create -f nginxrc.yaml

檢視完整的 nginxrc.yaml 檔案]

3、檢視Nginx的狀態

如果使用類似curl的命令請求我們剛剛配置好的服務連結，應該得到類似下面這樣的內容：

$ curl nginx-wordpress/nginx_status
 Active connections: 6
 server accepts handled requests
 100956 100956 101022 Reading: 0 Writing: 4 Waiting: 2

這僅僅是個開始，你可以想要得到更多的監控資訊，比如：historical data, graphs, dashboards, alerts…

可以通過 Kubernetes 的 metadata 和 labels 來配置所有的這些監控維度，之後你就可以得到像“每個服務的平均請求時間(Average request time per service)”或者在程式日誌中可以看到的一些像 “top HTTP requests” 和 “slowest HTTP requests” 等比較常見的資訊。所有這些 nginx 的狀態模組提供的監控維度資訊， Sysdig Monitor 也都可以實現。

你可以開啟一個 SysDig Monitor 的免費版本 , 這裡 介紹瞭如何使用 Kubernetes 的 DaemonSet 來安裝代理。

4、Nginx 的監控維度

A、Nginx 連線

Nginx 提供了來自於客戶端的 TCP 連線資訊，以及這些連線相關聯的 HTTP 請求和響應資訊。在 HTTP/1 中每個請求只需要一個連線，但是在 HTTP/2 中每個連線中可能會發起多次請求。為了加速請求，這些長連線可能會一直保持開啟等待狀態，來等待處理同一個客戶端可能會發生的多次請求，這個也叫做 Keepalive。

• 網路連線 nginx.can_connect：一個檢查 nginx 服務是否可用的二進位制值
• 當前連線數 nginx.net.connections：當前啟用的總連線數
• 每秒產生的新連線數 nginx.net.conn_opened_per_s：每秒產生新連線的速度，和上面的 nginx.net.connections 對比一下，你就可以得到一個有效的吞吐量值。
• 每秒被丟棄的連線數 nginx.net.conn_dropped_per_s：被 nginx 伺服器每秒丟棄的連線數，丟棄的原因可能是無效的客戶端請求、伺服器端的速率限制或者其他的 nginx 配置規則。

B、Nginx HTTP 應用維度

Nginx+ 中可以看到 HTTP 響應碼，但如果想要看到像請求時間這樣的更高階的維度資訊，我們需要在日誌模組(log module)中開啟 $request_time，這樣通過日誌系統就可以計算請求時間了。

SysDig Monitor 有更加簡便的方法。沒有必要去做這些複雜的配置，從日誌裡來計算這些維度，只需要取出 nginx 對於 sockets 檔案描述符關於 read() 和 write() 等系統呼叫的裝載量就可以自動完成這些統計。通過這種方式，無需任何程式碼，SysDig 將提供一些有趣的 HTTP 協議應用層的資訊。

• Top URLs： net.request.count|net.http.request.count segmented by net.http.url：Rate of hits per HTTP URL. 在監控使用者行為、最受歡迎資源和檢查異常連線方面非常有用。
• Slowest URLs： net.http.url segmented by net.http.request.time: 所有連線當中最耗時間的。這些是你需要去利用的關於系統總體反應的潛在瓶頸。
• HTTP 返回碼： net.http.statusCode：HTTP 返回碼可以提供大量的關於服務健康狀況的有用資訊，更多見這裡。
• 服務請求時間：net.request.time|net.http.request.time兩者的平均值。

下表介紹了各種維度，以及它們的來源：

C、nginx 的系統和資源維度

這裡我們也應該關注一下系統資源的監控情況：

• CPU 使用率 cpu.used.percent
• 平均負載，load.average.percpu.1m, 5m, 15m
• 記憶體使用，包括固定時間段(absolute terms) memory.bytes.used(雖然名字為bytes，但是顯示出來的是更容易讀的Mega or Giga)和百分比 memory.used.percent
• 總 IOPS ，file.iops.total 比如，你正在使用本地內容快取(a local content cache)
• 網路狀況 net.bytes.total, net.bytes.in, net.bytes.out，通過這些你可以知道是否達到了網路峰值，是否該升級網路了
• 網路錯誤計數 net.error.count 連結問題，注意其中的 HTTP-level error codes(Net error count net.error.count connectivity problems, not to be confused with the HTTP-level error codes.)

現在我們已經討論了最重要的維度，下面我們來看看如何將它們視覺化以及我們能用他們來幹什麼。

5、Nginx Dashboards

你可以在 Dashboard tab 中建立 Nginx Dashboard，點選 ADD DASHBOARD 然後找到 nginx 模板。通過 scope 可以選擇 kubernetes 的資源維度比如 node, namespace, Service, Deployment, 甚至想 AWS 區域 這樣的也是可能的。

一旦建立了 Dashboard 就可以自定義它了：新增/刪除圖表、改變 scope 或者 segmentation of each graph，檢視圖表事件，改變大小等等。

預設的 Dashboard 包括：連線狀態(讀、寫、等待)、CPU 負載、網路狀況、每秒請求、Top URLs、Slowest URLs、啟用的連線、丟棄的連線和響應碼。

HTTP 控制檯模板(HTTP dashboard template) 包含一些應用層的維度(metrics)，比如：平均請求時間、最大請求時間和請求型別（GET,POST等），你可以用Copy Panel按鈕將多個你感興趣的維度合併成一個，也可以將他們的組合放到另一個控制檯中去。

A、使用 Kubernetes 標籤監控 Nginx

在像 kubernetes 這樣的微服務架構的平臺中，你可能除了監控應用層的 nginx 維度外，也想知道單個的容器或者 pod 的情況。這時就可以使用 kubernetes 裡 metadata 中的 labels 屬性了，但是使用 SysDig 的話，你就可以使用任何可用的 metadata 了，不管是來自 kubernetes 還是 docker 或者是 AWS 這樣的雲服務提供商。

B、通過 Kubernetes 名稱空間進行隔離

假設你有 development , staging 和 production 3 個完全隔離的名稱空間環境。而你現在可能想知道每秒鐘每個環境都有多少請求，這時我們就可以用 kubernetes.namespace.name：

一種更普遍的情況是，在你的 CI/CD Pipeline中，你需要實時的知道生產環境和Stage環境的對比情況。我們再來對比一下生產環境和Stage環境的每秒處理請求情況：

再來看看 HTTP 錯誤響應：

根據這張圖，好像 stage 環境還是有一些問題，不能推到 production 環境中。

C、Kubernetes 服務維度的分割

在微服務架構中，我們最想知道的就是每個子服務的情況。通常我們都想找出來哪個子服務最慢，也就是說到底誰是整個應用的瓶頸所在。

在這個例子中，我們每個服務都對應一個 ReplicationController，這樣請求就可以被有效的分割開。一般情況下，你可以使用 kubernetes.replicationController.name 或kubernetes.service.name 來分割時序圖表中的任何維度。

比如你想要知道哪一個服務需要更大的頻寬：

或者每秒接收到更多的請求：

另一種常見情況是你想要知道哪一個服務在處理使用者請求上花費了更多的時間。SysDig 可以不新增任何額外的程式碼而且不需要伴隨監控容器(sidecar monitoring container)等複雜配置的情況下給出每一個微服務的響應時間。這可能是在微服務架構裡，一旦出問題最有效最直接的解決問題的切入點了。

可能你在某一個確定的時間段內發現應用出現了一些問題，而想要找到每個服務在這個時間段內的 HTTP error 統計。

D、按 Pod 維度統計

想要一個以每個容器的折線圖統計？只需要按 pod.name 分組即可：

特別有趣的是，當你尋找某個容器的表現與同一個服務中的其他容器表現不一致時，也可以輕鬆的建立出來：

E、以 HTTP 響應碼和 HTTP 方法分組

我們之前已經闡述過了 nginx 監控維度，連帶著也說了像 response time, HTTP URL, response code or HTTP method 這樣的應用維度。
監控 HTTP 方法（POST, GET, PUT, PATCH, DELETE…）可以審計客戶端是如何訪問你的 REST APIs 的。
HTTP 響應碼在你應用的 API 層面上可以提供大量的有用資訊。你不能僅僅只關注 404 和 500 這樣的錯誤，更要關注一些像 disallowed methods, bad gateway 和 gateway timeouts 這樣的錯誤：

也許你已經猜到了，當監控到太多的 4xx 或者 5xx 這樣的錯誤時，就改告警了。

6、總結

Nginx 在雲端計算中舉足輕重。他的靈活性和簡潔性意味著它既可以做一些簡單的部署任務，在複雜的情況下也能有出色的表現。他佔用資源如此之少，你甚至在做多節點高可用性的時候都不需要猶豫。

Nginx 伺服器通常在你的雲服務基礎設施中佔有特權位置，用來分析服務響應、監控瓶頸和後臺失敗告警，不要錯過充分利用這些監控資訊的機會。SysDig 既能監控 Nginx 的應用層，比如：service response time, HTTP methods, response code and top 和 slowest URls，也可以在不用其他額外的編碼的情況下監控微服務架構。

持續關注本系列的第二篇文章，我們將介紹 nginx 的一般失敗告警配置和本章所提到的一些使用示例。

本文轉自中文社群-在Kubernetes中監控Nginx