一、傳統(tǒng)監(jiān)控系統(tǒng)的盲區(qū)，如何打造業(yè)務狀態(tài)監(jiān)控。

在系統(tǒng)架構設計中非常重要的一環(huán)是要做數(shù)據(jù)監(jiān)控和數(shù)據(jù)最終一致性，關于一致性的補償，已經(jīng)由算法部的大佬總結過就不在贅述。這里主要講如何去補償？補償?shù)姆桨改男窟@就引出來數(shù)據(jù)監(jiān)控系統(tǒng)了。有小伙伴會問了，為什么業(yè)務狀態(tài)監(jiān)控系統(tǒng)可以做補償？別急，往下看。

傳統(tǒng)監(jiān)控系統(tǒng)分為兩種，系統(tǒng)監(jiān)控和業(yè)務監(jiān)控。系統(tǒng)監(jiān)控有并發(fā)量監(jiān)控、異常監(jiān)控、調(diào)用鏈監(jiān)控、端口監(jiān)控、zabbix 監(jiān)控、http監(jiān)控等。業(yè)務監(jiān)控是指用以監(jiān)控業(yè)務數(shù)據(jù)是否正常，用戶需要進行業(yè)務埋點進行數(shù)據(jù)采集。業(yè)務監(jiān)控底層常規(guī)依賴日志上報系統(tǒng)，接入業(yè)務監(jiān)控之前先申請接入日志上報系統(tǒng)。如圖1

（圖1）

從業(yè)務監(jiān)控時序圖中看到一般分為五步：

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

2.數(shù)據(jù)收集，通常都通過kafka做數(shù)據(jù)采集。

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

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

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

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

二、新型業(yè)務監(jiān)控，hunter-monitor的誕生。

站在巨人的肩膀上開始俯視全局，發(fā)現(xiàn)真實的需求：

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

2.數(shù)據(jù)計算和數(shù)據(jù)統(tǒng)計能力，根據(jù)埋點計算整條鏈路上，每個節(jié)點的異常數(shù)據(jù)。幫做統(tǒng)計和輸出。

3.觸達能力，內(nèi)部聊天工具，郵件，必要時電話，短信，微信都要跟上。

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

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

6.報警規(guī)則能力，“樹”的應用，要把整個系統(tǒng)鏈路串聯(lián)起來的能力。

?

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

hm業(yè)務狀態(tài)監(jiān)控的核心能力是：數(shù)據(jù)串聯(lián)和數(shù)據(jù)計算。是可以把業(yè)務整條鏈路在系統(tǒng)中的埋點，已線性串聯(lián)起來。并展示出每個節(jié)點的異常狀態(tài)數(shù)據(jù)。最終消化掉異常數(shù)據(jù)。

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

1、誰適合接入

接入保險SaaS工作臺的系統(tǒng)都可以接入業(yè)務狀態(tài)監(jiān)控。沒介入的呢？只需要在保險SaaS工作臺中，創(chuàng)建租戶便可以使用hm業(yè)務狀態(tài)監(jiān)控。

2、如何使用

2.1 監(jiān)控接入

接入hm只要簡單的三步即可，創(chuàng)建規(guī)則，創(chuàng)建報警規(guī)則，業(yè)務接入埋點。創(chuàng)建方式和常規(guī)的業(yè)務監(jiān)控系統(tǒng)一樣。

2.2 數(shù)據(jù)處理

異常數(shù)據(jù)最終需要處理掉。在監(jiān)控列表中可以一鍵處理異常數(shù)據(jù)

2.3 定制化

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

?

3、實戰(zhàn)！延保業(yè)務接入場景

3.1 大屏展示：

每周都會公示出上一周延保業(yè)務出現(xiàn)的問題，并通過內(nèi)部通訊工具和郵件發(fā)送給業(yè)務方負責人，支持異常投保單的下載。業(yè)務收到郵件后會按照郵件中的攻略去操作，完成正確的投保。截止目前幫助業(yè)務側完成40萬+的異常投保單的重新投保。幫助業(yè)務降低了客訴率，也幫助保司拿到保費。（圖2）

（圖2）

3.2 自動補單：

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

3.3 數(shù)據(jù)歸檔：

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

（圖3）

?

（圖4）

?

四、HM的內(nèi)核，技術架構和實現(xiàn)方案

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

1.技術架構

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

（圖5）

2.核心技術

2.1 規(guī)則引擎

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

（圖6）

（圖7）

2.2 報警引擎

報警引擎是指配置報警的一系列的規(guī)則，數(shù)據(jù)計算的規(guī)則，觸達的方式。創(chuàng)建好規(guī)則后，要對每一個規(guī)則進行詳細的報警配置，包括觸發(fā)報警的類型，報警規(guī)則，操作閾值，處理方式等。（圖8）報警類型指觸達方式，繼承了保險SaaS-msg的能力，支持郵件、內(nèi)部聊天工具、微信、電話等觸達方式。任務系統(tǒng)使用Easy-Job來動態(tài)管理任務。處理方式可以對接業(yè)務方Jsf 來完成閉環(huán)，也可以設置成歸檔，以便后續(xù)的有導出或對數(shù)的需求。

（圖8）

2.3 數(shù)據(jù)埋點

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

2.4 數(shù)據(jù)清洗

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

2.5 數(shù)據(jù)計算

hm只記錄異常數(shù)據(jù)，發(fā)力在異常數(shù)據(jù)的統(tǒng)計和計算上。在配置好規(guī)則節(jié)點和系統(tǒng)埋點后，hm會去計算每個節(jié)點的異常數(shù)據(jù)。根據(jù)報警規(guī)則來進行處理，或通知業(yè)務和產(chǎn)研，或調(diào)用業(yè)務系統(tǒng)的jsf接口去做異常數(shù)據(jù)的自動處理，又或者根據(jù)規(guī)則自行處理數(shù)據(jù)。

2.6 數(shù)據(jù)統(tǒng)計

hm每周會出數(shù)據(jù)統(tǒng)計報表發(fā)送給業(yè)務和產(chǎn)研。報表中會體現(xiàn)他負責的業(yè)務線下所有系統(tǒng)的異常數(shù)據(jù)，包括處理過的異常數(shù)據(jù)和未處理的異常數(shù)據(jù)，A業(yè)務線和B業(yè)務線異常對比數(shù)據(jù)，業(yè)務系統(tǒng)與業(yè)務系統(tǒng)的異常對比數(shù)據(jù)等。可以根據(jù)業(yè)務需求定制報表。幫助業(yè)務和產(chǎn)研更好掌握系統(tǒng)的最新狀況。

2.7 任務中心

任務中心是指xxljob任務指調(diào)度中心，它和報警規(guī)則強綁定的。調(diào)度任務分為兩類，一類是業(yè)務類任務，是動態(tài)去創(chuàng)建的任務，按照設置的corn執(zhí)行。另一類是平臺任務。用于維護業(yè)務類任務的，比如定期去刪除沒有異常的任務等。（圖9）

（圖9）

2.8 觸達展示

觸達方式支持了保險工作臺、內(nèi)部聊天工具、郵件、企業(yè)微信、電話語音等。根據(jù)業(yè)務方需求來選擇。

2.9 處理方式

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

2.10 開源能力：jaeger

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

審核編輯 黃宇