作者簡介

林晨曦，攜程酒店研發(fā)部資深測試開發(fā)工程師，主要從事測試框架和平臺的研發(fā)，現(xiàn)在負責監(jiān)控系統(tǒng)與性能平臺，熱衷于研究技術(shù)提升測試工作效率。

一、前言

攜程酒店業(yè)務量巨大，產(chǎn)生海量的埋點數(shù)據(jù)，以應用為單位接入公共日志平臺；常規(guī)監(jiān)控系統(tǒng)無法精確定位業(yè)務問題，測試人員花費大量時間查詢與判斷異常數(shù)據(jù)，低效且反應滯后。

為此我們根據(jù)測試痛點設(shè)計了一系列面向具體業(yè)務指標的監(jiān)控，并在此基礎(chǔ)上搭建了系統(tǒng)級的監(jiān)控平臺。本文將介紹酒店的智能監(jiān)控系統(tǒng)，并詳細闡述其中核心部分：針對酒店Clog和ES埋點數(shù)據(jù)的智能實時監(jiān)控。

二、酒店監(jiān)控系統(tǒng)

1、監(jiān)控現(xiàn)狀

酒店業(yè)務眾多，關(guān)系鏈復雜，目前應用數(shù)量已經(jīng)超過2000個，即使經(jīng)過一系列線下測試，在上線以后還是要如履薄冰，業(yè)務人員要時刻關(guān)注各項指標，對波動及時查明原因，防止線上故障。

公共方面已有Sitemon，Hickwall等監(jiān)控報表系統(tǒng)，我們結(jié)合了業(yè)務需求，在測試工作中構(gòu)建了為測試工作服務的一些監(jiān)控系統(tǒng)：

Smart：智能監(jiān)控平臺，基于主動健康監(jiān)測和日志收集的智能保障系統(tǒng)

Mdata：性能埋點平臺，針對具體業(yè)務指標在ES&Dashboard里埋點數(shù)據(jù)進行條件聚合用于性能預警與數(shù)據(jù)展示

Artemis：API自動化監(jiān)控平臺，通過自動化運行收集數(shù)據(jù)進行監(jiān)控，并對ES埋點涉及多個不同數(shù)據(jù)Index的業(yè)務指標進行邏輯處理的ES監(jiān)控

2、監(jiān)控工作簡介

為什么要設(shè)計自己的監(jiān)控系統(tǒng)？海量數(shù)據(jù)帶來了一系列挑戰(zhàn)：

數(shù)據(jù)量大：

通過CAT系統(tǒng)采集到每天埋點數(shù)據(jù)

-2000+億條日志

-100+T業(yè)務日志通過CAT進入ES

維度多：

如此海量數(shù)據(jù)，在數(shù)據(jù)大盤里即使已有過濾條件搜索仍如同大海撈針，以下為監(jiān)控難點：

日志平臺記錄大量零散數(shù)據(jù)，查詢不便

不能配置細粒度規(guī)則，用戶難以定制符合業(yè)務需求預警

無法判斷是否遺留問題

沒有分析模塊，不能跟蹤用戶分析行為

業(yè)務人員只關(guān)注生產(chǎn)環(huán)境，測試環(huán)境日志信息未起到先驗效果

我們希望監(jiān)控實現(xiàn)目標：

監(jiān)控為業(yè)務服務，以具體業(yè)務需求為切入點，持續(xù)集成，快速交付

構(gòu)建可擴展監(jiān)控體系，避免為業(yè)務調(diào)整增加大量項目復雜度

監(jiān)控盡量實時，提供信息量全面

覆蓋面廣，自動部署，減少人工值守時間

集中式管理，方便配置

在搭建監(jiān)控系統(tǒng)過程中，我們主要是通過兩種方式：

主動檢測式監(jiān)控: 通過自動化手段模擬用戶行為進行采點分析，統(tǒng)計Badcase

埋點收集方式: 與開發(fā)配合，在代碼里埋點關(guān)鍵數(shù)據(jù)，通過數(shù)據(jù)采集處理進行監(jiān)控

監(jiān)控系統(tǒng)以應用為維度，方便業(yè)務人員明確排查范圍

埋點數(shù)據(jù)采集監(jiān)控占了很大監(jiān)控比重，數(shù)據(jù)真實性高，也方便做實時預警，處理埋點數(shù)據(jù)過程中采用了對已有Clog&ES&Dashboard埋點平臺做二次挖據(jù)方式。

