【51CTO.com原創(chuàng)稿件】1 引言

目前業(yè)界已經(jīng)有很多杰出的監(jiān)控系統(tǒng)如Nagios、Zabbix、Prometheus，但都是面向運(yùn)維人員，在應(yīng)對復(fù)雜多變的業(yè)務(wù)指標(biāo)監(jiān)控時(shí)顯得不夠靈活。

為此蘇寧數(shù)據(jù)云在流式計(jì)算框架Apache Flink之上設(shè)計(jì)了一組包含ETL、指標(biāo)計(jì)算、告警觸發(fā)、告警通知模塊的業(yè)務(wù)監(jiān)控引擎。

其基本規(guī)則是告警SQL DSL語言，定義完備易用的場景規(guī)則語法和算子并支持動態(tài)更新調(diào)整，以便于業(yè)務(wù)方接入。下面對其基本原理和實(shí)現(xiàn)進(jìn)行介紹，供各位同行參考指正。

2 DSL規(guī)則設(shè)計(jì)

初期調(diào)研了各個(gè)業(yè)務(wù)方的需求，整理歸納出核心需求點(diǎn)主要是基于維度和時(shí)間的指標(biāo)絕對值、同環(huán)比或方差在超出閾值范圍則觸發(fā)告警，且業(yè)務(wù)方接入的是原始明細(xì)數(shù)據(jù)，故在設(shè)計(jì)規(guī)則中需要包含數(shù)據(jù)清洗過濾、分組、聚合計(jì)算、時(shí)間窗口設(shè)置特性。

而SQL語言作為開發(fā)人員最熟悉的數(shù)據(jù)處理語言，選擇其作為原型，可以省去理解和溝通的成本。

語法規(guī)則如下：

SELECT {metrics} FROM {metricFilters} WHERE {alertConditions} GROUP BY {groupByExpr} ORDER BY {orderByExpr} FOR LAST {number} MINUTE 

• SELECT子句指標(biāo)計(jì)算
• FROM子句數(shù)據(jù)過濾表達(dá)式
• WHERE子句告警狀態(tài)判斷表達(dá)式
• GROUP BY子句數(shù)據(jù)分組
• ORDER BY子句排序規(guī)則
• FOR LAST子句計(jì)算窗口時(shí)間

目前聚合函數(shù)支持的均值(avg)、記數(shù)(count)、總數(shù)(sum)、去重記數(shù)(distinct_count)等指標(biāo)計(jì)算，并支持多個(gè)指標(biāo)四則混合運(yùn)算、位運(yùn)算、比較運(yùn)算、邏輯運(yùn)算。

以下SQL規(guī)則表達(dá)的業(yè)務(wù)含義是根據(jù)錯(cuò)誤類型和城市信息進(jìn)行分組，5分鐘內(nèi)錯(cuò)誤數(shù)量大于100且與前5分鐘環(huán)比大于20%則觸發(fā)告警：

SELECT COUNT(errorType, 5) AS currentTypeNum, COUNT(errorType, 10, 5) AS previewTypeNum, (currentTypeNum - previewTypeNum) / previewTypeNumAS circularPercent, errorType, city 
FROM mobileAppIdIN ("Suning_PCbrowser","Suning_WAP")   
WHERE currentTypeNum>100 AND circularPercent>0.2   
GROUP BY errorType, city 
ORDER BY EVENT_TIME  
FOR LAST10 MINUTE 

3 實(shí)現(xiàn)設(shè)計(jì)

3.1 SQL解析

基于Antlr定義詞法和語法，使用Maven Antlr插件生成AST解析器，Visitor模式遍歷語法樹實(shí)現(xiàn)各個(gè)部分處理器，不熟悉的同學(xué)可以參考Antlr官方手冊，此處不再贅述。

解析SQL語句過程如下：

• 提取所有計(jì)算中用的到字段和過濾條件(FROM語句)，作為預(yù)處理器用于ETL過程
• WHERE子句抽象為布爾表達(dá)式，系統(tǒng)狀態(tài)判斷條件
• GROUP BY子句抽象為從一個(gè)數(shù)據(jù)對象中提取分組Key的處理器
• ORDER BY從句中提取時(shí)間窗口字段即Apache Flink中Event Time或Process Time
• FOR LAST子句提取出時(shí)間窗口大小
• SELECT語句是一組支持AS別名的算子，執(zhí)行后的結(jié)果為鍵值對，即業(yè)務(wù)指標(biāo)

需要注意的是考慮到ETL過程和計(jì)算過程都是獨(dú)立模塊，若計(jì)算過程通過字段名引用字段值，則中間對象必然是鍵值對方式的Map結(jié)構(gòu)，在傳輸中序列化和反序列化必然會對性能有一定的影響。

為此在遍歷抽象語法樹過程中須構(gòu)建一個(gè)解析上下文，把字段名引用改為數(shù)組下標(biāo)，ETL過程產(chǎn)生的中間數(shù)據(jù)對象為數(shù)組結(jié)構(gòu)，計(jì)算時(shí)訪問字段值的時(shí)間復(fù)雜度為O(1)。

