統一觀測丨如何使用Prometheus 實現效能壓測指標可觀測

語言: CN / TW / HK

作者:可觀測團隊

什麼是效能壓測可觀測

如果說2022年最熱的運維話題,非可觀測莫屬。可觀測性從傳統監控場景不斷延伸,逐漸覆蓋 Metrics、Traces、Logs 三個維度並將之相互融合,可觀測性幫助企業在複雜的分散式系統中更加快速的排查、定位問題,是分散式系統中必不可少的運維工具。

在效能壓測領域中,可觀測性更為重要,除了有助於定位效能問題,其中 Metrics 效能指標更直接決定了壓測是否通過,系統最終是否可以上線,具體如下:

  • Metrics - 監控指標

    • 系統性能指標,包括請求成功率、系統吞吐量、響應時長
    • 資源效能指標,衡量系統軟硬體資源使用情況,配合系統性能指標,觀察系統資源水位
  • Logs - 日誌

    • 施壓引擎日誌,觀察施壓引擎是否健康,壓測指令碼執行是否有報錯
    • 取樣日誌,取樣記錄API的請求和響應詳情,輔助排查壓測過程中的一些出錯請求的引數是否正常,並通過響應詳情,檢視完整的錯誤資訊
  • Traces - 分散式鏈路追蹤

用於效能問題診斷階段,通過追蹤請求在系統中的呼叫鏈路,定位報錯 API 的報錯系統和報錯堆疊,快速定位效能問題點。

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

壓測監控核心指標

壓測過程中,對系統硬體、中介軟體、資料庫資源的監控也很重要,包括系統性能指標、資源指標、中介軟體指標、資料庫指標、前端指標、穩定性指標、批量處理指標、可擴充套件性指標、可靠性指標等。

系統性能指標

  1. 交易響應時間

    1. 定義及解釋響應時間指使用者從客戶端發起一個請求開始,到客戶端接收到從伺服器端返回的響應結束,整個過程所耗費的時間。在效能檢測中一般以壓力發起端至被壓測伺服器返回處理結果的時間為計量,單位一般為秒或毫秒。平均響應時間指系統穩定執行時間段內,同一交易的平均響應時間。一般而言,交易響應時間均指平均響應時間。平均響應時間指標值應根據不同的交易分別設定,一般情況下,分為複雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中,特殊交易響應時間的設定必須明確該交易在響應時間方面的特殊性
    2. 簡稱 Response Time: RT
    3. 參考標準不同行業不同業務可接受的響應時間是不同的,一般情況,對於線上實時交易:對於批量交易:
    • 網際網路企業:500 毫秒以下,例如淘寶業務 10 毫秒左右
    • 金融企業:1 秒以下為佳,部分複雜業務 3 秒以下
    • 保險企業:3 秒以下為佳
    • 製造業:5 秒以下為佳
    • 時間視窗:即整個壓測過程的時間,不同資料量則時間不一樣,例如雙 11 和 99 大促,資料量級不一樣則時間視窗不同。大資料量的情況下,2 小時內可完成壓測
  2. 系統處理能力

    1. 定義及解釋系統處理能力是指系統在利用系統硬體平臺和軟體平臺進行資訊處理的能力。系統處理能力通過系統每秒鐘能夠處理的交易數量來評價,交易有兩種理解:一是業務人員角度的一筆業務過程;二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程,後者稱為事務。兩種交易指標都可以評價應用系統的處理能力。一般的建議與系統交易日誌保持一致,以便於統計業務量或者交易量。系統處理能力指標是技術測試活動中重要指標
    2. 簡稱一般情況下,用以下指標來度量:
    • HPS(Hits Per Second) :每秒點選次數,單位是次/秒
    • TPS(Transaction per Second):系統每秒處理交易數,單位是筆/秒。
    • QPS(Query per Second):系統每秒處理查詢次數,單位是次/秒。對於網際網路業務中,如果某些業務有且僅有一個請求連線,那麼 TPS=QPS=HPS,一般情況下用 TPS 來衡量整個業務流程,用 QPS 來衡量介面查詢次數,用 HPS 來表示對伺服器單擊請求
    1. 標準無論 TPS、QPS、HPS,此指標是衡量系統處理能力非常重要的指標,越大越好,根據經驗,一般情況下:
    • 金融行業:1000 TPS~50000 TPS,不包括網際網路化的活動
    • 保險行業:100 TPS~100000 TPS,不包括網際網路化的活動
    • 製造行業:10 TPS~5000 TPS
    • 網際網路電子商務:10000 TPS~1000000 TPS
    • 網際網路中型網站:1000 TPS~50000 TPS
    • 網際網路小型網站:500 TPS~10000 TPS
  3. 併發使用者

    1. 定義及解釋併發使用者數指在同一時刻內,登入系統並進行業務操作的使用者數量。併發使用者數對於長連線系統來說最大併發使用者數即是系統的併發接入能力。對於短連線系統而言最大併發使用者數並不等於系統的併發接入能力,而是與系統架構、系統處理能力等各種情況相關。例如系統吞吐能力很強,加上短連線一般都有連線複用,往往併發使用者數大於系統的併發接入連線數。所以對於大部分短連線型別的系統,吞吐量模式(RPS模式,Request Per Second)比較適合,也是阿里的最佳實踐,PTS 支援 RPS 模式的壓測,吞吐量的壓測構建和衡量一步到位。在測試中,採用虛擬使用者來模擬現實中使用者進行業務操作
    2. 簡稱 Virtual User:VU
    3. 標準一般情況下,效能測試是將系統處理能力容量測出來,而不是測試併發使用者數,除了伺服器長連線可能影響併發使用者數外,系統處理能力不受併發使用者數影響,可以用最小的使用者數將系統處理能力容量測試出來,也可以用更多的使用者將系統處理能力容量測試出來
  4. 錯誤率

    1. 定義及解釋錯誤率指系統在負載情況下,失敗交易的概率。錯誤率=(失敗交易數/交易總數)×100%。穩定性較好的系統,其錯誤率應該由超時引起,即為超時率。
    2. 簡稱 Virtual Failure Ratio:FR: VU
    3. 標準不同系統對錯誤率的要求不同,但一般不超出千分之六,即成功率不低於 99.4%

