Categories
程式開發

愛奇藝在日誌實時數據監控的探索與實踐


傳統監控的痛點

以往監控依賴虛機部署的shell、py腳本,單台虛機異常數目達到閾值,即推送報警,這種方式存在如下問題。

愛奇藝在日誌實時數據監控的探索與實踐 1

為解決如上痛點,我們實時分析線上日誌,採集各業務訪問日誌、異常日誌、Nginx日誌、前端日誌,四種維度數據上報,衡量應用系統質量的標準得以完善;對四種日誌不同指標進行數據監控,各應用具備了分鐘級應用的報警能力;搭建日誌體系,整個系統有了提取關鍵線索能力,多維度快速定位問題。問題一旦定位就能通過會員的線上運維規范進行容災操作:降級,切換通道或限流,從而保證整體的核心鏈路穩定性,避免客訴、用戶報障。

目前會員監控分為基礎監控及上層監控,基礎監控依賴於shell腳本,進行數據上報,監控機器相關指標(CPU、內存、線程數等);上層監控依賴於各層日誌數據,監控各業務的網絡狀態、成功率、RT時間、業務異常、業務狀態碼等上層指標,目前已實現分鐘粒度報警,5min內快速響應。

技術方案

線上實時日誌量是巨大的,當數據量增長到10億至百億級別,傳統的關係型數據庫基本被排除在可選的集數架構之外了,同時基於日誌的時間序列特點及公司體系建設情況,經過對功能性、可擴展性、社區活躍度和文檔完善度的對比後,我們選擇Spark Streaming和Flink作為流計算引擎,選擇Druid作為實時分析數據庫。 Spark Streaming通過微批次將實時數據拆成一個個批處理任務,通過批處理的方式完成各個子Batch,API非常簡單靈活。 Flink基於原生數據流計算實現,保證Exactly once語義,支持延時數據處理,可以達到毫秒級低延時。 Druid是一款開源的為實時數據的亞秒級查詢設計的數據存儲引擎。主要用於進行OLAP聚合分析。這些工具的API和文檔都比較完善,社區活躍度較高,通過服務雲實時分析平台(RAP)能夠快速搭建,維護成本低。

數據流圖

愛奇藝在日誌實時數據監控的探索與實踐 2

數據採集:虛機中安裝Venus-Agent(愛奇藝自研基於Filebeat數據採集)進行實時數據採集,上報至指定kafka集群。

實時處理:會員日誌監控90%指標是由實時計算產生的,相關報警數據處理依賴大數據實時分析平台(Realtime analysis platform)進行解析,過濾,處理,聚合之後寫入分佈式存儲當中。

存儲:Druid集群在整個會員監控中是集數據存儲、展現的數據中心,所有的實時計算結果數據、閾值數據、其他時間序列的數據都要匯總到Druid存儲當中。

離線計算:離線計算部分主要處理的是離線的數據表,數據來源為Druid及Mysql集群中,用於每天的日報、週報,用來進行長時間跨度的分析,智能化指標數據訓練。

監控相關功能

下圖為已有相關功能圖:

愛奇藝在日誌實時數據監控的探索與實踐 3

利用Nginx日誌、應用異常日誌、應用訪問、前端投遞日誌進行如上不同維度的分析,實現了固定閾值、實時突增等觸發方式,熱聊、郵件、電話等推送方式。

日誌監控

Nginx日誌:可獲取網絡層信息,如:接口、機房、HTTP狀態碼、域名、IP、RT時間等,我們對這些信息進行實時聚合、監控、報警後二次分析,進行精細化告警,提供排查方向,極大提高排查效率。例如下圖中,通過報警截圖可知單台機器499狀態碼佔比過高,引起成功率降低,排查方向可確定為這台機器問題,極大提高排查效率。

愛奇藝在日誌實時數據監控的探索與實踐 4

前端投遞日誌:後端監控到的響應時間,往往不能完全真實反映用戶的網絡狀況,因此我們在關鍵業務相關頁面,進行接口相關數據投遞,從用戶側反映後端接口狀態,更具有價值。目前監控維度包括頁面加載耗時、後端接口耗時、靜態資源耗時等,區分地區、地域、運營商等信息。如通過指標分析出某個運營商、某個地區的用戶請求存在較高延時,則可進一步調整對應DNS配置,從用戶側優化網絡狀態。

業務訪問日誌:業務返回的狀態碼,可從業務角度實時監測服務狀態,提取ERROR日誌,進行實時分析告警;比如會員鑑權業務,Code-Q00508代表平台值不匹配,對應業務可能存在編輯劃價錯誤;實現方式同異常告警相似,同樣進行了問題分析定位,給與排查方向。

業務異常日誌:對於業務來說,每一次異常都代表了系統間的一個問題,就是隱藏的一次客訴,比如ResourceAccessException超時問題、NEP空指針問題、UnknownHostExcepiton解析問題,都會對線上用戶帶來影響;

如下報警截圖所示,ResourceAccessException異常集中於電信機房,問題出在下游系統中電信機房服務超時,同時提供接口名稱,可快速定位問題方,提高排查效率,避免客訴問題。

愛奇藝在日誌實時數據監控的探索與實踐 5

