作者：京東保險 管順利

一、傳統監控系統的盲區，如何打造業務狀態監控。

在系統架構設計中非常重要的一環是要做數據監控和數據最終一致性，關于一致性的補償，已經由算法部的大佬總結過就不再贅述。這里主要講如何去補償？補償的方案哪些？這就引出來數據監控系統了。有小伙伴會問了，為什么業務狀態監控系統可以做補償？別急，往下看。

傳統監控系統分為兩種，系統監控和業務監控。系統監控有并發量監控、異常監控、調用鏈監控、端口監控、zabbix 監控、http監控等。業務監控是指用以監控業務數據是否正常，用戶需要進行業務埋點進行數據采集。業務監控底層常規依賴日志上報系統，接入業務監控之前先申請接入日志上報系統。如圖1

（圖1）

從業務監控時序圖中看到一般分為五步：

1.數據埋點，業務端埋點后上報的日志，也可以是mysql。日志文件最后通過flume或者bin log上報。

2.數據收集，通常都通過kafka做數據采集。

3.數據清洗，一般都是在ods層用spark-streaming進行分流，清洗。

4.數據存儲，數據分流后會存儲到dw層，最后落到各種庫里面。

5.數據展示，開源的很多，用的多還是grafana，還有數據大屏等。

看到這里大家有沒有感覺到一絲困惑？有沒有感覺跟鏈路追蹤傻傻分不清楚？業務監控和鏈路追蹤的區別就成了侵入式埋點上報和無侵入式agent抓取上報。這仿佛沒了靈魂，于是我去問了下AI，AI給出的答案是“業務監控則是一種用于監測業務指標和關鍵業務流程的技術，目的在于實現對業務運營狀況的實時了解和快速響應”。

二、新型業務監控，hunter-monitor的誕生。

站在巨人的肩膀上開始俯視全局，發現真實的需求：

1.報警能力，圍繞業務，運營場景。設置各種預警的閾值。達到閾值后要及時發出響應。

2.數據計算和數據統計能力，根據埋點計算整條鏈路上，每個節點的異常數據。幫做統計和輸出。

3.觸達能力，京me，郵件，必要時電話，短信，微信都要跟上。

4.數據歸檔能力，數據歸檔是為了兜底，做最終一致性。是為了異常時做數據比對。

5.數據自理能力，在AI時代，必須要有自動消化處理的能力。

6.報警規則能力，“樹”的應用，要把整個系統鏈路串聯起來的能力。

我們是京東保險平臺研發部，承接商城的端延保訂單的流量。流量全是交易數據。交易數據是不允許丟失。因此我們孕育出自己的業務監控系統“監控獵手 （hunter-monitor）” 簡稱hm。hm已經實現了以上6種能力。在出現問題時，會第一時間通知業務和產品。還提供了異常數據統計、節點數據計算、回溯、補償等能力。業務或產研發需要時，可以在平臺上做數據對比。還具備了延展能力，如可以對接jsf接口。來實現自動補償能力。

hm業務狀態監控的核心能力是：數據串聯和數據計算。是可以把業務整條鏈路在系統中的埋點，已線性串聯起來。并展示出每個節點的異常狀態數據。最終消化掉異常數據。

三、三連問：誰適合接入？如何使用？有接入的實例么？

1、誰適合接入

接入保險SaaS工作臺的系統都可以接入業務狀態監控。沒介入的呢？只需要在保險SaaS工作臺中，創建租戶便可以使用hm業務狀態監控。

2、如何使用

2.1 監控接入

接入hm只要簡單的三步即可，創建規則，創建報警規則，業務接入埋點。創建方式和常規的業務監控系統一樣。

2.2 數據處理

異常數據最終需要處理掉。在監控列表中可以一鍵處理異常數據

2.3 定制化

我們支持觸達內容定制化，異常數據處理方式定制化，異常數據統計定制化。可以調用業務系統jsf接口完成自動處理，也可以根據需求出異常數據報告，更可以深度幫助業務方定制系統鏈路中的異常處理。hm已應用到延保交易全鏈路系統，履約平臺，業財一體平臺和保險abTest等系統。我們來看幾個延保業務的接入的場景。

3、實戰！延保業務接入場景

3.1 大屏展示：

每周都會公示出上一周延保業務出現的問題，并通過經代小助手、京me和郵件發送給業務方負責人，支持異常投保單的下載。業務收到郵件后會按照郵件中的攻略去操作，完成正確的投保。截止目前幫助業務側完成40萬+的異常投保單的重新投保。幫助業務降低了客訴率，也幫助保司拿到保費。（圖2）

（圖2）

3.2 自動補單：

