1. 壓測場景下的數(shù)據(jù)寫入一個被忽視的性能瓶頸最近在復(fù)盤一個線上壓測項目時又遇到了一個典型的“壓測后遺癥”——JMeter的測試結(jié)果數(shù)據(jù)無法正常寫入InfluxDB。這已經(jīng)不是第一次了每次排查都發(fā)現(xiàn)問題根源往往不是工具本身而是使用者的配置姿勢。壓測工具和監(jiān)控數(shù)據(jù)庫的組合本意是為了讓我們更清晰地看到系統(tǒng)在高并發(fā)下的表現(xiàn)但如果配置不當(dāng)它們本身就會成為新的性能瓶頸甚至導(dǎo)致壓測結(jié)果失真。這次的問題表面上是JMeter的Backend Listener連接InfluxDB超時但深挖下去是一連串關(guān)于網(wǎng)絡(luò)、配置、資源以及工具理解的連鎖反應(yīng)。如果你也正在或計劃使用JMeterInfluxDBGrafana這套經(jīng)典的性能監(jiān)控組合那么這篇文章里踩過的坑和總結(jié)的經(jīng)驗或許能幫你省下不少排查時間。這套組合的優(yōu)勢很明顯JMeter負(fù)責(zé)產(chǎn)生壓力InfluxDB作為時序數(shù)據(jù)庫高效存儲壓測產(chǎn)生的海量時間點數(shù)據(jù)如響應(yīng)時間、TPS、錯誤率Grafana則負(fù)責(zé)將數(shù)據(jù)以炫酷的圖表形式實時展示出來。然而從“能用”到“穩(wěn)定、高效地用”中間隔著許多細(xì)節(jié)。一個常見的誤解是只要把JMeter的Backend Listener指向InfluxDB的地址數(shù)據(jù)就能順暢寫入。實際上在高并發(fā)壓測場景下JMeter本身、網(wǎng)絡(luò)鏈路、InfluxDB的配置、甚至操作系統(tǒng)的資源限制任何一個環(huán)節(jié)都可能成為堵塞的“水管”導(dǎo)致數(shù)據(jù)寫入延遲、丟失最終讓你在Grafana上看到斷斷續(xù)續(xù)甚至平坦的曲線完全無法反映真實的壓測情況。2. 問題全景從現(xiàn)象到根源的深度拆解2.1 典型錯誤現(xiàn)象與初步判斷當(dāng)JMeter向InfluxDB寫入數(shù)據(jù)出現(xiàn)問題時在監(jiān)控端和壓測端通常會表現(xiàn)出一些共通的癥狀。在Grafana儀表盤上最直觀的感受就是圖表“卡住了”或者“跳崖式”下降。具體來說你可能會看到代表TPS每秒事務(wù)數(shù)或活躍線程數(shù)的曲線在某個時間點之后突然變得平直或者響應(yīng)時間曲線出現(xiàn)異常的尖峰后歸于平靜但這并非因為被測系統(tǒng)性能變好而是數(shù)據(jù)停止上報了。同時在JMeter的運行日志jmeter.log中會頻繁出現(xiàn)如“java.net.ConnectException: Connection timed out”、“java.net.SocketException: Broken pipe”或“org.apache.http.conn.HttpHostConnectException: Connect to :8086 [/] failed: Connection refused”等網(wǎng)絡(luò)連接相關(guān)的錯誤。在JMeter的圖形界面運行壓測時你可能會發(fā)現(xiàn)“后端監(jiān)聽器”組件持續(xù)顯示為黃色警告狀態(tài)。這些現(xiàn)象首先指向的是網(wǎng)絡(luò)連通性或服務(wù)可用性問題。但經(jīng)過初步排查往往發(fā)現(xiàn)InfluxDB服務(wù)進(jìn)程是正常運行的端口也是開放的。這時問題就進(jìn)入了更深的層次不是“不能連”而是“連上了卻處理不過來”。這通常意味著JMeter產(chǎn)生的數(shù)據(jù)流量超過了InfluxDB服務(wù)實例或所在機(jī)器的處理能力或者網(wǎng)絡(luò)鏈路存在瓶頸。一個關(guān)鍵的觀察點是InfluxDB自身的監(jiān)控指標(biāo)例如通過其自帶的_internal數(shù)據(jù)庫查看寫入速率writePointsPerSecond和HTTP請求處理延遲。如果寫入速率遠(yuǎn)低于JMeter產(chǎn)生的數(shù)據(jù)發(fā)送速率或者HTTP請求的POST /write端點延遲極高那么問題的根源很可能就在InfluxDB的配置和資源上。2.2 錯誤配置姿勢的常見“重災(zāi)區(qū)”根據(jù)多次實戰(zhàn)排查以下幾個配置環(huán)節(jié)最容易引發(fā)寫入問題可以稱之為“重災(zāi)區(qū)”JMeter Backend Listener的“批處理”與“隊列”配置缺失默認(rèn)情況下JMeter的Backend Listener是每產(chǎn)生一個采樣結(jié)果sample就立即向InfluxDB發(fā)送一個HTTP請求。這在低并發(fā)下沒問題但在高并發(fā)壓測時每秒可能產(chǎn)生成千上萬個采樣點這意味著每秒要向InfluxDB發(fā)起數(shù)萬次HTTP請求。這種“單點高頻寫入”模式會迅速壓垮InfluxDB的HTTP服務(wù)端并產(chǎn)生大量不必要的網(wǎng)絡(luò)開銷。正確的姿勢是啟用異步隊列和批處理。然而很多使用者并未調(diào)整queueSize內(nèi)存隊列大小和metricsBatchSize批量提交大小這兩個關(guān)鍵參數(shù)。InfluxDB的HTTP API配置未優(yōu)化InfluxDB默認(rèn)的HTTP寫入口通常是8086端口有其并發(fā)處理限制。默認(rèn)配置可能沒有針對高吞吐寫入進(jìn)行優(yōu)化。例如max-concurrent-writes最大并發(fā)寫入數(shù)、max-enqueued-writes最大排隊寫入數(shù)以及max-body-size最大請求體大小等參數(shù)如果設(shè)置得過低就會在服務(wù)端形成瓶頸。當(dāng)寫入請求超過max-enqueued-writes時新的請求會被直接拒絕返回“429 Too Many Requests”錯誤。網(wǎng)絡(luò)與系統(tǒng)資源瓶頸這常常被忽略。即使JMeter和InfluxDB配置正確如果它們部署在同一臺性能不足的機(jī)器上或者通過網(wǎng)絡(luò)帶寬有限的鏈路通信也會出現(xiàn)問題。例如JMeter在壓測時本身會消耗大量CPU和內(nèi)存如果同時它還在拼命地向本地InfluxDB寫數(shù)據(jù)兩者會競爭資源導(dǎo)致整體性能驟降。另外操作系統(tǒng)的文件描述符限制、網(wǎng)絡(luò)端口范圍限制也可能導(dǎo)致JMeter在建立大量HTTP連接時失敗。數(shù)據(jù)序列化與格式錯誤JMeter發(fā)送給InfluxDB的數(shù)據(jù)需要遵循Line Protocol格式。如果測試腳本中包含了非常復(fù)雜的標(biāo)簽tags或字段fields比如一個標(biāo)簽的值是長達(dá)數(shù)KB的JSON字符串這會導(dǎo)致單個數(shù)據(jù)點的體積暴增。不僅增加了網(wǎng)絡(luò)傳輸負(fù)擔(dān)也加重了InfluxDB解析和存儲的壓力。不合理的measurement命名、tag設(shè)計也可能影響InfluxDB的索引效率。3. 核心環(huán)節(jié)JMeter與InfluxDB的優(yōu)化配置實操3.1 JMeter Backend Listener的正確配置姿勢JMeter的InfluxDBBackendListenerClient是實現(xiàn)數(shù)據(jù)寫入的核心組件。其默認(rèn)配置是為通用性設(shè)計的對于高壓場景必須進(jìn)行調(diào)優(yōu)。下面是一個經(jīng)過實戰(zhàn)檢驗的推薦配置和參數(shù)詳解啟用異步隊列與批處理這是最重要的優(yōu)化。在Backend Listener的配置界面找到“metricsBatchSize”參數(shù)。不要使用默認(rèn)的1。建議設(shè)置為1000到5000之間。這意味著JMeter會先在內(nèi)存中累積最多這么多條采樣數(shù)據(jù)然后一次性打包成一個HTTP請求發(fā)送給InfluxDB。這能將HTTP請求頻率降低幾個數(shù)量級。參數(shù)解析metricsBatchSize1000。設(shè)置太小如100批處理效果不明顯設(shè)置太大如10000則可能導(dǎo)致數(shù)據(jù)寫入延遲過高且在JMeter突然停止時容易丟失內(nèi)存中尚未發(fā)送的批次數(shù)據(jù)。2000是一個比較均衡的起點。合理設(shè)置內(nèi)存隊列大小找到“queueSize”參數(shù)。這個參數(shù)定義了用于存放待發(fā)送采樣數(shù)據(jù)的內(nèi)存隊列容量。當(dāng)壓測線程產(chǎn)生的數(shù)據(jù)速度暫時超過網(wǎng)絡(luò)發(fā)送速度時隊列起到緩沖作用。參數(shù)解析queueSize5000。如果隊列滿了新的采樣數(shù)據(jù)將被丟棄導(dǎo)致數(shù)據(jù)丟失。因此這個值需要設(shè)置得足夠大以應(yīng)對瞬時的流量峰值。通?？梢栽O(shè)置為metricsBatchSize的2-5倍。監(jiān)控JMeter日志如果出現(xiàn)“Queue is full, dropping sample”的警告就需要調(diào)大此值。調(diào)整連接超時與讀取超時在“URL”或“參數(shù)”中我們可以通過添加請求參數(shù)來配置HTTP客戶端的超時時間。默認(rèn)的超時時間可能太短在InfluxDB壓力大響應(yīng)慢時容易導(dǎo)致連接斷開。配置示例你的InfluxDB寫入URL可以配置為http://your-influxdb-host:8086/write?dbjmeteruusernameppasswordconnectTimeout5000socketTimeout30000參數(shù)解析connectTimeout5000表示建立TCP連接的超時時間為5秒。socketTimeout30000表示從連接建立成功到收到響應(yīng)數(shù)據(jù)的超時時間為30秒。在高負(fù)載下InfluxDB處理一個大批量寫入請求可能需要數(shù)秒因此需要適當(dāng)調(diào)高socketTimeout。注意修改metricsBatchSize和queueSize會增加JMeter自身的內(nèi)存消耗。你需要確保運行JMeter的機(jī)器有足夠的堆內(nèi)存通過jmeter.bat或jmeter.sh中的HEAP參數(shù)設(shè)置例如-Xms4g -Xmx8g否則可能引發(fā)JMeter的OOM內(nèi)存溢出錯誤。3.2 InfluxDB服務(wù)端的關(guān)鍵調(diào)優(yōu)光優(yōu)化JMeter還不夠InfluxDB服務(wù)端也必須做好迎接海量數(shù)據(jù)寫入的準(zhǔn)備。調(diào)優(yōu)主要圍繞配置文件通常為/etc/influxdb/influxdb.conf中的[http]和[data]部分。優(yōu)化HTTP服務(wù)參數(shù)max-concurrent-writes 0這個參數(shù)默認(rèn)是0表示不限制。但在某些版本或配置下可能是一個較小的值。確保它被設(shè)置為一個較大的數(shù)值或0以允許高并發(fā)寫入連接。max-enqueued-writes 0同樣確保它不是一個小數(shù)值。這個隊列是在HTTP請求被處理前的內(nèi)存隊列如果設(shè)置過小請求會被快速拒絕。max-body-size 25000000約25MB當(dāng)JMeter使用較大的metricsBatchSize時單個POST請求的body可能會很大。確保這個值足夠大能夠容納你的批量數(shù)據(jù)避免出現(xiàn)“413 Request Entity Too Large”錯誤。優(yōu)化數(shù)據(jù)寫入與索引調(diào)整WALWrite-Ahead Logging配置WAL是InfluxDB保證數(shù)據(jù)持久化的機(jī)制。在[data]部分可以調(diào)整wal-fsync-delay。默認(rèn)是0s意味著每次寫入都要同步刷盤保證強(qiáng)一致性但性能低。對于壓測這種可以容忍極少量數(shù)據(jù)丟失如JMeter崩潰前最后一批未落盤數(shù)據(jù)的場景可以適當(dāng)增大此值例如設(shè)置為10ms或100ms能顯著提升寫入吞吐。[data] wal-fsync-delay 100msSeries索引限制InfluxDB中measurement tag set 的組合定義了一個series。過多的seriesseries cardinality過高會嚴(yán)重影響性能。確保你的JMeter腳本沒有生成海量唯一的tag值例如將每毫秒的時間戳或每個線程ID作為tag。Tag應(yīng)該是低基數(shù)low-cardinality的如transaction_name,status而像response_time這種值應(yīng)該作為field。系統(tǒng)與部署層面分離部署強(qiáng)烈建議將JMeter壓測機(jī)、InfluxDB數(shù)據(jù)庫、Grafana展示端部署在不同的服務(wù)器上。至少確保InfluxDB獨占一臺機(jī)器。避免資源競爭。使用SSD磁盤InfluxDB的WAL和數(shù)據(jù)文件都是磁盤IO密集型操作。使用SSD可以極大提升寫入性能。監(jiān)控InfluxDB自身啟用InfluxDB的_internal數(shù)據(jù)庫監(jiān)控定期查看其關(guān)鍵指標(biāo)如writePointsPerSecond、httpReqDurationNs寫入請求耗時、system相關(guān)的CPU/內(nèi)存使用率。這能幫助你提前發(fā)現(xiàn)瓶頸。4. 從零搭建與驗證一個可復(fù)現(xiàn)的穩(wěn)定壓測監(jiān)控環(huán)境4.1 環(huán)境準(zhǔn)備與組件安裝為了確保大家能復(fù)現(xiàn)一個穩(wěn)定的環(huán)境我們從最干凈的步驟開始。假設(shè)我們使用三臺Linux服務(wù)器或虛擬機(jī)jmeter-server,influxdb-server,grafana-server。在 influxdb-server 上安裝InfluxDB (以Ubuntu為例)# 1. 導(dǎo)入InfluxData倉庫密鑰 wget -q https://repos.influxdata.com/influxdata-archive.key sudo gpg --yes --batch --import influxdata-archive.key echo deb [signed-by/usr/share/keyrings/influxdata-archive-keyring.gpg] https://repos.influxdata.com/debian stable main | sudo tee /etc/apt/sources.list.d/influxdata.list # 2. 更新并安裝 sudo apt-get update sudo apt-get install influxdb2 # 3. 啟動并啟用服務(wù) sudo systemctl start influxdb sudo systemctl enable influxdb # 4. 初始化設(shè)置InfluxDB 2.x版本 # 訪問 http://influxdb-server:8086 完成Web UI的初始設(shè)置創(chuàng)建組織(org)、桶(bucket)并生成一個All-Access Token。 # 對于自動化腳本也可以使用命令行初始化。對于喜歡使用1.x版本的用戶可以安裝influxdb包而非influxdb2其配置方式略有不同核心的[http]和[data]配置節(jié)是類似的。在 grafana-server 上安裝Grafana# 1. 安裝依賴并添加Grafana倉庫 sudo apt-get install -y software-properties-common wget wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - echo deb https://packages.grafana.com/oss/deb stable main | sudo tee /etc/apt/sources.list.d/grafana.list # 2. 更新并安裝 sudo apt-get update sudo apt-get install grafana # 3. 啟動并啟用服務(wù) sudo systemctl start grafana-server sudo systemctl enable grafana-server安裝后訪問http://grafana-server:3000默認(rèn)用戶名密碼為admin/admin。首次登錄后會要求修改密碼。在 jmeter-server 上安裝JMeter# 1. 安裝Java (JMeter依賴) sudo apt-get install -y openjdk-11-jre-headless # 2. 下載并解壓JMeter wget https://dlcdn.apache.org//jmeter/binaries/apache-jmeter-5.6.2.tgz tar -xzf apache-jmeter-5.6.2.tgz cd apache-jmeter-5.6.2/bin # 3. 安裝InfluxDB后端監(jiān)聽器插件如果默認(rèn)沒有 # JMeter 5.0 通常已內(nèi)置。如果沒有可從JMeter插件管理器中安裝。4.2 JMeter測試計劃與Backend Listener配置實戰(zhàn)創(chuàng)建測試計劃打開JMeter GUI./jmeter新建一個測試計劃。添加一個Thread Group設(shè)置線程數(shù)如100、Ramp-up時間如60秒、循環(huán)次數(shù)永遠(yuǎn)。在線程組下添加一個HTTP Request采樣器指向一個簡單的測試接口例如http://httpbin.org/get。添加并配置Backend Listener右鍵點擊Thread Group-Add-Listener-Backend Listener。在Backend Listener implementation下拉框中選擇InfluxDBBackendListenerClient。關(guān)鍵參數(shù)配置influxdbMetricsSender選擇org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender。influxdbUrl填寫你的InfluxDB寫入地址。對于InfluxDB 2.x格式為http://influxdb-server:8086/api/v2/write?orgYOUR_ORGbucketYOUR_BUCKETprecisionms。注意這里需要你的org組織名稱和bucket桶名稱相當(dāng)于1.x的數(shù)據(jù)庫。application自定義一個應(yīng)用名如MyPressureTest這會在InfluxDB中作為application標(biāo)簽。measurement保持默認(rèn)jmeter即可或自定義。優(yōu)化參數(shù)metricsBatchSize:2000queueSize:10000在influxdbUrl末尾添加超時參數(shù)connectTimeout5000socketTimeout60000添加認(rèn)證TokenInfluxDB 2.x必需點擊下方的Add按鈕添加一個參數(shù)。Name:AuthorizationValue:Token YOUR_ALL_ACCESS_TOKEN注意Token和你的token字符串之間有一個空格添加必要的監(jiān)聽器用于調(diào)試在調(diào)試階段建議在測試計劃中添加一個View Results Tree和一個Summary Report監(jiān)聽器用于實時查看請求響應(yīng)和聚合報告但這僅用于調(diào)試正式壓測時應(yīng)禁用這些圖形化監(jiān)聽器以減少資源消耗。4.3 Grafana數(shù)據(jù)源與儀表盤配置添加InfluxDB數(shù)據(jù)源登錄Grafana點擊左側(cè)齒輪圖標(biāo) -Data Sources-Add data source。選擇InfluxDB。對于InfluxDB 2.xURL:http://influxdb-server:8086Auth: 勾選Basic auth并填寫InfluxDB 2.x的用戶名可為空和上面生成的All-Access Token作為密碼?；蛘咴贑ustom HTTP Headers中添加Authorization: Token YOUR_TOKEN。InfluxDB Details: 填寫Organization,Token(同上),Default Bucket。點擊Save Test應(yīng)顯示“Data source is working”成功信息。導(dǎo)入JMeter儀表盤模板最快捷的方式是使用社區(qū)模板。在Grafana首頁點擊Dashboards-New-Import。在Import via grafana.com框中輸入模板ID5496這是一個非常流行的JMeter性能測試儀表盤模板。加載后選擇剛創(chuàng)建的InfluxDB數(shù)據(jù)源點擊Import。導(dǎo)入后儀表盤會自動展示來自InfluxDB中JMeter寫入的數(shù)據(jù)。你可以根據(jù)application標(biāo)簽篩選你的測試應(yīng)用。5. 壓測執(zhí)行與全鏈路監(jiān)控驗證配置完成后真正的考驗在于執(zhí)行壓測并觀察全鏈路是否穩(wěn)定。切勿在GUI模式下進(jìn)行高并發(fā)壓測應(yīng)使用命令行CLI模式。在jmeter-server上使用以下命令執(zhí)行測試計劃./jmeter -n -t /path/to/your/test-plan.jmx -l /path/to/result.jtl -e -o /path/to/html-report參數(shù)說明-n非GUI模式-t指定測試腳本-l指定結(jié)果文件JTL格式-e測試結(jié)束后生成HTML報告-o指定HTML報告輸出目錄。在壓測執(zhí)行期間你需要同時監(jiān)控以下幾個關(guān)鍵點形成一個完整的監(jiān)控閉環(huán)JMeter服務(wù)器資源通過top或htop命令觀察JMeter進(jìn)程的CPU和內(nèi)存使用率。如果CPU持續(xù)高于90%或內(nèi)存使用不斷增長可能需要優(yōu)化JMeter腳本如減少不必要的監(jiān)聽器、增加HEAP內(nèi)存或者考慮使用JMeter分布式壓測。實操心得運行JMeter的機(jī)器最好有足夠的內(nèi)存如16GB并將JMeter堆內(nèi)存設(shè)置為物理內(nèi)存的50%-70%例如-Xms8g -Xmx12g?？梢酝ㄟ^修改jmeter腳本在jmeter/bin/目錄下開頭的HEAP變量來實現(xiàn)。網(wǎng)絡(luò)帶寬使用iftop或nethogs工具監(jiān)控從JMeter服務(wù)器到InfluxDB服務(wù)器的網(wǎng)絡(luò)流量。確保網(wǎng)絡(luò)帶寬不是瓶頸。一個簡單的估算假設(shè)每秒產(chǎn)生10萬條采樣數(shù)據(jù)每條數(shù)據(jù)約0.5KB那么寫入帶寬需求約為 100,000 * 0.5KB / 1024 ≈ 49 MB/s。如果網(wǎng)絡(luò)是千兆約125 MB/s理論值那么是足夠的但如果是百兆網(wǎng)絡(luò)約12.5 MB/s就會成為瓶頸。InfluxDB服務(wù)器資源與指標(biāo)系統(tǒng)資源監(jiān)控InfluxDB服務(wù)器的CPU、內(nèi)存、磁盤IO尤其是await和%util。磁盤IO是常見瓶頸。InfluxDB內(nèi)部指標(biāo)訪問InfluxDB自帶的_internal監(jiān)控。你可以寫一個簡單的查詢來監(jiān)控寫入狀態(tài)# InfluxDB 1.x 語法示例在Grafana中查詢 SELECT mean(writePointsPerSecond) FROM _internal..httpd WHERE time now() - 5m GROUP BY time(10s) SELECT mean(writeReqDurationNs) / 1000000 FROM _internal..httpd WHERE time now() - 5m GROUP BY time(10s) # 將納秒轉(zhuǎn)換為毫秒觀察writePointsPerSecond是否與你預(yù)期的JMeter發(fā)送速率匹配writeReqDurationNs寫入請求耗時是否穩(wěn)定在較低水平如100ms。如果耗時持續(xù)很高說明InfluxDB處理不過來。Grafana儀表盤觀察導(dǎo)入的JMeter儀表盤。關(guān)注以下幾個核心圖表Active Threads Over Time活躍線程數(shù)曲線應(yīng)與你的壓測場景設(shè)計相符如階梯上升后保持平穩(wěn)。Transactions Per Second (TPS)TPS曲線應(yīng)相對平穩(wěn)沒有劇烈的鋸齒狀波動或長時間為零的斷層。Response Times Over Time響應(yīng)時間曲線。如果出現(xiàn)伴隨寫入問題的系統(tǒng)瓶頸這里可能會先出現(xiàn)響應(yīng)時間飆升然后由于數(shù)據(jù)寫入失敗曲線可能變得異常平滑或斷開。Errors Per Second錯誤率。除了被測系統(tǒng)的錯誤如果JMeter到InfluxDB的寫入失敗達(dá)到一定比例也可能在這里有所體現(xiàn)取決于Backend Listener的實現(xiàn)。6. 典型問題排查清單與實戰(zhàn)解決記錄即使按照最佳實踐配置在實際壓測中仍可能遇到各種問題。下面是一個根據(jù)真實案例整理的排查清單你可以像查字典一樣按順序排查?，F(xiàn)象可能原因排查步驟與解決方案Grafana圖表無數(shù)據(jù)或數(shù)據(jù)斷斷續(xù)續(xù)1. JMeter未成功寫入數(shù)據(jù)。2. Grafana數(shù)據(jù)源配置錯誤。3. InfluxDB服務(wù)異常。1.檢查JMeter日志查看jmeter.log搜索ERROR和WARN重點關(guān)注與InfluxDB、HttpClient、connect相關(guān)的錯誤。2.檢查InfluxDB寫入直接在InfluxDB服務(wù)器上使用curl命令模擬JMeter寫入檢查HTTP返回碼。例如curl -i -XPOST http://localhost:8086/write?dbjmeter --data-binary cpu,hostserver01 value0.64。應(yīng)返回204 No Content。3.檢查Grafana數(shù)據(jù)源在Grafana數(shù)據(jù)源配置頁面點擊Save Test確認(rèn)連接成功。檢查查詢語句中的Measurement、Tag篩選條件是否正確。JMeter日志出現(xiàn)“Connection timed out”1. 網(wǎng)絡(luò)不通或防火墻攔截。2. InfluxDB服務(wù)未啟動或崩潰。3. InfluxDB的max-concurrent-writes或max-enqueued-writes隊列已滿拒絕新連接。1.網(wǎng)絡(luò)連通性從JMeter服務(wù)器telnet influxdb-server 8086或使用nc -zv influxdb-server 8086測試端口。2.檢查InfluxDB服務(wù)systemctl status influxdb。查看InfluxDB日志通常位于/var/log/influxdb/。3.檢查InfluxDB配置確認(rèn)influxdb.conf中[http]下的max-concurrent-writes和max-enqueued-writes值是否足夠大或為0。重啟InfluxDB服務(wù)使配置生效。JMeter日志出現(xiàn)“Broken pipe”或“SocketException”1. JMeter發(fā)送數(shù)據(jù)過快InfluxDB端主動關(guān)閉了連接。2. InfluxDB處理請求超時。3. 操作系統(tǒng)文件描述符限制。1.優(yōu)化JMeter批處理增大metricsBatchSize如到5000降低請求頻率。2.優(yōu)化InfluxDB檢查磁盤IO是否飽和使用iostat -x 1考慮使用SSD。適當(dāng)增加wal-fsync-delay。3.檢查系統(tǒng)限制在JMeter服務(wù)器上檢查文件描述符限制ulimit -n。如果值較小如1024在高并發(fā)下可能不夠用?？梢耘R時提高ulimit -n 65535或永久修改/etc/security/limits.conf。InfluxDB服務(wù)器CPU/磁盤IO持續(xù)100%1. 寫入負(fù)載過高單機(jī)實例達(dá)到性能極限。2. Series基數(shù)Series Cardinality爆炸式增長。1.垂直/水平擴(kuò)展為InfluxDB服務(wù)器升級硬件更多CPU核心、更快SSD。或者考慮使用InfluxDB集群版Enterprise或使用其他支持水平擴(kuò)展的時序數(shù)據(jù)庫方案。2.審查數(shù)據(jù)模型檢查JMeter寫入的數(shù)據(jù)是否使用了高基數(shù)的Tag如threadName,timeStamp。Tag值應(yīng)具有有限的、可枚舉的范圍。將動態(tài)值如響應(yīng)時間、響應(yīng)體大小作為Field而非Tag?？梢栽贗nfluxDB中使用命令SHOW SERIES CARDINALITY來查看series數(shù)量如果數(shù)量級達(dá)到百萬甚至千萬就需要重構(gòu)數(shù)據(jù)模型。Grafana圖表顯示的數(shù)據(jù)明顯低于預(yù)期TPS1. JMeter的Backend Listener隊列滿丟棄了部分采樣數(shù)據(jù)。2. 批處理延遲導(dǎo)致數(shù)據(jù)未及時寫入。1.檢查JMeter日志搜索“Queue is full, dropping sample”警告。如果存在需要增大Backend Listener的queueSize參數(shù)并確保JMeter堆內(nèi)存足夠。2.理解監(jiān)控延遲由于設(shè)置了metricsBatchSize數(shù)據(jù)是批量寫入的因此Grafana上看到的數(shù)據(jù)會有幾秒到十幾秒的延遲。這是正?，F(xiàn)象屬于吞吐量和實時性的權(quán)衡?？梢酝ㄟ^減小metricsBatchSize來降低延遲但會增加InfluxDB負(fù)擔(dān)。寫入錯誤“413 Request Entity Too Large”JMeter單個批量寫入請求的Body大小超過了InfluxDB配置的max-body-size限制。調(diào)整InfluxDB配置在influxdb.conf的[http]部分增大max-body-size參數(shù)值例如設(shè)置為5000000050MB。然后重啟InfluxDB服務(wù)。同時也可以考慮適當(dāng)減小JMeter的metricsBatchSize從源頭控制單個請求的大小。一次真實的排查記錄在一次模擬萬人并發(fā)的壓測中Grafana圖表在壓測開始10分鐘后突然變得平滑。檢查JMeter日志發(fā)現(xiàn)大量“SocketTimeoutException: Read timed out”。首先排除了網(wǎng)絡(luò)問題。登錄InfluxDB服務(wù)器iostat顯示磁盤%util持續(xù)在100%await高達(dá)數(shù)百毫秒。這說明磁盤IO是瓶頸。該服務(wù)器使用的是機(jī)械硬盤。臨時解決方案是將InfluxDB的wal-fsync-delay從0s調(diào)整為500ms犧牲一點數(shù)據(jù)安全性極端情況下可能丟失500ms內(nèi)未刷盤的數(shù)據(jù)來換取寫入性能。調(diào)整后磁盤IO壓力下降寫入超時錯誤消失。長期解決方案則是將數(shù)據(jù)庫遷移至SSD存儲的服務(wù)器上。這個案例說明監(jiān)控不能只看應(yīng)用層系統(tǒng)底層資源往往是隱藏的殺手。