之所以不直接通過Kafka消費原始數(shù)據(jù)，因為Clog&ES&Dashboard已有可以配置條件的索引過濾掉用戶無需關(guān)心數(shù)據(jù)，盡管數(shù)據(jù)落地有延遲，但是與需要過濾數(shù)據(jù)的量級相比，這種不利因素可以接受。以下介紹重點針對Clog與ES埋點監(jiān)控內(nèi)容。

3、監(jiān)控效果

酒店監(jiān)控平臺目前已經(jīng)配置了30多種主動式自動化監(jiān)控，并有以下系統(tǒng)級監(jiān)控：

Clog監(jiān)控

ES&Dashboard規(guī)則監(jiān)控

機器狀態(tài)監(jiān)控

Job監(jiān)控

Badsql監(jiān)控

ART報表監(jiān)控

DB數(shù)據(jù)庫一致性監(jiān)控

CAT服務響應時間監(jiān)控

監(jiān)控獲得收益：

覆蓋所有酒店核心應用

系統(tǒng)靈敏度高，出現(xiàn)問題立即暴露，及時解決

發(fā)現(xiàn)需要分析問題>60000，平臺自動創(chuàng)建CP4 Bug>4000

三、Clog監(jiān)控的前世今生

我們從Clog系統(tǒng)能獲取到的信息：

日志信息: AppID、服務器、標題、來源、信息、錯誤類型、CatId

日志級別: DEBUG、INFO、WARN、ERROR、FATAL

日志類型: APP、URL、WEB_SERVICE、SQL、MEMCACHED

借助CAT獲取詳細信息

Clog監(jiān)控系統(tǒng)根據(jù)日志信息指標配置成規(guī)則，采用了兩種監(jiān)控方式：

1.0監(jiān)控：應用級日志監(jiān)控, 用戶配置應用信息，設(shè)置閾值與過濾項，掃描應用日志根據(jù)歷史比對發(fā)現(xiàn)新錯誤信息，超過閾值的錯誤量，需要關(guān)注錯誤內(nèi)容預警到關(guān)注用戶。

1.0規(guī)則配制圖

2.0監(jiān)控：重要Issue部門級智能監(jiān)控,用戶配置錯誤類型，設(shè)置需要關(guān)注應用信息，掃描所有關(guān)注應用里匹配該錯誤類型信息并預警到關(guān)注用戶，生成缺陷到CP4。

2.0規(guī)則配置圖

監(jiān)控初期1.0的預警對象是錯誤量和新問題，從1.0到2.0的擴展是一次從問題收集到智能篩選的過程，如空指針引用、內(nèi)存問題都是開發(fā)需要重點關(guān)注并解決的缺陷，這些處理也是可以明確為程序問題并直接開Bug的，從而減少了用戶分析時間，而且部門級監(jiān)控可以拉取所有酒店應用信息無需單獨配置。

監(jiān)控原理：

用戶在系統(tǒng)中配置監(jiān)控規(guī)則

主服務器根據(jù)用戶配置自動生成執(zhí)行任務，并調(diào)度分布式執(zhí)行機執(zhí)行，執(zhí)行機分生產(chǎn)與測試環(huán)境，可收集不同環(huán)境數(shù)據(jù)

執(zhí)行機配置管理圖

執(zhí)行機上數(shù)據(jù)監(jiān)視器通過配置規(guī)則批處理運行任務，該過程包括數(shù)據(jù)采集、算法過濾、歷史比對、系統(tǒng)掃描，異常數(shù)據(jù)傳至郵件服務器預警并推送到CP4，目前日運行任務數(shù)>30萬，最小時間粒度可至20秒

1.0預警郵件

2.0預警郵件

監(jiān)控缺陷數(shù)據(jù)處理環(huán)節(jié)，生成質(zhì)量閉環(huán)報告，數(shù)據(jù)直接推送給質(zhì)量平臺，長期追蹤解決結(jié)果。

Clog監(jiān)控系統(tǒng)架構(gòu)圖

指標監(jiān)控->全鏈路監(jiān)控：

為幫助業(yè)務人員分析問題，需要提供盡可能詳細的信息，讓用戶從多維角度快速定位問題來源，預警信息集成了以下信息：

CAT系統(tǒng)獲取應用上下游調(diào)用關(guān)系與波動程度