延保的業務上游大多來自商城，業務會在系統里處理訂單分發到下游，由于量大，操作門檻高，總會出現異常的情況，比如漏配某個參數，導致交易失敗或者用戶不能正常履約。以前都是到客戶履約的時候或者下游交易發起結算失敗時，才能發現的問題。在hm中配置了監控后，發現異常情況會調用補單的jsf接口，觸發自動補單。以前出現問題最長要已天為單位才能解決，現在分鐘級解決問題。起到了降本增效的效果。

3.3 數據歸檔：

hm給延保上游和下游交易提供數據了永久歸檔能力，如發現各種異常類的情況，可以從hm系統里面導出數據來作數據比對。如果是金額類的還可以自動接入到對賬系統。在線上查看對賬結果，導出對賬差異數據（圖3）。同時會發送異常數據郵件，通知對應的產品和業務（圖4）。

（圖3）

（圖4）

四、HM的內核，技術架構和實現方案

如果實在是沒辦法接入，只能自研怎么辦？沒關系，我把技術方法列出來。給大家提供解決方案的思路。

1.技術架構

hm架構上化繁為簡，單刀直入。從最核心的業務數據下手，在業務應用中埋點，通過樹型節點nodeId串起整條鏈路。埋點數據統一進數倉清洗后。由調度中心定時觸發去做數據計算和數據統計，展示到前端。我們先來看一張架構圖。圖5

（圖5）

2.核心技術

2.1 規則引擎

規則引擎是指埋點的規則。規則引擎參考了Jaeger源碼，用來生成我們的規則編碼nodeId。（圖6）構建成hm的規則樹。最終緩存到工作業務臺展示（圖7）。

（圖6）

（圖7）

2.2 報警引擎

報警引擎是指配置報警的一系列的規則，數據計算的規則，觸達的方式。創建好規則后，要對每一個規則進行詳細的報警配置，包括觸發報警的類型，報警規則，操作閾值，處理方式等。（圖8）報警類型指觸達方式，繼承了保險SaaS-msg的能力，支持郵件、京me、微信、電話等觸達方式。任務系統使用Easy-Job來動態管理任務。處理方式可以對接業務方Jsf 來完成閉環，也可以設置成歸檔，以便后續的有導出或對數的需求。

（圖8）

2.3 數據埋點

在保險工作臺配置好埋點規則和報警規則后，就可以在業務方去埋點，區別于鏈路追蹤或傳統的基于Agent系統，它們都是無侵入埋點系統。hm則屬于強侵入式埋點系統，在這里我們定制了一套埋點規范，“必須啟用異步線程，進行發送MQ或者調用API接口”。埋點支持兩種方式，一種是send msg to topic，mq支持jmq2/jmq4。另一種就是通過調用API去初始化hunter-expoxt的實體類。由hm來發送消息。

2.4 數據清洗

hm的主要職責在業務數據的歸納、分揀。除了埋點接入外還支持，mq、數據庫等數據源的接入。所有的數據統一有集團的DP（DataPilot ）平臺的DataBus系統的DTS完成，統一進數倉的FDM/BDM層。再由集團的調度中心Buffalo（EMR），配置的spark任務執行數據分揀。最終數據進入doris/hive/es中存儲。

2.5 數據計算

hm只記錄異常數據，發力在異常數據的統計和計算上。在配置好規則節點和系統埋點后，hm會去計算每個節點的異常數據。根據報警規則來進行處理，或通知業務和產研，或調用業務系統的jsf接口去做異常數據的自動處理，又或者根據規則自行處理數據。

2.6 數據統計

hm每周會出數據統計報表發送給業務和產研。報表中會體現他負責的業務線下所有系統的異常數據，包括處理過的異常數據和未處理的異常數據，A業務線和B業務線異常對比數據，業務系統與業務系統的異常對比數據等。可以根據業務需求定制報表。幫助業務和產研更好掌握系統的最新狀況。

2.7 任務中心

任務中心是指EasyJob，是和報警規則強綁定的。調度任務分為兩類，一類是業務類任務，是動態去創建的任務，按照設置的corn執行。另一類是平臺任務。用于維護業務類任務的，比如定期去刪除沒有異常的任務等。（圖9）

（圖9）

2.8 觸達展示

觸達方式支持了保險工作臺、經代小助手、郵件、京me通知、企業微信、電話語音等。根據業務方需求來選擇。

2.9 處理方式

如果觸達3次還沒有做異常的處理數據，會進行自動升級，在下次觸達時會抄給上一級。異常數據需要在hm列表頁里做數據狀態變更。

2.10 開源能力：jaeger

hm底層參考了jaeger-core，重寫了jaegerSpan和jaegerTracer類。并把jaeger-core和opentracing-api重新打包-形成自己的jar（hunter-api）

五、總結

以上是hm的全部技術細節。hm靈魂是數據計算、治理、數據統計。hm根基是集成百家之長。hm生在保險SaaS工作臺，是我們平臺研發部自研的一款面向業務的，異常監控處理的解決方案。