同實踐)
最先要考慮的問題其實是多條件閾值判斷這塊邏輯到底應該寫在 InfluxDB 內部還是寫在你自己的 Java 服務里。這個選擇做不好后面會遇到兩類問題一類是告警判斷被寫死在業(yè)務代碼里時間窗口一改就要發(fā)版另一類是過度依賴 InfluxDB 原生告警組合條件稍微復雜一點就寫不出查詢。我最近在一個模擬項目 X 里重構告警鏈路核心需求是Java 服務持續(xù)把性能指標寫入 InfluxDB然后對 CPU、內存、磁盤、接口錯誤率這些指標做多條件閾值判斷超限后觸發(fā)告警并把告警狀態(tài)反饋到業(yè)務側處理。整個方案跑完我最大的體會是——Check 告警不是一個“開關”而是“數(shù)據(jù)庫負責統(tǒng)計、Java 負責組合判定、Webhook 負責推送”這樣一條流水線。這篇文章就把完整鏈路拆開講清楚。1. 告警判斷放在哪業(yè)務層輪詢和 InfluxDB 原生 Check 不是二選一先說背景。大多數(shù) Java 團隊接 InfluxDB起步寫法都是這樣定時任務每隔固定時間去查一次指標把平均值、最大值取出來然后在 Java 里做if (cpu 90) alert()。這種寫法在指標少、團隊小的時候完全沒問題但一旦到了幾十臺機器、十幾個監(jiān)控指標問題就開始集中爆發(fā)。1.1 應用層輪詢?yōu)槭裁磿綄懺街貞脤虞喸冏畲蟮膯栴}不是性能而是職責錯位。你寫了一個定時任務每 30 秒跑一次查詢查完之后自己算閾值、自己發(fā)告警、自己記錄狀態(tài)。聽起來很靈活但實際維護時會遇到三個麻煩時間窗口的語義很難統(tǒng)一。接口錯誤率要看 5 分鐘窗口CPU 要看 1 分鐘窗口磁盤要看 10 分鐘窗口Java 里每個任務都要單獨維護窗口邏輯。告警狀態(tài)只能自己緩存。Java 進程一重啟上次是 warn 還是 crit 就丟了很容易出現(xiàn)重復告警或者漏告警。聚合邏輯寫在代碼里無法復用。InfluxDB 本身擅長做降采樣、窗口聚合你在 Java 里用 List 自己算均值、百分位純屬浪費數(shù)據(jù)庫能力。我見過最夸張的一個項目告警定時任務里同時維護了 20 多個 CronTask每個任務里有自己的 Redis key 存狀態(tài)光是狀態(tài)清理的 bug 就夠排查半天。所以從某個階段開始團隊會自然地往 InfluxDB 原生 Check 去靠。1.2 InfluxDB 原生 Check 的能力邊界InfluxDB 2.x 里的 Check 可以理解為數(shù)據(jù)庫內部的一個周期任務它會按照你設定的every間隔反復執(zhí)行一段查詢然后根據(jù)查詢結果輸出一條帶_level字段的記錄。_level的取值通常是ok、warn、crit、unknown這個字段是后面一切告警推送的判定依據(jù)。原生 Check 的優(yōu)點很明顯狀態(tài)保存在數(shù)據(jù)庫內部查詢窗口精準告警歷史在_monitoringbucket 里留痕。但它也有邊界——如果只是給單個字段配一個簡單閾值在 UI 上點幾下就完成一旦要說“CPU 超過 85 且內存超過 80 才算 crit”或者“三個指標里任意兩個超限才告警”UI 上的 threshold 配置就不夠用了。這時候要么用自定義 Check自定義 Flux 查詢要么把組合判斷拉回 Java。我最終選擇的是兩條路都走下面會展開說明。1.3 我的最終鏈路設計綜合下來我采用的場景劃分是單指標、單閾值、重復性強的告警交給 InfluxDB 原生 Check。多指標、組合條件、需要業(yè)務動作的告警由 Java 查詢數(shù)據(jù)后自行判斷。Check 輸出的_level狀態(tài)統(tǒng)一落到_monitoringbucketJava 定時讀取作為兜底。推送統(tǒng)一走 WebhookJava 接到 Check 通知后轉成業(yè)務側的消息格式。Java 業(yè)務服務 —寫入指標— InfluxDB InfluxDB —原生Check— Webhook — 告警接收服務 Java 業(yè)務服務 —Flux查詢— InfluxDB —組合判定— 業(yè)務動作這個結構的核心是InfluxDB 永遠只負責時序數(shù)據(jù)的存儲與聚合真正決定“要不要發(fā)告警”的組合判斷邏輯上由 Java 做一層收斂。這樣既能利用數(shù)據(jù)庫的高效窗口計算又能把復雜判斷保持在高靈活性的一方。2. 多條件 Check 的 Flux 表達聚合窗口內組合字段級閾值如果確定某個告警場景要在 InfluxDB 內部完成那就必須寫對自定義 Check 的查詢。多條件 Check 的難點不在查詢語句本身而在如何把多個字段對齊到同一個時間片內做比較。2.1 多條件組合的三種常見模式按我遇到過的需求多條件閾值判斷基本能歸成三類組合模式含義實際例子AND 組合兩個條件同時滿足才告警CPU 85% 并且內存 80%OR 組合任一條件滿足就告警錯誤率 5% 或 P99 延遲 300msN-of-M 組合M 個指標中至少 N 個超限CPU、內存、磁盤中任意兩個超限這三種模式在 SQL 里寫很容易但 InfluxDB 的數(shù)據(jù)模型是“字段分散在不同行”的。比如一個 measurement 里同時有cpu_usage、mem_usage、disk_usage三個 field在查詢結果里它們是不同的行記錄沒法直接在filter里同時比較。所以需要先做一次 Pivot把字段從列變成對應的行內列。2.2 用 Flux 的 pivot 和 map 把多字段映射成 _level以一條典型的多條件 Check 為例每分鐘計算一次 CPU 和內存的平均值如果兩個都超限則輸出crit如果只有一個超限輸出warn。Flux 查詢是這樣寫的from(bucket: prod-data) | range(start: -2m) | filter(fn: (r) r._measurement perf) | filter(fn: (r) r._field cpu_usage or r._field mem_usage or r._field disk_usage) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _level: if r.cpu_usage 85.0 and r.mem_usage 80.0 then crit else if r.cpu_usage 85.0 or r.mem_usage 80.0 then warn else ok, _value: r.cpu_usage }))這里有兩個關鍵細節(jié)。第一個是pivot。它把cpu_usage、mem_usage、disk_usage從三行數(shù)據(jù)變成同一行里的三個列這樣在map函數(shù)里才能用r.cpu_usage這種方式直接訪問字段值。不 pivot 的話每個 field 單獨成行沒法做跨字段的 AND 判斷。第二個是輸出_level字段。InfluxDB 的自定義 Check 正是通過每行結果里的_level來判斷狀態(tài)的。查詢里必須顯式構造這個字段并且建議同時輸出_value否則 UI 里展示告警詳情時會缺少數(shù)值信息。不同 InfluxDB 版本對自定義 Check 的字段要求會有細節(jié)差異比如部分版本要求在map里保留_time和_measurement。建議在測試環(huán)境先用同一條查詢手工執(zhí)行確認輸出行里包含_level后再把它存成 Check。2.3 Check 的執(zhí)行節(jié)奏與內部狀態(tài)輸出創(chuàng)建 Check 時除了查詢腳本還要配置every和offset。every是執(zhí)行間隔offset是偏移作用是把執(zhí)行時間往后挪避免剛寫入的數(shù)據(jù)還來不及聚合就被查到。Check 每次執(zhí)行后會產(chǎn)生一條狀態(tài)記錄落在_monitoringbucket 里。這條記錄自帶_check_name、_check_id、_level這些標簽也就成了 Java 側做兜底查詢的數(shù)據(jù)源。后面會在第 3 節(jié)演示如何讀取。3. Java 與 Check 的雙通道聯(lián)通寫入數(shù)據(jù)、回讀告警狀態(tài)、觸發(fā)業(yè)務動作這一節(jié)就是標題里“Java 結合”真正落地的地方。我用三個環(huán)節(jié)來講怎么把指標寫進去、怎么查 Check 狀態(tài)、怎么接收 Check 推送。3.1 Java 客戶端依賴與連接管理官方 Java 客戶端的坐標是com.influxdb:influxdb-client-java。我在項目里用的是 6.x 版本Maven 依賴如下dependency groupIdcom.influxdb/groupId artifactIdinfluxdb-client-java/artifactId version6.11.0/version /dependency連接方式也很直接InfluxDBClient client InfluxDBClientFactory.create( http://127.0.0.1:8086, my-token-xxx.toCharArray(), my-org, prod-data);有一點容易忽略InfluxDBClientFactory.create里最后兩個參數(shù)分別是 org 和默認 bucket。之后用WriteApi和QueryApi時如果不顯式指定就會用默認值。多個服務共用同一個 client 實例沒問題它是線程安全的但同時要記得在應用關閉時調用client.close()。3.2 寫入監(jiān)控指標Point 建模寫入端用Point構造就行。我習慣把同一時刻采集到的多個指標放在同一個 Point 里這樣在 Flux 中做 pivot 跨字段判斷時天然就在同一時間片內WriteApi writeApi client.getWriteApi(); Point point Point.measurement(perf) .addTag(host, app-node-01) .addField(cpu_usage, 87.4) .addField(mem_usage, 82.1) .addField(disk_usage, 72.3) .time(Instant.now(), WritePrecision.MS); writeApi.writePoint(prod-data, my-org, point);寫入頻率按窗口大小決定即可。如果告警窗口是 1 分鐘寫入頻率建議不低于 15 秒采集一次否則窗口內的 mean 值平滑效果不好容易出現(xiàn)毛刺。3.3 回讀 Check 狀態(tài)從 _monitoring 里撈告警即使原生 Check 已經(jīng)把告警推送出來了我也會在 Java 側做一個兜底讀取邏輯是定期查詢_monitoringbucket 中最近一次非 ok 的狀態(tài)from(bucket: _monitoring) | range(start: -5m) | filter(fn: (r) r._measurement statuses) | filter(fn: (r) r._check_name cpu-memory-and-threshold) | filter(fn: (r) r._level ! ok) | last()Java 端讀取時QueryApi queryApi client.getQueryApi(); String flux from(bucket: \_monitoring\) | range(start: -5m) | filter(fn: (r) r._measurement \statuses\) | filter(fn: (r) r._check_name \cpu-memory-and-threshold\) | filter(fn: (r) r._level ! \ok\) | last(); ListFluxTable tables queryApi.query(flux); for (FluxTable table : tables) { for (FluxRecord record : table.getRecords()) { String level (String) record.getValueByName(_level); String checkName (String) record.getValueByName(_check_name); // 執(zhí)行你的業(yè)務動作 } }這個做法的價值在于原生 Check 的執(zhí)行是在 InfluxDB 內部不受 Java 服務狀態(tài)影響。哪怕 Java 側定時任務掛了一段時間重啟后依然能從_monitoring里把最近的告警狀態(tài)補回來不會丟狀態(tài)。3.4 Webhook 通道讓 Check 自己找上門比輪詢更及時的方式是讓 Check 推送告警。InfluxDB 的通知規(guī)則Notification Rule會把 Check 的狀態(tài)變化發(fā)到通知端點Notification Endpoint。端點類型支持 HTTP 請求也就是 Webhook。Java 側只需要提供一個接收端點這里以 Spring Boot 接口為例PostMapping(/influx/alert) public ResponseEntityVoid receiveAlert(RequestBody MapString, Object payload) { MapString, String tags (MapString, String) payload.get(tags); String checkName tags.get(checkName); String level tags.get(level); alertProcessor.process(checkName, level, payload); return ResponseEntity.ok().build(); }要提醒的是Webhook 推送是冪等性最弱的一環(huán)網(wǎng)絡抖動時可能出現(xiàn)重復推送。所以接收端我會在處理器里做去重按checkName 時間戳 level作為 Redis 去重鍵。4. 兩個高價值實戰(zhàn)場景交易接口質量告警與主機資源多條件告警理論講完還是要落到具體場景。我在這套架構上做了兩個最有代表性的案例一個偏業(yè)務指標一個偏基礎設施指標。兩者的差異正好說明了多條件判斷的兩種寫法。4.1 場景一交易接口錯誤率與延遲組合判斷這類告警想要表達的是“接口開始惡化”而不是“偶發(fā)抖動”。單個指標超閾值很容易誤報比如某一次慢請求拖高了 P99但錯誤率很低業(yè)務其實沒有受損。我用的判斷規(guī)則是最近 5 分鐘平均錯誤率 3%并且最近 5 分鐘 P99 延遲 250ms兩個條件同時滿足才觸發(fā) crit。Flux 還是走 pivot 思路from(bucket: api-metrics) | range(start: -6m) | filter(fn: (r) r._measurement apiQuality) | filter(fn: (r) r._field errorRate or r._field p99Latency) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _level: if r.errorRate 3.0 and r.p99Latency 250.0 then crit else if r.errorRate 2.0 or r.p99Latency 200.0 then warn else ok, _value: r.errorRate }))窗口取 5 分鐘aggregateWindow里每隔 1 分鐘打一個點這樣查詢結果最近 5 個點左右。InfluxDB 的 Check 執(zhí)行時會對這些點逐行判斷只要任意一個點滿足 crit狀態(tài)就會變成 crit。這個場景里我踩過一個坑如果p99Latency這樣的字段在某些分鐘內沒有數(shù)據(jù)pivot 之后會出現(xiàn)r.p99Latency nullFlux 里 null 跟數(shù)值比較永遠返回 false。結果就是明明錯誤率超標了但只產(chǎn)出 warn。解決辦法是在 map 之前加一層fill(column: p99Latency, value: 0.0)或者把 map 里的判斷寫成exists r.p99Latency這樣的空值保護。4.2 場景二基礎設施資源 N-of-M 告警另一個常見需求是主機資源告警規(guī)則不是“單指標超限就告警”而是“以下三個指標中任意兩個達到閾值再告警”。這是因為單指標偶爾峰值很常見兩個資源同時打滿通常是更明確的狀態(tài)異常。我在 Java 端用組合判斷更直觀。先寫一條 Flux 查詢把最近一分鐘的主機資源數(shù)據(jù)按小時聚合拿到from(bucket: prod-data) | range(start: -2m) | filter(fn: (r) r._measurement perf) | filter(fn: (r) r._field cpu_usage or r._field mem_usage or r._field disk_usage) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value)Java 側逐行判斷int thresholdCount 0; boolean cpuHigh record.getValueByName(cpu_usage) ! null ((Number) record.getValueByName(cpu_usage)).doubleValue() 90.0; boolean memHigh record.getValueByName(mem_usage) ! null ((Number) record.getValueByName(mem_usage)).doubleValue() 90.0; boolean diskHigh record.getValueByName(disk_usage) ! null ((Number) record.getValueByName(disk_usage)).doubleValue() 95.0; if (cpuHigh) thresholdCount; if (memHigh) thresholdCount; if (diskHigh) thresholdCount; if (thresholdCount 2) { alertService.sendResourceAlert(host, cpuHigh, memHigh, diskHigh); }這段代碼看起來簡單但有一個容易被忽略的前提cpu_usage、mem_usage這些字段必須來自同一個 Point 寫入時間或者經(jīng) aggregateWindow 對齊到同一窗口。如果業(yè)務側寫入時把三個字段分成了三個 Point 交給 InfluxDBpivot 之后可能因為時間戳不同而分成多行組合判斷就會失效。實際操作建議像主機資源這類采集項采集端盡量一次構造一個 Point 寫入。同一個時刻的指標必須落在一個時間戳上后續(xù)做跨字段閾值判斷才順。4.3 為什么復雜判斷建議留在 Java原生 Check 在多條件組合里確實能做但每加一個條件Flux 腳本的可讀性就下一個臺階。尤其是 N-of-M 這類邏輯在 Flux 里寫出來基本是幾個布爾變量加 if 的組合坑非常多比如字段缺失、類型轉換、時間對齊。維護一個只能靠文檔解釋的 Flux 腳本不如把它寫成 Java 里的純邏輯函數(shù)能單測、能覆蓋、能加日志。所以我的原則是閾值簡單、狀態(tài)展示也簡單的用 Check閾值復雜、觸及業(yè)務動作的用 Java。兩者共用同一份 InfluxDB 數(shù)據(jù)源避免同一套指標被查兩遍。5. 生產(chǎn)環(huán)境最容易翻車的三個告警細節(jié)空窗口、重復推送與檢查節(jié)奏最后寫幾個我在真實環(huán)境里踩過的細節(jié)問題。這些內容在官方文檔里都只提了一句但實際影響非常大。5.1 空窗口會吞掉告警條件前面提到了createEmpty這里展開講。aggregateWindow在不滿足窗口時間范圍時默認不會產(chǎn)生空窗口。如果某個窗口里由于采集端停機沒有數(shù)據(jù)那么這條告警條件的檢查就不會發(fā)生。對單指標 Check 來說可能表現(xiàn)為“該告警沒告警”對多條件 Check 來說表現(xiàn)為其中一個條件被跳過。解決辦法分兩種如果希望“指標缺失也算異常”用createEmpty: true再配合fill把 null 填成值。如果希望“缺失不算異常”就用createEmpty: false但必須在 Java 側對返回空數(shù)組的情況做單獨處理比如記錄一條“無數(shù)據(jù)”日志。5.2 Check 推送不是天然冪等InfluxDB 的通知規(guī)則在觸發(fā)時可能因為網(wǎng)絡超時、端點不可用而重復調用。更常見的是一個 Check 每次執(zhí)行都會輸出一條 status如果 Java 側只按時間來記錄同一輪告警會被重復處理。我的降噪思路是把_check_name _level作為狀態(tài)鍵只有當 level 從warn升級到crit或者從crit恢復為ok時才觸發(fā)真正的外部動作同一個 level 內反復推送只更新數(shù)據(jù)庫狀態(tài)不再發(fā)短信或企業(yè)微信群消息。這個狀態(tài)機用 Redis 或者內存 ConcurrentHashMap 都可以實現(xiàn)。5.3 檢查紀律every、offset 與寫入頻率的配合Check 的every不能設置得比聚合窗口還短否則每次執(zhí)行時窗口內數(shù)據(jù)都不完整聚合出來的值會偏低。也不要設置得過長否則告警延遲會變成用戶可感知的故障。我這里給一個參數(shù)配合經(jīng)驗表適用大多數(shù)監(jiān)控場景指標類型寫入頻率Check every查詢窗口備注主機 CPU/內存15s1m2moffset 5s確保窗口數(shù)據(jù)完整接口錯誤率10s1m5m需要更長的平滑窗口磁盤空間1m2m10m趨勢類不需要高頻檢查我見過有人在 Check every 設成 10s窗口卻還是 5m結果每個 Check 執(zhí)行都會產(chǎn)生大量重復狀態(tài)記錄最后推送服務直接被打爆。記住一個原則every是執(zhí)行頻率窗口是判斷范圍這兩者不要混在一起。最后再分享一個實際體會把多條件閾值放進 InfluxDB 還是 Java不是純粹的技術選型而要看誰離業(yè)務邏輯更近。業(yè)務側告警比如“接口響應變慢且錯誤率上升”這種狀態(tài)判斷邏輯應該交給 Java因為后面往往要跟著重啟容器、切流量這類動作。基礎設施側告警比如“三資源中兩項超標”則可以放到 InfluxDB Check 里讓數(shù)據(jù)庫自己周期檢查Java 只消費結果。兩條路同時存在并不沖突反而讓告警鏈路更穩(wěn)。 多條件閾值告警鏈路：Java與InfluxDB Check協(xié)同實踐
最先要考慮的問題其實是多條件閾值判斷這塊邏輯到底應該寫在 InfluxDB 內部還是寫在你自己的 Java 服務里。這個選擇做不好后面會遇到兩類問題一類是告警判斷被寫死在業(yè)務代碼里時間窗口一改就要發(fā)版另一類是過度依賴 InfluxDB 原生告警組合條件稍微復雜一點就寫不出查詢。我最近在一個模擬項目 X 里重構告警鏈路核心需求是Java 服務持續(xù)把性能指標寫入 InfluxDB然后對 CPU、內存、磁盤、接口錯誤率這些指標做多條件閾值判斷超限后觸發(fā)告警并把告警狀態(tài)反饋到業(yè)務側處理。整個方案跑完我最大的體會是——Check 告警不是一個“開關”而是“數(shù)據(jù)庫負責統(tǒng)計、Java 負責組合判定、Webhook 負責推送”這樣一條流水線。這篇文章就把完整鏈路拆開講清楚。1. 告警判斷放在哪業(yè)務層輪詢和 InfluxDB 原生 Check 不是二選一先說背景。大多數(shù) Java 團隊接 InfluxDB起步寫法都是這樣定時任務每隔固定時間去查一次指標把平均值、最大值取出來然后在 Java 里做if (cpu 90) alert()。這種寫法在指標少、團隊小的時候完全沒問題但一旦到了幾十臺機器、十幾個監(jiān)控指標問題就開始集中爆發(fā)。1.1 應用層輪詢?yōu)槭裁磿綄懺街貞脤虞喸冏畲蟮膯栴}不是性能而是職責錯位。你寫了一個定時任務每 30 秒跑一次查詢查完之后自己算閾值、自己發(fā)告警、自己記錄狀態(tài)。聽起來很靈活但實際維護時會遇到三個麻煩時間窗口的語義很難統(tǒng)一。接口錯誤率要看 5 分鐘窗口CPU 要看 1 分鐘窗口磁盤要看 10 分鐘窗口Java 里每個任務都要單獨維護窗口邏輯。告警狀態(tài)只能自己緩存。Java 進程一重啟上次是 warn 還是 crit 就丟了很容易出現(xiàn)重復告警或者漏告警。聚合邏輯寫在代碼里無法復用。InfluxDB 本身擅長做降采樣、窗口聚合你在 Java 里用 List 自己算均值、百分位純屬浪費數(shù)據(jù)庫能力。我見過最夸張的一個項目告警定時任務里同時維護了 20 多個 CronTask每個任務里有自己的 Redis key 存狀態(tài)光是狀態(tài)清理的 bug 就夠排查半天。所以從某個階段開始團隊會自然地往 InfluxDB 原生 Check 去靠。1.2 InfluxDB 原生 Check 的能力邊界InfluxDB 2.x 里的 Check 可以理解為數(shù)據(jù)庫內部的一個周期任務它會按照你設定的every間隔反復執(zhí)行一段查詢然后根據(jù)查詢結果輸出一條帶_level字段的記錄。_level的取值通常是ok、warn、crit、unknown這個字段是后面一切告警推送的判定依據(jù)。原生 Check 的優(yōu)點很明顯狀態(tài)保存在數(shù)據(jù)庫內部查詢窗口精準告警歷史在_monitoringbucket 里留痕。但它也有邊界——如果只是給單個字段配一個簡單閾值在 UI 上點幾下就完成一旦要說“CPU 超過 85 且內存超過 80 才算 crit”或者“三個指標里任意兩個超限才告警”UI 上的 threshold 配置就不夠用了。這時候要么用自定義 Check自定義 Flux 查詢要么把組合判斷拉回 Java。我最終選擇的是兩條路都走下面會展開說明。1.3 我的最終鏈路設計綜合下來我采用的場景劃分是單指標、單閾值、重復性強的告警交給 InfluxDB 原生 Check。多指標、組合條件、需要業(yè)務動作的告警由 Java 查詢數(shù)據(jù)后自行判斷。Check 輸出的_level狀態(tài)統(tǒng)一落到_monitoringbucketJava 定時讀取作為兜底。推送統(tǒng)一走 WebhookJava 接到 Check 通知后轉成業(yè)務側的消息格式。Java 業(yè)務服務 —寫入指標— InfluxDB InfluxDB —原生Check— Webhook — 告警接收服務 Java 業(yè)務服務 —Flux查詢— InfluxDB —組合判定— 業(yè)務動作這個結構的核心是InfluxDB 永遠只負責時序數(shù)據(jù)的存儲與聚合真正決定“要不要發(fā)告警”的組合判斷邏輯上由 Java 做一層收斂。這樣既能利用數(shù)據(jù)庫的高效窗口計算又能把復雜判斷保持在高靈活性的一方。2. 多條件 Check 的 Flux 表達聚合窗口內組合字段級閾值如果確定某個告警場景要在 InfluxDB 內部完成那就必須寫對自定義 Check 的查詢。多條件 Check 的難點不在查詢語句本身而在如何把多個字段對齊到同一個時間片內做比較。2.1 多條件組合的三種常見模式按我遇到過的需求多條件閾值判斷基本能歸成三類組合模式含義實際例子AND 組合兩個條件同時滿足才告警CPU 85% 并且內存 80%OR 組合任一條件滿足就告警錯誤率 5% 或 P99 延遲 300msN-of-M 組合M 個指標中至少 N 個超限CPU、內存、磁盤中任意兩個超限這三種模式在 SQL 里寫很容易但 InfluxDB 的數(shù)據(jù)模型是“字段分散在不同行”的。比如一個 measurement 里同時有cpu_usage、mem_usage、disk_usage三個 field在查詢結果里它們是不同的行記錄沒法直接在filter里同時比較。所以需要先做一次 Pivot把字段從列變成對應的行內列。2.2 用 Flux 的 pivot 和 map 把多字段映射成 _level以一條典型的多條件 Check 為例每分鐘計算一次 CPU 和內存的平均值如果兩個都超限則輸出crit如果只有一個超限輸出warn。Flux 查詢是這樣寫的from(bucket: prod-data) | range(start: -2m) | filter(fn: (r) r._measurement perf) | filter(fn: (r) r._field cpu_usage or r._field mem_usage or r._field disk_usage) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _level: if r.cpu_usage 85.0 and r.mem_usage 80.0 then crit else if r.cpu_usage 85.0 or r.mem_usage 80.0 then warn else ok, _value: r.cpu_usage }))這里有兩個關鍵細節(jié)。第一個是pivot。它把cpu_usage、mem_usage、disk_usage從三行數(shù)據(jù)變成同一行里的三個列這樣在map函數(shù)里才能用r.cpu_usage這種方式直接訪問字段值。不 pivot 的話每個 field 單獨成行沒法做跨字段的 AND 判斷。第二個是輸出_level字段。InfluxDB 的自定義 Check 正是通過每行結果里的_level來判斷狀態(tài)的。查詢里必須顯式構造這個字段并且建議同時輸出_value否則 UI 里展示告警詳情時會缺少數(shù)值信息。不同 InfluxDB 版本對自定義 Check 的字段要求會有細節(jié)差異比如部分版本要求在map里保留_time和_measurement。建議在測試環(huán)境先用同一條查詢手工執(zhí)行確認輸出行里包含_level后再把它存成 Check。2.3 Check 的執(zhí)行節(jié)奏與內部狀態(tài)輸出創(chuàng)建 Check 時除了查詢腳本還要配置every和offset。every是執(zhí)行間隔offset是偏移作用是把執(zhí)行時間往后挪避免剛寫入的數(shù)據(jù)還來不及聚合就被查到。Check 每次執(zhí)行后會產(chǎn)生一條狀態(tài)記錄落在_monitoringbucket 里。這條記錄自帶_check_name、_check_id、_level這些標簽也就成了 Java 側做兜底查詢的數(shù)據(jù)源。后面會在第 3 節(jié)演示如何讀取。3. Java 與 Check 的雙通道聯(lián)通寫入數(shù)據(jù)、回讀告警狀態(tài)、觸發(fā)業(yè)務動作這一節(jié)就是標題里“Java 結合”真正落地的地方。我用三個環(huán)節(jié)來講怎么把指標寫進去、怎么查 Check 狀態(tài)、怎么接收 Check 推送。3.1 Java 客戶端依賴與連接管理官方 Java 客戶端的坐標是com.influxdb:influxdb-client-java。我在項目里用的是 6.x 版本Maven 依賴如下dependency groupIdcom.influxdb/groupId artifactIdinfluxdb-client-java/artifactId version6.11.0/version /dependency連接方式也很直接InfluxDBClient client InfluxDBClientFactory.create( http://127.0.0.1:8086, my-token-xxx.toCharArray(), my-org, prod-data);有一點容易忽略InfluxDBClientFactory.create里最后兩個參數(shù)分別是 org 和默認 bucket。之后用WriteApi和QueryApi時如果不顯式指定就會用默認值。多個服務共用同一個 client 實例沒問題它是線程安全的但同時要記得在應用關閉時調用client.close()。3.2 寫入監(jiān)控指標Point 建模寫入端用Point構造就行。我習慣把同一時刻采集到的多個指標放在同一個 Point 里這樣在 Flux 中做 pivot 跨字段判斷時天然就在同一時間片內WriteApi writeApi client.getWriteApi(); Point point Point.measurement(perf) .addTag(host, app-node-01) .addField(cpu_usage, 87.4) .addField(mem_usage, 82.1) .addField(disk_usage, 72.3) .time(Instant.now(), WritePrecision.MS); writeApi.writePoint(prod-data, my-org, point);寫入頻率按窗口大小決定即可。如果告警窗口是 1 分鐘寫入頻率建議不低于 15 秒采集一次否則窗口內的 mean 值平滑效果不好容易出現(xiàn)毛刺。3.3 回讀 Check 狀態(tài)從 _monitoring 里撈告警即使原生 Check 已經(jīng)把告警推送出來了我也會在 Java 側做一個兜底讀取邏輯是定期查詢_monitoringbucket 中最近一次非 ok 的狀態(tài)from(bucket: _monitoring) | range(start: -5m) | filter(fn: (r) r._measurement statuses) | filter(fn: (r) r._check_name cpu-memory-and-threshold) | filter(fn: (r) r._level ! ok) | last()Java 端讀取時QueryApi queryApi client.getQueryApi(); String flux from(bucket: \_monitoring\) | range(start: -5m) | filter(fn: (r) r._measurement \statuses\) | filter(fn: (r) r._check_name \cpu-memory-and-threshold\) | filter(fn: (r) r._level ! \ok\) | last(); ListFluxTable tables queryApi.query(flux); for (FluxTable table : tables) { for (FluxRecord record : table.getRecords()) { String level (String) record.getValueByName(_level); String checkName (String) record.getValueByName(_check_name); // 執(zhí)行你的業(yè)務動作 } }這個做法的價值在于原生 Check 的執(zhí)行是在 InfluxDB 內部不受 Java 服務狀態(tài)影響。哪怕 Java 側定時任務掛了一段時間重啟后依然能從_monitoring里把最近的告警狀態(tài)補回來不會丟狀態(tài)。3.4 Webhook 通道讓 Check 自己找上門比輪詢更及時的方式是讓 Check 推送告警。InfluxDB 的通知規(guī)則Notification Rule會把 Check 的狀態(tài)變化發(fā)到通知端點Notification Endpoint。端點類型支持 HTTP 請求也就是 Webhook。Java 側只需要提供一個接收端點這里以 Spring Boot 接口為例PostMapping(/influx/alert) public ResponseEntityVoid receiveAlert(RequestBody MapString, Object payload) { MapString, String tags (MapString, String) payload.get(tags); String checkName tags.get(checkName); String level tags.get(level); alertProcessor.process(checkName, level, payload); return ResponseEntity.ok().build(); }要提醒的是Webhook 推送是冪等性最弱的一環(huán)網(wǎng)絡抖動時可能出現(xiàn)重復推送。所以接收端我會在處理器里做去重按checkName 時間戳 level作為 Redis 去重鍵。4. 兩個高價值實戰(zhàn)場景交易接口質量告警與主機資源多條件告警理論講完還是要落到具體場景。我在這套架構上做了兩個最有代表性的案例一個偏業(yè)務指標一個偏基礎設施指標。兩者的差異正好說明了多條件判斷的兩種寫法。4.1 場景一交易接口錯誤率與延遲組合判斷這類告警想要表達的是“接口開始惡化”而不是“偶發(fā)抖動”。單個指標超閾值很容易誤報比如某一次慢請求拖高了 P99但錯誤率很低業(yè)務其實沒有受損。我用的判斷規(guī)則是最近 5 分鐘平均錯誤率 3%并且最近 5 分鐘 P99 延遲 250ms兩個條件同時滿足才觸發(fā) crit。Flux 還是走 pivot 思路from(bucket: api-metrics) | range(start: -6m) | filter(fn: (r) r._measurement apiQuality) | filter(fn: (r) r._field errorRate or r._field p99Latency) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value) | map(fn: (r) ({ r with _level: if r.errorRate 3.0 and r.p99Latency 250.0 then crit else if r.errorRate 2.0 or r.p99Latency 200.0 then warn else ok, _value: r.errorRate }))窗口取 5 分鐘aggregateWindow里每隔 1 分鐘打一個點這樣查詢結果最近 5 個點左右。InfluxDB 的 Check 執(zhí)行時會對這些點逐行判斷只要任意一個點滿足 crit狀態(tài)就會變成 crit。這個場景里我踩過一個坑如果p99Latency這樣的字段在某些分鐘內沒有數(shù)據(jù)pivot 之后會出現(xiàn)r.p99Latency nullFlux 里 null 跟數(shù)值比較永遠返回 false。結果就是明明錯誤率超標了但只產(chǎn)出 warn。解決辦法是在 map 之前加一層fill(column: p99Latency, value: 0.0)或者把 map 里的判斷寫成exists r.p99Latency這樣的空值保護。4.2 場景二基礎設施資源 N-of-M 告警另一個常見需求是主機資源告警規(guī)則不是“單指標超限就告警”而是“以下三個指標中任意兩個達到閾值再告警”。這是因為單指標偶爾峰值很常見兩個資源同時打滿通常是更明確的狀態(tài)異常。我在 Java 端用組合判斷更直觀。先寫一條 Flux 查詢把最近一分鐘的主機資源數(shù)據(jù)按小時聚合拿到from(bucket: prod-data) | range(start: -2m) | filter(fn: (r) r._measurement perf) | filter(fn: (r) r._field cpu_usage or r._field mem_usage or r._field disk_usage) | aggregateWindow(every: 1m, fn: mean, createEmpty: false) | pivot(rowKey: [_time], columnKey: [_field], valueColumn: _value)Java 側逐行判斷int thresholdCount 0; boolean cpuHigh record.getValueByName(cpu_usage) ! null ((Number) record.getValueByName(cpu_usage)).doubleValue() 90.0; boolean memHigh record.getValueByName(mem_usage) ! null ((Number) record.getValueByName(mem_usage)).doubleValue() 90.0; boolean diskHigh record.getValueByName(disk_usage) ! null ((Number) record.getValueByName(disk_usage)).doubleValue() 95.0; if (cpuHigh) thresholdCount; if (memHigh) thresholdCount; if (diskHigh) thresholdCount; if (thresholdCount 2) { alertService.sendResourceAlert(host, cpuHigh, memHigh, diskHigh); }這段代碼看起來簡單但有一個容易被忽略的前提cpu_usage、mem_usage這些字段必須來自同一個 Point 寫入時間或者經(jīng) aggregateWindow 對齊到同一窗口。如果業(yè)務側寫入時把三個字段分成了三個 Point 交給 InfluxDBpivot 之后可能因為時間戳不同而分成多行組合判斷就會失效。實際操作建議像主機資源這類采集項采集端盡量一次構造一個 Point 寫入。同一個時刻的指標必須落在一個時間戳上后續(xù)做跨字段閾值判斷才順。4.3 為什么復雜判斷建議留在 Java原生 Check 在多條件組合里確實能做但每加一個條件Flux 腳本的可讀性就下一個臺階。尤其是 N-of-M 這類邏輯在 Flux 里寫出來基本是幾個布爾變量加 if 的組合坑非常多比如字段缺失、類型轉換、時間對齊。維護一個只能靠文檔解釋的 Flux 腳本不如把它寫成 Java 里的純邏輯函數(shù)能單測、能覆蓋、能加日志。所以我的原則是閾值簡單、狀態(tài)展示也簡單的用 Check閾值復雜、觸及業(yè)務動作的用 Java。兩者共用同一份 InfluxDB 數(shù)據(jù)源避免同一套指標被查兩遍。5. 生產(chǎn)環(huán)境最容易翻車的三個告警細節(jié)空窗口、重復推送與檢查節(jié)奏最后寫幾個我在真實環(huán)境里踩過的細節(jié)問題。這些內容在官方文檔里都只提了一句但實際影響非常大。5.1 空窗口會吞掉告警條件前面提到了createEmpty這里展開講。aggregateWindow在不滿足窗口時間范圍時默認不會產(chǎn)生空窗口。如果某個窗口里由于采集端停機沒有數(shù)據(jù)那么這條告警條件的檢查就不會發(fā)生。對單指標 Check 來說可能表現(xiàn)為“該告警沒告警”對多條件 Check 來說表現(xiàn)為其中一個條件被跳過。解決辦法分兩種如果希望“指標缺失也算異常”用createEmpty: true再配合fill把 null 填成值。如果希望“缺失不算異常”就用createEmpty: false但必須在 Java 側對返回空數(shù)組的情況做單獨處理比如記錄一條“無數(shù)據(jù)”日志。5.2 Check 推送不是天然冪等InfluxDB 的通知規(guī)則在觸發(fā)時可能因為網(wǎng)絡超時、端點不可用而重復調用。更常見的是一個 Check 每次執(zhí)行都會輸出一條 status如果 Java 側只按時間來記錄同一輪告警會被重復處理。我的降噪思路是把_check_name _level作為狀態(tài)鍵只有當 level 從warn升級到crit或者從crit恢復為ok時才觸發(fā)真正的外部動作同一個 level 內反復推送只更新數(shù)據(jù)庫狀態(tài)不再發(fā)短信或企業(yè)微信群消息。這個狀態(tài)機用 Redis 或者內存 ConcurrentHashMap 都可以實現(xiàn)。5.3 檢查紀律every、offset 與寫入頻率的配合Check 的every不能設置得比聚合窗口還短否則每次執(zhí)行時窗口內數(shù)據(jù)都不完整聚合出來的值會偏低。也不要設置得過長否則告警延遲會變成用戶可感知的故障。我這里給一個參數(shù)配合經(jīng)驗表適用大多數(shù)監(jiān)控場景指標類型寫入頻率Check every查詢窗口備注主機 CPU/內存15s1m2moffset 5s確保窗口數(shù)據(jù)完整接口錯誤率10s1m5m需要更長的平滑窗口磁盤空間1m2m10m趨勢類不需要高頻檢查我見過有人在 Check every 設成 10s窗口卻還是 5m結果每個 Check 執(zhí)行都會產(chǎn)生大量重復狀態(tài)記錄最后推送服務直接被打爆。記住一個原則every是執(zhí)行頻率窗口是判斷范圍這兩者不要混在一起。最后再分享一個實際體會把多條件閾值放進 InfluxDB 還是 Java不是純粹的技術選型而要看誰離業(yè)務邏輯更近。業(yè)務側告警比如“接口響應變慢且錯誤率上升”這種狀態(tài)判斷邏輯應該交給 Java因為后面往往要跟著重啟容器、切流量這類動作。基礎設施側告警比如“三資源中兩項超標”則可以放到 InfluxDB Check 里讓數(shù)據(jù)庫自己周期檢查Java 只消費結果。兩條路同時存在并不沖突反而讓告警鏈路更穩(wěn)。