資源指標

  1. CPU

    1. 定義及解釋中央處理器是一塊超大規模的積體電路,是一臺計算機的運算核心(Core)和控制核心( Control Unit)。它的功能主要是解釋計算機指令以及處理計算機軟體中的資料。CPU Load:系統正在幹活的多少的度量,佇列長度。系統平均負載
    2. 簡稱 Central Processing Unit:CPU
    3. 標準 CPU 指標主要指的 CPU 使用率、利用率,包括使用者態(user)、系統態(sys)、等待態(wait)、空閒態(idle)。CPU使用率、利用率要低於業界警戒值範圍之內,即小於或者等於 75%、CPU sys%小於或者等於 30%,CPU wait% 小於或者等於 5%。單核 CPU 也需遵循上述指標要求。CPU Load 要小於CPU核數
  2. Memory

    1. 定義及解釋記憶體是計算機中重要的部件之一,它是與 CPU 進行溝通的橋樑。計算機中所有程式的執行都是在記憶體中進行的,因此記憶體的效能對計算機的影響非常大
    2. 簡稱 Memory 就是記憶體的簡稱
    3. 標準現代的作業系統為了最大利用記憶體,在記憶體中存放了快取,因此記憶體利用率 100% 並不代表記憶體有瓶頸,衡量系統內有瓶頸主要靠 SWAP(與虛擬記憶體交換)交換空間利用率,一般情況下,SWAP 交換空間利用率要低於 70%,太多的交換將會引起系統性能低下
  3. 磁碟吞吐量

    1. 定義及解釋磁碟吞吐量是指在無磁碟故障的情況下單位時間內通過磁碟的資料量
    2. 簡稱 Disk Throughput
    3. 標準磁碟指標主要有每秒讀寫多少兆,磁碟繁忙率,磁碟佇列數,平均服務時間,平均等待時間,空間利用率。其中磁碟繁忙率是直接反映磁碟是否有瓶頸的重要依據,一般情況下,磁碟繁忙率要低於 70%
  4. 網路吞吐量

    1. 定義及解釋網路吞吐量是指在無網路故障的情況下單位時間內通過的網路的資料數量。單位為 Byte/s。網路吞吐量指標用於衡量系統對於網路裝置或鏈路傳輸能力的需求。當網路吞吐量指標接近網路裝置或鏈路最大傳輸能力時,則需要考慮升級網路裝置
    2. 簡稱 Network Throughput
    3. 標準網路吞吐量指標主要有每秒有多少兆流量進出,一般情況下不能超過裝置或鏈路最大傳輸能力的 70%

