千萬級別資料 20 秒內反饋，攜程酒店智慧監控平臺如何實現？

摘要： 作者簡介 林晨曦，攜程酒店研發部資深測試開發工程師，主要從事測試框架和平臺的研發，現在負責監控系統與效能平臺，熱衷於研究技術提升測試工作效率。 一、前言 攜程酒店業務量巨大，產生海量的埋點資料，以應用為單位接入公共日誌平臺；常規監控系統無法精確定位業務問題，測試人員花費...

作者簡介

林晨曦，攜程酒店研發部資深測試開發工程師，主要從事測試框架和平臺的研發，現在負責監控系統與效能平臺，熱衷於研究技術提升測試工作效率。

一、前言

攜程酒店業務量巨大，產生海量的埋點資料，以應用為單位接入公共日誌平臺；常規監控系統無法精確定位業務問題，測試人員花費大量時間查詢與判斷異常資料，低效且反應滯後。

為此我們根據測試痛點設計了一系列面向具體業務指標的監控，並在此基礎上搭建了系統級的監控平臺。本文將介紹酒店的智慧監控系統，並詳細闡述其中核心部分：針對酒店Clog和ES埋點資料的智慧實時監控。

二、酒店監控系統

1、監控現狀

酒店業務眾多，關係鏈複雜，目前應用數量已經超過2000個，即使經過一系列線下測試，在上線以後還是要如履薄冰，業務人員要時刻關注各項指標，對波動及時查明原因，防止線上故障。

公共方面已有Sitemon，Hickwall等監控報表系統，我們結合了業務需求，在測試工作中構建了為測試工作服務的一些監控系統：

Smart：智慧監控平臺，基於主動健康監測和日誌收集的智慧保障系統

Mdata：效能埋點平臺，針對具體業務指標在ES&Dashboard裡埋點資料進行條件聚合用於效能預警與資料展示

Artemis：API自動化監控平臺，通過自動化執行收集資料進行監控，並對ES埋點涉及多個不同資料Index的業務指標進行邏輯處理的ES監控

2、監控工作簡介

為什麼要設計自己的監控系統？海量資料帶來了一系列挑戰：

資料量大：

通過CAT系統採集到每天埋點資料

-2000+億條日誌

-100+T業務日誌通過CAT進入ES

維度多：

如此海量資料，在資料大盤裡即使已有過濾條件搜尋仍如同大海撈針，以下為監控難點：

• 日誌平臺記錄大量零散資料，查詢不便

• 不能配置細粒度規則，使用者難以定製符合業務需求預警

• 無法判斷是否遺留問題

• 沒有分析模組，不能跟蹤使用者分析行為

• 業務人員只關注生產環境，測試環境日誌資訊未起到先驗效果

我們希望監控實現目標：

• 監控為業務服務，以具體業務需求為切入點，持續整合，快速交付

• 構建可擴充套件監控體系，避免為業務調整增加大量專案複雜度

• 監控儘量實時，提供資訊量全面

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

• 集中式管理，方便配置

在搭建監控系統過程中，我們主要是通過兩種方式：

• 主動檢測式監控: 通過自動化手段模擬使用者行為進行採點分析，統計Badcase

• 埋點收集方式: 與開發配合，在程式碼裡埋點關鍵資料，通過資料採集處理進行監控

監控系統以應用為維度，方便業務人員明確排查範圍

埋點資料採集監控佔了很大監控比重，資料真實性高，也方便做實時預警，處理埋點資料過程中採用了對已有Clog&ES&Dashboard埋點平臺做二次挖據方式。

之所以不直接通過Kafka消費原始資料，因為Clog&ES&Dashboard已有可以配置條件的索引過濾掉使用者無需關心資料，儘管資料落地有延遲，但是與需要過濾資料的量級相比，這種不利因素可以接受。以下介紹重點針對Clog與ES埋點監控內容。

3、監控效果

酒店監控平臺目前已經配置了30多種主動式自動化監控，並有以下系統級監控：

• Clog監控

• ES&Dashboard規則監控

• 機器狀態監控

• Job監控

• Badsql監控

• ART報表監控

• DB資料庫一致性監控

• CAT服務響應時間監控

監控獲得收益：

• 覆蓋所有酒店核心應用

• 系統靈敏度高，出現問題立即暴露，及時解決

• 發現需要分析問題>60000，平臺自動建立CP4 Bug>4000

三、Clog監控的前世今生

我們從Clog系統能獲取到的資訊：

• 日誌資訊: AppID、伺服器、標題、來源、資訊、錯誤型別、CatId

• 日誌級別: DEBUG、INFO、WARN、ERROR、FATAL

• 日誌型別: APP、URL、WEB_SERVICE、SQL、MEMCACHED

• 藉助CAT獲取詳細資訊

Clog監控系統根據日誌資訊指標配置成規則，採用了兩種監控方式：