NOC系統(tǒng)獲取到配置修改信息

發(fā)布系統(tǒng)獲取最新發(fā)布狀態(tài)

SLB系統(tǒng)獲取機器狀態(tài)信息

Clog監(jiān)控還提供了一些輔助功能：

集成TTS電話系統(tǒng)，重要預警可電話到負責人

集成Trace功能，有性能問題機器會被自動拉出集群采集Trace用于性能分析

對用戶而言，使用Clog監(jiān)控需要處理的內(nèi)容：

配置規(guī)則

處理預警郵件，在平臺及時完成分析

查看個人未解決問題

推動開發(fā)解決未完成Bug

四、從Mdata到Artemis：深度挖掘ES

ES數(shù)據(jù)量巨大，但是它自帶的聚合功能可以大大減少數(shù)據(jù)量，用戶關(guān)注的其實還是符合特征的數(shù)值指標。

根據(jù)特征聚合ES數(shù)據(jù)，我們設(shè)計了早期Mdata平臺的ES監(jiān)控，用戶直接配置Json到規(guī)則，后臺Job定時執(zhí)行抓取數(shù)據(jù)源數(shù)據(jù)。平臺有以下特征：

配置簡單，用戶只需復制ES里的Json內(nèi)容

形式多樣，可以配置百分比與數(shù)值形式

監(jiān)控采用系統(tǒng)默認與用戶配置兩種，系統(tǒng)默認采用環(huán)比增量預警方式

數(shù)據(jù)采集時間<10分鐘

半小時與按天預警同時設(shè)置

集成系統(tǒng)發(fā)布信息與用戶歷史分析內(nèi)容

性能問題直接創(chuàng)建缺陷到CP4關(guān)聯(lián)到性能負責人

存儲時間長，系統(tǒng)保留超過半年數(shù)據(jù)，可以查看長期趨勢與歷史分析內(nèi)容

大量使用后的業(yè)務痛點：

預警郵件多，對于波動較大指標很難界定

性能問題成因復雜，定位困難

預警閾值不好控制，業(yè)務變更造成前后不一致內(nèi)容多，寬嚴兩難

在進一步分析與調(diào)整中，采用了區(qū)別對待的處理方案，對于核心應用關(guān)鍵指標更多采用上下限閾值處理，并且預警時間達到<10分鐘。一般指標預警規(guī)則也更嚴格，達到連續(xù)增長趨勢才會觸發(fā)報警。

業(yè)務的發(fā)展帶來很多難以界定的指標，數(shù)據(jù)埋點往往不能用單一規(guī)則來處理，需要對ES數(shù)據(jù)做更深的挖掘，在原來單指標監(jiān)控基礎(chǔ)上我們發(fā)展出了Artemis ES自定義指標監(jiān)控，監(jiān)控內(nèi)容有以下擴展：

對抓取ES數(shù)據(jù)做了邏輯處理，包括對不同Index的數(shù)據(jù)進行聚合，項目復雜度有所增加，更多應用于數(shù)量有限的關(guān)鍵業(yè)務指標

配置規(guī)則多樣化，提供了更多閾值檢查

維度更接近業(yè)務內(nèi)容，用戶有更多篩選方式

實時度高，抓取數(shù)據(jù)時間<2分鐘

目前對ES數(shù)據(jù)的挖掘還有很多系統(tǒng)，公共Sitemon，Hickwall上也能配置ES規(guī)則與報警，我們的主動式自動化監(jiān)控也有一些是對更細的包括未聚合具體埋點內(nèi)容的分析，數(shù)據(jù)挖掘還有很多內(nèi)容可以探索。

五、尾聲

監(jiān)控的目標是為了提高系統(tǒng)預警準確率與實時性，從而提高測試效率，減少人工值守時間。而監(jiān)控全面化帶來了一系列新的問題，目前公共Sitemon上已有超過10000個監(jiān)控指標，大量告警需要更好的降噪處理。

從方法角度看，只有指標越細覆蓋越廣才能達到更高精度，而這需要大量邏輯處理提高了系統(tǒng)復雜度?，F(xiàn)在流行的機器學習是個可以突破的方向，通過模型處理數(shù)據(jù)來提高報警精度，這也是監(jiān)控下一步的工作目標，讓預警更快更準，監(jiān)控更智能化，在這個過程中需要更多思維突破與創(chuàng)新，讓質(zhì)量真正閉環(huán)。