中介軟體指標

  1. 定義及解釋常用的中介軟體例如 Tomcat、Weblogic 等指標主要包括 JVM、ThreadPool、JDBC,具體如下:

1.png

  1. 標準

    • 當前正在執行的執行緒數不能超過設定的最大值。一般情況下系統性能較好的情況下,執行緒數最小值設定 50 和最大值設定 200 比較合適
    • 當前執行的 JDBC 連線數不能超過設定的最大值。一般情況下系統性能較好的情況下,JDBC 最小值設定 50 和最大值設定 200 比較合適
    • GC 頻率不能頻繁,特別是 FULL GC 更不能頻繁,一般情況下系統性能較好的情況下,JVM 最小堆大小和最大堆大小分別設定 1024 M 比較合適

資料庫指標

  1. 定義及解釋常用的資料庫例如 MySQL 指標主要包括 SQL、吞吐量、快取命中率、連線數等,具體如下:

2.png

標準

    • SQL 耗時越小越好,一般情況下微秒級別
    • 命中率越高越好,一般情況下不能低於 95%
    • 鎖等待次數越低越好,等待時間越短越好

前端指標

  1. 定義及解釋前端指標主要包括頁面展示和網路所花的時間,具體如下:

3.png

  1. 標準

    • 頁面要儘可能小及壓縮
    • 頁面展示和花費時間越短越好

穩定性指標

  1. 定義及解釋最短穩定時間:系統按照最大容量的 80% 或標準壓力(系統的預期日常壓力)情況下執行,能夠穩定執行的最短時間。一般來說,對於正常工作日(8小時)執行的系統,至少應該能保證系統穩定執行8小時以上。對於 7×24 執行的系統,至少應該能夠保證系統穩定執行 24 小時以上。如果系統不能穩定的執行,上線後,隨著業務量的增長和長時間執行,將會出現效能下降甚至崩潰的風險
  2. 標準

    • TPS 曲線穩定,沒有大幅度的波動
    • 各項資源指標沒有洩露或異常情況

批量處理指標

  1. 定義及解釋指批量處理程式單位時間內處理的資料數量。一般用每秒處理的資料量來衡量。處理效率是估算批量處理時間視窗最重要的計算指標。關於批量處理時間視窗,不同系統的批量處理時間視窗在起止時間上可以部分重疊。另外,同一系統內部,也可能存在多個批量處理過程同時進行,其時間視窗相互疊加。長時間批量處理將會對聯機線上實時交易產生重大的效能影響
  2. 標準

    • 在資料量很大的情況下,批處理時間視窗時間越短越好
    • 不能影響實時交易系統性能

可擴充套件性指標

  1. 定義及解釋指應用軟體或作業系統以叢集方式部署,增加的硬體資源與增加的處理能力之間的關係。計算公式為:(增加效能/原始效能)/(增加資源/原始資源)×100%。擴充套件能力應通過多輪測試獲得擴充套件指標的變化趨勢。一般擴充套件能力非常好的應用系統,擴充套件指標應是線性或接近線性的,現在很多大規模的分散式系統的擴充套件能力非常好。
  2. 標準

    • 理想的擴充套件能力是資源增加幾倍,效能就提升幾倍。
    • 擴充套件能力至少在70%以上。