1.0監控：應用級日誌監控, 使用者配置應用資訊，設定閾值與過濾項，掃描應用日誌根據歷史比對發現新錯誤資訊，超過閾值的錯誤量，需要關注錯誤內容預警到關注使用者。

1.0規則配製圖

2.0監控：重要Issue部門級智慧監控,使用者配置錯誤型別，設定需要關注應用資訊，掃描所有關注應用裡匹配該錯誤型別資訊並預警到關注使用者，生成缺陷到CP4。

2.0規則配置圖

監控初期1.0的預警物件是錯誤量和新問題，從1.0到2.0的擴充套件是一次從問題收集到智慧篩選的過程，如空指標引用、記憶體問題都是開發需要重點關注並解決的缺陷，這些處理也是可以明確為程式問題並直接開Bug的，從而減少了使用者分析時間，而且部門級監控可以拉取所有酒店應用資訊無需單獨配置。

監控原理：

• 使用者在系統中配置監控規則

• 主伺服器根據使用者配置自動生成執行任務，並排程分散式執行機執行，執行機分生產與測試環境，可收集不同環境資料

執行機配置管理圖

• 執行機上資料監視器通過配置規則批處理執行任務，該過程包括資料採集、演算法過濾、歷史比對、系統掃描，異常資料傳至郵件伺服器預警並推送到CP4，目前日執行任務數>30萬，最小時間粒度可至20秒

1.0預警郵件

2.0預警郵件

• 監控缺陷資料處理環節，生成質量閉環報告，資料直接推送給質量平臺，長期追蹤解決結果。

Clog監控系統架構圖

指標監控->全鏈路監控：

為幫助業務人員分析問題，需要提供儘可能詳細的資訊，讓使用者從多維角度快速定位問題來源，預警資訊集成了以下資訊：

• CAT系統獲取應用上下游呼叫關係與波動程度

• NOC系統獲取到配置修改資訊

• 釋出系統獲取最新發布狀態

• SLB系統獲取機器狀態資訊

Clog監控還提供了一些輔助功能：

• 整合TTS電話系統，重要預警可電話到負責人

• 整合Trace功能，有效能問題機器會被自動拉出叢集採集Trace用於效能分析

對使用者而言，使用Clog監控需要處理的內容：

• 配置規則

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

• 檢視個人未解決問題

• 推動開發解決未完成Bug

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

ES資料量巨大，但是它自帶的聚合功能可以大大減少資料量，使用者關注的其實還是符合特徵的數值指標。

根據特徵聚合ES資料，我們設計了早期Mdata平臺的ES監控，使用者直接配置Json到規則，後臺Job定時執行抓取資料來源資料。平臺有以下特徵：

• 配置簡單，使用者只需複製ES裡的Json內容

• 形式多樣，可以配置百分比與數值形式

• 監控採用系統預設與使用者配置兩種，系統預設採用環比增量預警方式

• 資料採集時間<10分鐘

• 半小時與按天預警同時設定

• 整合系統釋出資訊與使用者歷史分析內容

• 效能問題直接建立缺陷到CP4關聯到效能負責人

• 儲存時間長，系統保留超過半年資料，可以檢視長期趨勢與歷史分析內容

大量使用後的業務痛點：

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

• 效能問題成因複雜，定位困難

• 預警閾值不好控制，業務變更造成前後不一致內容多，寬嚴兩難

在進一步分析與調整中，採用了區別對待的處理方案，對於核心應用關鍵指標更多采用上下限閾值處理，並且預警時間達到<10分鐘。一般指標預警規則也更嚴格，達到連續增長趨勢才會觸發報警。

業務的發展帶來很多難以界定的指標，資料埋點往往不能用單一規則來處理，需要對ES資料做更深的挖掘，在原來單指標監控基礎上我們發展出了Artemis ES自定義指標監控，監控內容有以下擴充套件：

• 對抓取ES資料做了邏輯處理，包括對不同Index的資料進行聚合，專案複雜度有所增加，更多應用於數量有限的關鍵業務指標

• 配置規則多樣化，提供了更多閾值檢查

• 維度更接近業務內容，使用者有更多篩選方式

• 實時度高，抓取資料時間<2分鐘

目前對ES資料的挖掘還有很多系統，公共Sitemon，Hickwall上也能配置ES規則與報警，我們的主動式自動化監控也有一些是對更細的包括未聚合具體埋點內容的分析，資料探勘還有很多內容可以探索。

五、尾聲

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

從方法角度看，只有指標越細覆蓋越廣才能達到更高精度，而這需要大量邏輯處理提高了系統複雜度。現在流行的機器學習是個可以突破的方向，通過模型處理資料來提高報警精度，這也是監控下一步的工作目標，讓預警更快更準，監控更智慧化，在這個過程中需要更多思維突破與創新，讓質量真正閉環。

【推薦閱讀】