例如原始數(shù)據(jù)為：

{"errorType":"E005","mobileAppId":"Suning_WAP","city":"025","network":"CMCC"} 
解析出子字段數(shù)組[“errorType”,”city”]發(fā)送ETL模塊，處理后數(shù)據(jù)對象Row為[“E005”,”025”]，算子COUNT(“errorType”)實(shí)際運(yùn)行中為COUNT(ROW[0]) 

3.2 整體架構(gòu)

整個(gè)流程中ETL和告警計(jì)算模塊都是運(yùn)行在Apache Flink中，借用Flink實(shí)時(shí)計(jì)算和狀態(tài)持久化能力。

每個(gè)業(yè)務(wù)接入方的數(shù)據(jù)格式不盡相同，把相關(guān)數(shù)據(jù)解析、清洗、過濾、豐富等功能單獨(dú)抽離成ETL模塊，可以根據(jù)接入方業(yè)務(wù)需求單獨(dú)定制部署，其中SQL中FROM階段提前到ETL模塊，提取過濾掉不需要的數(shù)據(jù)，降低數(shù)據(jù)傳輸量。

3.3 SQL引擎在Flink中的運(yùn)行機(jī)制

• ETL模塊

告警規(guī)則SourceStream轉(zhuǎn)成廣播流BroadcastStream并connect到數(shù)據(jù)解析Stream，因并行度不一致且未分組須使用BroadcastProcessFunction處理規(guī)則的變化通知，把SQL規(guī)則解析成字段提取和過濾處理器，保存在BroadcastState中達(dá)到數(shù)據(jù)流和廣播流共享狀態(tài)的目的。

• 告警計(jì)算模塊

從Kafka中消費(fèi)ETL模塊提取的字段和規(guī)則ID，根據(jù)告警規(guī)則Group子句提取分組信息;結(jié)合規(guī)則流解析Select子句表達(dá)式計(jì)算所有指標(biāo);再次結(jié)合規(guī)則流解析Where 子句告警觸發(fā)條件和狀態(tài)機(jī)相關(guān)參數(shù)，判斷系統(tǒng)當(dāng)前健康狀態(tài)，觸發(fā)健康狀態(tài)機(jī)變遷;把系統(tǒng)狀態(tài)變遷和當(dāng)前指標(biāo)值作為告警事件寫入Kakfa，由告警通知模塊根據(jù)通知規(guī)則配置處理相關(guān)發(fā)送邏輯。

3.4 聚合計(jì)算

Apache Flink是流式實(shí)時(shí)處理框架，而聚合計(jì)算類似于批處理，需要計(jì)算窗口內(nèi)的所有數(shù)據(jù);相對應(yīng)告警SQL可能會產(chǎn)生大量分組，每個(gè)分組其實(shí)都是獨(dú)立的告警規(guī)則，若是緩存一個(gè)事件窗口的數(shù)據(jù)進(jìn)行計(jì)算，會對Flink的狀態(tài)維護(hù)產(chǎn)生巨大壓力，所以對于聚合計(jì)算采用的分鐘級分桶計(jì)算和累加器聚合結(jié)果設(shè)計(jì)思路。

• 分桶

根據(jù)時(shí)間窗口長度創(chuàng)建環(huán)形隊(duì)列，每分鐘一個(gè)桶，按照時(shí)間計(jì)算當(dāng)前元素桶的位置，計(jì)算當(dāng)前桶的值。

• 累加器

類似于Spark和Flink中累加器Accumulator實(shí)現(xiàn)，保存分鐘級計(jì)算中間結(jié)果、合并累加器、獲取最終值，因此計(jì)算過程中不必保留原始數(shù)據(jù)，只需要在Flink中保存累加器的狀態(tài)即可。

/** 
     * Creates a new accumulator, starting a new aggregate. 
     */ 
     ADD createAccumulator(); 
 
     /** 
     * Adds the given input value to the given accumulator, returning the 
     * new accumulator value. 
     */ 
ADD add(ELE value, ADD accumulator); 
 
/** 
     * Gets the result of the aggregation from the accumulator. 
     */ 
OUT getResult(ADD accumulator); 
 
/** 
     * Merges two accumulators, returning an accumulator with the merged state. 
     */ 
ADD merge(ADD a, ADD b); 
} 

其中去重計(jì)數(shù)distinct_count聚合計(jì)算在告警場景允許精度損失故采用支持分桶累加的HyperLogLog算法，降低對內(nèi)存的要求。

3.5 告警狀態(tài)機(jī)

是否產(chǎn)生告警事件并不是依據(jù)計(jì)算出的指標(biāo)，而是根據(jù)Where從句判斷指標(biāo)是否超出閾值返回True或False確定當(dāng)前系統(tǒng)健康狀態(tài)，比對當(dāng)前狀態(tài)產(chǎn)生的健康狀態(tài)變遷事件作為觸發(fā)告警事件。

