nginx監控之 監控我所需要的
阿新 • • 發佈：2019-01-24
https 方式 後端 ror 日誌 連接數 對比 模塊化 接受 apache和nginx對比
相比 Apache 服務器，Nginx 因其采用的異步非阻塞工作模型，使其具備高並發、低資源消耗的特性，高度模塊化設計使 Nginx 具備很好的擴展性；在處理靜態文件、反向代理請求等方面，Nginx 表現出很大的優勢。
常見的nginx用途
Nginx 可以作為反向代理服務器來轉發用戶請求；並能夠在處理請求的過程中實現後端實例負載均衡，實現分發請求的功能；也可將 Nginx 配置為本地靜態服務器，處理靜態請求。
監控nginx需要的指標
Nginx 處理請求的過程被詳細地記錄在 access.log 以及 error.log 文件中
| 監控項目 | 所屬性質 | 指標 |
|---|---|---|
| 請求時長 | 服務性質 | 從發出請求到結束需要的時間$request_time 和 $upstream_response_time |
| 服務存活性 | 服務性質 | nginx是否存活 |
| 請求返回錯誤 | 服務性質 | 服務器日誌方式錯誤碼4xx和5xx |
| 流量 | 服務性質 | pv 和 流量 |
| 服務損耗 | 服務性質 | 連接數 打開文件數 cpu使用率和綁定cpu核心的使用率 |
請求時長
log_format main ‘$remote_addr - $remote_user [$time_local] "$request" ‘ ‘$status $body_bytes_sent "$http_referer" ‘ ‘"$http_user_agent" "$http_x_forwarded_for" "$request_time" "$upstream_response_time" ‘; 添加上"$request_time" 和"$upstream_response_time"
這樣在後面顯示請求體和時間，根據自己請求的時長容忍度來實現程序層面的請求接口優化或者緩存
nginx是否存活
檢查nginx訪問 是否返回值和自己的理想的數據返回是否一致 或者狀態碼是否一致請求返回錯誤
必須添加對諸如 500/502/504 等 5xx 服務類錯誤狀態碼的監控，它們告訴我們服務本身出現了問題。
5xx 類錯誤每分鐘出現的頻率應該在個位數，太多的 5xx 應及時排查問題並解決；4xx 類錯誤，在協助解決一些非預期的權限錯誤、資源丟失或性能等問題上可以給予幫助。
例如：| connection refused 用戶請求超時 | 用戶請求超時 |
|---|---|
| connection timed out | nginx與後端服務器連接超時 |
| while connection upstream | nginx與後端服務器連接出現問題 |
流量
可以適當的監控網絡接口的流量
服務損耗
location /nginx-status {
stub_status on;
access_log off;
allow 10.1.1.1/24；
deny all;
}
文件打開數：lsof |grep nginx|wc -l
cpu損耗： 監控cpu的使用率即可| active connection | 當前正在處理的活躍連接數 |
|---|---|
| reading | 正在讀取的客戶連接數 |
| writing | 處理響應數據到客戶端的數量 |
| waiting | Nginx等待下次請求的駐留的客戶連接數 |
第1列：
當前與http建立的連接數，包括等待的客戶端連接： 20
第2列：
接受的客戶端連接總數目：20
處理的客戶端連接總數目：20
客戶端總的請求數目：50
第3列：
當前，nginx讀請求連接
當前，nginx寫響應返回給客戶端
目前有多少空閑客戶端請求連接nginx監控之 監控我所需要的