作者：京東保險 管順利
一、傳統監控系統的盲區，如何打造業務狀態監控，
在系統架構設計中非常重要的一環是要做資料監控和資料最終一致性，關于一致性的補償，已經由演算法部的大佬總結過就不在贅述，這里主要講如何去補償？補償的方案哪些？這就引出來資料監控系統了，有小伙伴會問了，為什么業務狀態監控系統可以做補償？別急，往下看，
傳統監控系統分為兩種，系統監控和業務監控，系統監控有并發量監控、例外監控、呼叫鏈監控、埠監控、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作業臺，是我們平臺研發部自研的一款面向業務的，例外監控處理的解決方案，匯集了團隊每位伙伴的智慧，感興趣的同學可以聯系我們，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/551238.html
標籤：架構設計
下一篇：返回列表