目前設(shè)計(jì)系統(tǒng)的狀態(tài)有三種，即正常(Normal)、警告(Warning)、嚴(yán)重(Critical)，而后兩種就是分別對應(yīng)兩個(gè)SQL DSL中Where從句表達(dá)式，狀態(tài)變遷圖如下：

業(yè)務(wù)系統(tǒng)是否產(chǎn)生告警通知也可以根據(jù)這幾種事件進(jìn)行配置，如果連續(xù)5分鐘異常才產(chǎn)生告警，則可以只關(guān)注CONTINUE相關(guān)事件。當(dāng)然告警通知系統(tǒng)也有通知合并和告警風(fēng)暴抑制相關(guān)功能。

4 問題和展望

目前此引擎已經(jīng)用于蘇寧易購登錄、商品詳情頁、購物車和支付多個(gè)業(yè)務(wù)線的用戶體驗(yàn)監(jiān)控，幫助產(chǎn)品和業(yè)務(wù)運(yùn)營人員可以快速發(fā)現(xiàn)和定位問題。為了提升處理能力和降低接入難度，以下兩個(gè)方面還需要進(jìn)行優(yōu)化：

• 改進(jìn)Apache Flink狀態(tài)管理 現(xiàn)在Flink集群中狀態(tài)管理使用的FsStateBackend機(jī)制,狀態(tài)保存在HDFS文件系統(tǒng)，在高基數(shù)維度或多維組合產(chǎn)生海量分組的業(yè)務(wù)場景下可能會有OOM和性能風(fēng)險(xiǎn)，下一步準(zhǔn)備切換為支持增量Checkpoint的RocksDB狀態(tài)存儲方案。
• 異常檢測智能化 現(xiàn)有告警規(guī)則如何判斷系統(tǒng)狀態(tài)是否異常還是依據(jù)靜態(tài)閾值，這種方式要求業(yè)務(wù)方對系統(tǒng)指標(biāo)有精確的了解，且隨著業(yè)務(wù)的變化要不斷調(diào)整，不符合業(yè)界的發(fā)展趨勢。下一階段計(jì)劃針對新業(yè)務(wù)無歷史數(shù)據(jù)的場景采用曲線波動檢測3sigma和中位數(shù)絕對偏差MAD(Median absolute deviation)算法，而比較穩(wěn)定的業(yè)務(wù)線引入時(shí)間序列異常檢測機(jī)器學(xué)習(xí)。

蘇寧數(shù)據(jù)云服務(wù)產(chǎn)品

蘇寧數(shù)據(jù)云已有大數(shù)據(jù)開發(fā)套件(提供全方位的大數(shù)據(jù)開發(fā)服務(wù))、人工智能服務(wù)(實(shí)現(xiàn)智能的人機(jī)互動做出更好決策)、數(shù)據(jù)分析及展示服務(wù)(提供海量數(shù)據(jù)處理與分析方法)、平臺基礎(chǔ)服務(wù)(提供大數(shù)據(jù)平臺基礎(chǔ)服務(wù))，實(shí)時(shí)告警數(shù)據(jù)分析平臺也在規(guī)劃建設(shè)中。實(shí)時(shí)計(jì)算中實(shí)現(xiàn)監(jiān)控規(guī)則DSL是內(nèi)部項(xiàng)目的一次技術(shù)探索，若能經(jīng)過實(shí)際業(yè)務(wù)的考驗(yàn)，也會考慮通過數(shù)據(jù)云對外提供服務(wù)。

作者簡介

黃小虎，蘇寧科技集團(tuán)消費(fèi)者平臺購物流程架構(gòu)負(fù)責(zé)人，全面負(fù)責(zé)蘇寧易購商品詳情頁、購物車、大聚會等核心系統(tǒng)的優(yōu)化及大促保障工作。對電商交易流程和業(yè)務(wù)有較深入的思考和研究，專注于高并發(fā)大型電商網(wǎng)站的架構(gòu)設(shè)計(jì)、高可用的系統(tǒng)設(shè)計(jì)。曾主導(dǎo)和參與了 Commerce 系統(tǒng)拆分、商品詳情頁接入層優(yōu)化、云信客服系統(tǒng)重構(gòu)等重大技術(shù)攻關(guān)項(xiàng)目。現(xiàn)致力于打造蘇寧易購新一代核心購物流程系統(tǒng)，希望將購物體驗(yàn)做到更好。

胡正林，蘇寧科技集團(tuán)消費(fèi)者平臺高級架構(gòu)師，十余年軟件開發(fā)經(jīng)驗(yàn)，熟悉大型分布式高并發(fā)系統(tǒng)架構(gòu)和開發(fā)，目前主要負(fù)責(zé)易購各系統(tǒng)架構(gòu)優(yōu)化與大促保障工作。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】