可靠性指標

  1. 雙機熱備對於將雙機熱備作為可靠性保障手段的系統,可衡量的指標如下:

    • 節點切換是否成功及其消耗時間。
    • 雙機切換是否有業務中斷。
    • 節點回切是否成功及其耗時
    • 雙機回切是否有業務中斷。
    • 節點回切過程中的資料丟失量。在進行雙機切換的同時,使用壓力發生工具模擬實際業務發生情況,對應用保持一定的效能壓力,保證測試結果符合生產實際情況。
  2. 叢集對於使用叢集方式的系統,主要通過以下方式考量其叢集可靠性:

    • 叢集中某個節點出現故障時,系統是否有業務中斷情況出現。
    • 在叢集中新增一個節點時,是否需要重啟系統。
    • 當故障節點恢復後,加入叢集,是否需要重啟系統。
    • 當故障節點恢復後,加入叢集,系統是否有業務中斷情況出現。
    • 節點切換需要多長時間。在驗證叢集可靠性的同時,需根據具體情況使用壓力工具模擬實際業務發生相關情況,對應用保持一定的效能壓力,確保測試結果符合生產實際情況。
  3. 備份和恢復本指標為了驗證系統的備份、恢復機制是否有效可靠,包括系統的備份和恢復、資料庫的備份和恢復、應用的備份和恢復,包括以下測試內容:

    • 備份是否成功及其消耗時間。
    • 備份是否使用指令碼自動化完成。
    • 恢復是否成功及其消耗時間。
    • 恢復是否使用指令碼自動化完成指標體系的運用原則。
    • 指標項的採用和考察取決於對相應系統的測試目的和測試需求。被測系統不一樣,測試目的不一樣,測試需求也不一樣,考察的指標項也有很大差別。
    • 部分系統涉及額外的前端使用者接入能力的,需要考察使用者接入併發能力指標。
    • 對於批量處理過程的效能驗證,主要考慮批量處理效率並估算批量處理時間視窗。
    • 如測試目標涉及到系統性能容量,測試需求中應根據相關指標項的定義,明確描述效能指標需求。
    • 測試指標獲取後,需說明相關的前提條件(如在多少的業務量、系統資源情況等)。

施壓機效能指標

壓測鏈路中,施壓機效能是容易被忽略的一環,為了保證施壓機不是整個壓測鏈路的效能瓶頸,需要關注如下施壓機效能指標:

  • 壓測程序的記憶體使用量
  • 施壓機 CPU 使用率,Load1、Load5 負載指標
  • 基於 JVM 的壓測引擎,需要關注垃圾回收次數、垃圾回收時長

為什麼用 Prometheus 做壓測監控

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

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

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

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

方案一:Zabbix

Zabbix 是早期開源的分散式監控系統,支援 MySQL 或 PostgreSQL 關係型資料庫作為資料來源。

對於系統性能監控,需要施壓機提供秒級的監控指標,每秒高併發的監控指標寫入,使關係型資料庫成為了監控系統的瓶頸。

對於資源效能監控,Zabbix 對物理機、虛擬機器的指標很全面,但是對容器、彈性計算的監控支援還不夠。

方案二:Prometheus

Prometheus 使用時序資料庫作為資料來源,相比傳統關係型資料庫,讀寫效能大大提高,對於施壓機大量的秒級監控資料上報的場景,效能表現良好。

對於資源效能監控,Prometheus 更適用於雲資源的監控,尤其對 Kubernates 和容器的監控非常全面,對使用雲原生技術的使用者,上手更簡單。

總結下來,Prometheus 相較 Zabbix,更適合於壓測中高併發監控指標的採集和聚合,並且更適用於雲資源的監控,且易於擴充套件。PTS 提供壓測時的系統性能指標, Prometheus 提供資源監控和整體可觀測的能力,一站式解決壓測可觀測的問題。

怎麼使用 Prometheus 實現壓測監控

開源 JMeter 改造

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

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

4.png

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

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

PTS 壓測工具& Prometheus 監控

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

由於效能測試 PTS 已經與阿里雲 Prometheus 監控進行了雲產品自監控整合,因此咱們可以直接在阿里雲 Prometheus 監控中進行整合開通。 在已整合區域,單擊雲產品卡片,您可以在彈出的面板中檢視該雲產品的指標、大盤及告警的監控資料。

  • 指標:您可以在指標頁籤檢視效能測試 PTS 的監控指標資訊,其中包括您所建立的 PTS 壓測任務以及 PTS 施壓機的自監控。
  • 大盤:您可以在大盤頁籤檢視當前雲產品的預置大盤。
  • 告警:您可以在告警頁籤建立 Prometheus 告警規則,檢視監控告警資訊。如何建立告警規則的具體操作,請參見 Prometheus 告警規則。

總結

本文闡述了:

  1. 什麼是效能測試可觀測
  2. 為什麼用 Prometheus 做壓測效能指標監控
  3. 如何使用開源 JMeter 和雲上 PTS 實現基於 Prometheus 的壓測監控

PTS 壓測監控匯出 Prometheus 功能,歡迎使用。同時,PTS 全新售賣方式來襲,基礎版價格直降50%!百萬併發價格只需 6200!更有新使用者 0.99 體驗版、VPC 壓測專屬版,歡迎大家選購!

點選此處進入可觀測大促專場