網絡運維數據:以往線上機器數量及流量配比,多依賴於運維經驗,容易出現錯誤;利用Nginx日誌,可離線統計每日流量峰值,進一步分析機器數量,提出優化建議,提高機器利用率,避免機器浪費;同時檢測Nginx機房流量不均問題,提供予運維人員以數據指導,極大增加了操作的安全性、及時性。

除此之外提供網絡拓撲、流量拓撲等功能,也能進一步增加開發人員對網絡感知。

愛奇藝在日誌實時數據監控的探索與實踐 6

遇到的問題

1、數據標準化

處理日誌信息首要問題是要統一日誌格式,保證採集到數據的準確性,同時會員這邊80%的應用部署在虛機上,20%部署在QAE中,監控採集需同時兼容兩種部署方式;

  • Nginx日誌,提供統一化運維平台,封裝Nginx安裝、擴容、克隆等操作,內置工具統一Nginx日誌模塊,統一日誌格式;
  • Exception日誌,提供通用化配置方案,支持QAE應用及虛機應用,分別採用不同數據流處理,將kafka流合併後統一消費;
  • 業務日誌,提供統一日誌組件,打印request、response相應信息即可。

2、機器採集性能瓶頸,延遲

採集日誌客戶端(Venus-Agent)部署在應用機器上,目前通過CGroup限制資源使用(默認使用1核128M內存),採集效率依賴於CPU、內存資源等資源,同時也被提取規則的複雜程度所影響。

  • 對於大流量應用來說,應盡可能精簡提取規則,同時平衡資源等關係 ;
  • 精簡無用日誌打印,盡可能一條請求打印一條日誌,避免重複打印;
  • 日誌流量過大,考慮採樣提取。

歷史教訓 :

  • 20WQPS應用,一條請求打印5條日誌,日誌量放大至100WQPS,資源集群瀕臨崩潰;
  • 經過總結:經反复實踐,對於Nginx機器(8core32G),限制在2core 2G可保證4WQPS 同時採集;
  • 對於虛機(6core8G),可維持在1core 512M 進行採集 。

3、減少計算資源,節約成本

計算資源同樣需要合理分配,Druid單Task預計能消費15Wqps的消息,增加Task可以提高處理能力。由於Druid自身的partition能力不是特別出色,所以多5倍資源並不能提升5倍的處理能力。所以採取將高QPS的實時數據拆分成多個子Topic的方式,接入Druid多個Datasource,對於百萬QPS的Nginx流量來說,有如下兩種節約方案,採用第二點方案,拆分多個數據流後,相應計算資源節約了120core。 :

  • 採樣流量數據。優點:改造成本小;缺點:Nginx日誌對排查問題極為重要,採樣會缺少相應日誌;
  • Nginx機器流量拆分,高流量應用Nginx集群獨立部署,拆分多個數據流。優點:可避免流量衝擊對其他Nginx集群造成影響,保證核心業務的穩定性;缺點:改造成本高,依賴於基礎運維體系。

4、Spark Streaming/Flink消費延遲

對於監控系統,報警時間尤為重要,如何保證消費時能平穩進行,不出現延遲尤為重要,將調優Kafka Partition數以及Druid Task數,調整到最優的值。

另外,由於Spark Streaming偽實時,將實時任務拆分成一個個批處理逐一阻塞處理。從中發現SparkStreaming任務中的平均處理時間並不高,常常由於單個Task太慢,導致單批次處理太慢。於是針對實時OLAP、並不關註消息的到達順序的場景,將spark.streaming.concurrentJobs配置成流任務的並行度,以提高流計算任務並行處理能力。

價值與未來規劃

愛奇藝會員服務團隊供通用化監控平台,接入方式簡單,可快速對系統搭建以上監控體系,並可以面向公司的其他業務團隊監控服務。建立完整的跟進機制,多級反饋,提高告警感知,提升排查效率80%以上,預先發現90+次會員客訴問題,客訴率極大降低,監控覆蓋400+種異常提供有效告警 4800+次。

未來,愛奇藝會員服務團隊將從監控閾值智能化、流量問題預測、輔助定位等方面進行進一步優化:

  • 監控閾值智能化:將監控向智能化增強,在業務監控的某些環節上代替人工執行和判斷的過程。人工維護監控目標和閾值是以經驗為參考的;依賴對歷史樣本數據統計分析、以往問題場景判斷,得出依據,系統自動判斷哪些目標需要監控、同時智能調整相應閾值策略。
  • 流量問題預測:通過對Nginx流量日誌的收集,使用智能預測算法模型,收集原有流量數據及收集相應熱劇、營銷等流量指標,預測服務流量峰值,給開發人員以流量預警機制。
  • 輔助定位:監控覆蓋更多的鏈路及模塊,將報警關聯,智能分析出問題場景,提高分析問題原因準確性,降低報警漏報率、誤報率。

本文轉載自公眾號愛奇藝技術產品團隊(ID:iQIYI-TP)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247486371&idx=1&sn=3d5c15fb99c45c0eb1701090e1a0a6df&chksm=e9769780de011e9688313d7c0241c5592596f23c0e62adb64dd035a569226c4de2b04b7b3e94&scene=27#wechat_redirect