雲原生時代如何用 Prometheus 實現效能壓測可觀測-Metrics 篇

ALIYUN_PTS發表於2022-04-07

原文網址 : http://blog.itpub.net/69953029/viewspace-2885666/

Prometheus

什麼是效能壓測可觀測

可觀測性包括 Metrics、Traces、Logs3 個維度。可觀測能力幫助我們在複雜的分散式系統中快速排查、定位問題，是分散式系統中必不可少的運維工具。

在效能壓測領域中，可觀測能力更為重要，除了有助於定位效能問題，其中 Metrics 效能指標更直接決定了壓測是否透過，對系統上線有決定性左右，具體如下：

Metrics，監控指標
- 系統效能指標，包括請求成功率、系統吞吐量、響應時長
- 資源效能指標，衡量系統軟硬體資源使用情況，配合系統效能指標，觀察系統資源水位
Logs，日誌
- 施壓引擎日誌，觀察施壓引擎是否健康，壓測指令碼執行是否有報錯
- 取樣日誌，取樣記錄 API 的請求和響應詳情，輔助排查壓測過程中的一些出錯請求的引數是否正常，並透過響應詳情，檢視完整的錯誤資訊
Traces，分散式鏈路追蹤用於效能問題診斷階段，透過追蹤請求在系統中的呼叫鏈路，定位報錯 API 的報錯系統和報錯堆疊，快速定位效能問題點

本篇闡述如何使用 Prometheus 實現效能壓測 Metrics 的可觀測性。

壓測監控核心指標

系統效能指標

壓測監控最重要的 3 個指標：請求成功率、服務吞吐量 (TPS)、請求響應時長 (RT)，這 3 個指標任意一個出現拐點，都可以認為系統已達到效能瓶頸。

這裡特別說明下響應時長，對於這個指標，用平均值來判斷很有誤導性，因為一個系統的響應時長並不是平均分佈的，往往會出現長尾現象，表現為一部分使用者請求的響應時間特別長，但整體平均響應時間符合預期，這樣其實是影響了一部分使用者的體驗，不應該判斷為測試透過。因此對於響應時長，常用 99、95、90 分位值來判斷系統響應時長是否達標。

另外，如果需要觀察請求響應時長的分佈細節，可以補充請求建聯時長 (Connect Time)、等待響應時長 (Idle Time) 等指標。

資源效能指標

壓測過程中，對系統硬體、中介軟體、資料庫資源的監控也很重要，包括但不限於：

CPU 使用率
記憶體使用率
磁碟吞吐量
網路吞吐量
資料庫連線數
快取命中率

... ...
詳細可見《測試指標》一文。

施壓機效能指標

壓測鏈路中，施壓機效能是容易被忽略的一環，為了保證施壓機不是整個壓測鏈路的效能瓶頸，需要關注如下施壓機效能指標：
壓測程序的記憶體使用量
施壓機 CPU 使用率，Load1、Load5 負載指標
基於 JVM 的壓測引擎，需要關注垃圾回收次數、垃圾回收時長

為什麼用 Prometheus 做壓測監控

開源壓測工具如 JMeter 本身支援簡單的系統效能監控指標，如：請求成功率、系統吞吐量、響應時長等。但是對於大規模分散式壓測來說，開源壓測工具的原生監控有如下不足：

監控指標不夠全面，一般只包含了基礎的系統效能指標，只能用於判斷壓測是否透過。但是如果壓測不透過，需要排查、定位問題時，如分析一個 API 的 99 分位建聯時長，原生監控指標就無法實現。
聚合時效性不能保證
無法支援大規模分散式的監控資料聚合
監控指標不支援按時間軸回溯

綜上，在大規模分散式壓測中，不推薦使用開源壓測工具的原生監控。

下面對比 2 種開源的監控方案：

方案一：Zabbix

Zabbix 是早期開源的分散式監控系統，支援 MySQL 或 PostgreSQL 關係型資料庫作為資料來源。
對於系統效能監控，需要施壓機提供秒級的監控指標，每秒高併發的監控指標寫入，使關係型資料庫成為了監控系統的瓶頸。
對於資源效能監控，Zabbix 對物理機、虛擬機器的指標很全面，但是對容器、彈性計算的監控支援還不夠。

方案二：Prometheus

Prometheus 使用時序資料庫作為資料來源，相比傳統關係型資料庫，讀寫效能大大提高，對於施壓機大量的秒級監控資料上報的場景，效能表現良好。
對於資源效能監控，Prometheus 更適用於雲資源的監控，尤其對 Kubernates 和容器的監控非常全面，對使用雲原生技術的使用者，上手更簡單。

總結下來，Prometheus 相較 Zabbix，更適合於壓測中高併發監控指標的採集和聚合，並且更適用於雲資源的監控，且易於擴充套件。
當然，使用成熟的雲產品也是一個很好選擇，如壓測工具PTS+ 可觀測工具ARMS，就是一組黃金搭檔。PTS 提供壓測時的系統效能指標，ARMS 提供資源監控和整體可觀測的能力，一站式解決壓測可觀測的問題。

怎麼使用 Prometheus 實現壓測監控

開源 JMeter 改造

Prometheus 是拉資料模型，因此需要壓測引擎暴露 HTTP 服務，供 Prometheus 獲取各壓測指標。

JMeter 提供了外掛機制，可以自定義外掛來擴充套件 Prometheus 監控能力。在自定外掛中，需要擴充套件 JMeter 的 BackendListener，讓在取樣器執行完成時，更新每個壓測指標，如成功請求數、失敗請求數、請求響應時長。並將各壓測指標在記憶體中儲存，在 Prometheus 拉資料時，透過 HTTP 服務暴露出去。整體結構如下：

JMeter 自定義外掛需要改造的點：

增加指標註冊中心
擴充套件 Prometheus 指標更新器
實現自定義 JMeter BackendListener，在取樣器執行結束後，呼叫 Prometheus 更新器
實現 HTTP Server，如果有安全需要，補充鑑權邏輯

PTS 壓測工具

效能測試 PTS（Performance Testing Service）是一款阿里雲 SaaS 化的效能測試工具。PTS 支援自研壓測引擎，同時支援開源 JMeter 壓測，在 PTS 上開放壓測指標到 Prometheus，無需開發自定義外掛來改造引擎，只需 3 步白屏化操作即可。

具體步驟如下：

PTS 壓測的高階設定中，開啟【Prometheus】開關
壓測開始後，在【監控匯出】一鍵複製 Prometheus 配置
自建的 Prometheus 中貼上並熱載入此配置，即可生效

快速搭建 Grafana 監控大盤

PTS 提供了官方 Grafana 大盤模板，支援一鍵匯入監控大盤，並可以靈活編輯和擴充套件，滿足您的定製監控需求。

本大盤提供了全域性請求成功率，系統吞吐量 (TPS)，99、95、90 分位響應時長，以及按錯誤狀態碼聚合的錯誤請求數等資料。
在 API 分佈專欄中，可以直觀的對比各 API 的監控指標，快速定位效能短板 API。
在 API 詳情專欄中，可以檢視單個 API 的詳細指標，準確定位效能瓶頸。
另外，大盤還提供了施壓機的 JVM 垃圾回收監控指標，可以輔助判斷施壓機是否是壓測鏈路中的效能瓶頸。

匯入步驟如下：