《監(jiān)控系統(tǒng)故障定位之事件關聯(lián)分析的設計介紹》要點：
本文介紹了監(jiān)控系統(tǒng)故障定位之事件關聯(lián)分析的設計介紹，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹

本文作者是吳城?聯(lián)系方式：autohomeops@autohome.com.cn,主要負責汽車之家云平臺的開發(fā)和技術管理工作. 個人Blog?http://jackywu.github.io/

團隊介紹

我們是汽車之家運維團隊,是汽車之家技術部里最為核心的團隊,由op和dev共同組成.我們的目標是為汽車之家集團打造一個高性能,高可擴展,低成本,并且穩(wěn)定可靠的網站基礎設施平臺. 團隊技術博客地址為 http://autohomeops.corpautohome.com

一、前言

在《汽車之家監(jiān)控系統(tǒng)的第一次里程碑》](http://autohomeops.corpautohome.com/articles/汽車之家監(jiān)控系統(tǒng)的第一次里程碑/)之后,我們實現(xiàn)了如下幾個小Feature

1. URL監(jiān)控
2. 日志監(jiān)控,并且在告警信息中帶上錯誤日志片段

而后,我們又希望能夠實現(xiàn)所謂的“自動故障定位”,來提升問題診斷的效率.

二、思路

我們認為,一個異常問題的發(fā)生,必定是有一個或者多個原因導致的,我們用“事件(Event)”來描述這個異常.網站的QPS增大超預期是一個事件,后端接口響應時間變大超預期是一個事件,服務器的CPU-Load增大超預期是一個事件,有人對MySQL服務器進行了配置變更是一個事件,有人進行了一次業(yè)務代碼發(fā)布也是一個事件,找出這些事件之間的關系是實現(xiàn)故障定位的關鍵.

我們理解有兩種故障定位的方法

1. 事件關聯(lián)分析
2. 決策樹自動推理

我們目前在實踐第一種方法.

三、方案

監(jiān)控指標分類

為了方便進行分析定位,我們對所有采集的監(jiān)控指標進行了分類

解釋

• 業(yè)務層：該層指標反映出Service的質量,如一個訂單系統(tǒng)的下單成功率
• 應用層：該層指標反映出應用軟件的運行狀態(tài),如Nginx連接數(shù)
• 系統(tǒng)層：該層指標反映出操作系統(tǒng)的運行狀態(tài),如平均負載
• 硬件層：該層指標反映出硬件設備的運行狀態(tài),如CPU溫度

通過分層,我們將問題分類在我們熟知的范圍內.

建立服務樹模型

重點是：“服務” 和 “模塊”

• 模塊：提供某種功能的服務器的組合,屬于同一個模塊中的服務器功能一樣.如“緩存模塊“,”DB模塊“.
• 服務：由多個模塊組織在一起提供一種Service,“服務”是對“功能”的一個更高層的抽象.如”訂單拆分服務“.

這兩個概念的定義,為下面的模塊調用關系奠定了基礎.

建立模塊調用關系

大寫字母代表”服務“,如A服務；小寫字母代表”模塊“,如a模塊；箭頭代表調用或者結果返回關系

建立”統(tǒng)一事件庫“

我們認為有如下幾種確定事件之間關系的方法

1. 上面的模塊調用關系是一種人為定義的確定性關系.
2. 時間相關性,這是一種非確定性的策略,代表了一種相關可能性.
3. 事實相關性,通過對大批量歷史數(shù)據(jù)進行分析計算,找到事件之間事實上發(fā)生的相關性.

那么,首先我們得需要一個統(tǒng)一的“事件庫”來收集所有事件.

我們認為形成事件的來源有這么幾個

我們認為一個對象產生異常的影響因素來自于這幾個方面

1. 自身異常,如硬盤損壞
2. 依賴方異常,如A.b調用了A.c的服務,然而A.c服務異常
3. 來自外部的對其產生的變更,如開發(fā)者對A.b服務進行了代碼升級,該服務器所在交換機故障,局方機房網絡割接

對于第一點,我們只要將自身的4層指標監(jiān)控完整,就能夠做到可控的程度.

對于第二點,需要我們完整確定每個模塊的調用關系. 對于第三點,是我們尤其擔心的一點,因為我們很難收集全所有的外部事件,我們使用了如下的方法來盡量實現(xiàn)這個目標.

• 建立“通告中心”,讓人為已知的確定性變更通過這個方式發(fā)送出來,并且記錄到事件庫中.例如對A.b服務進行代碼升級.
• 通過消息隊列的Pub/Sub模型建立一個公共的事件總線,讓平臺里的每個系統(tǒng)都能夠將自己產生的重要變更通過這種松耦合的方式對外發(fā)布,對該系統(tǒng)的變更感興趣的其他系統(tǒng)就可以有選擇地抓取,如監(jiān)控系統(tǒng)可以抓取寫入事件庫.

對于事件總線這塊,我們這幾個系統(tǒng)的是這樣工作的

1. AutoBank(資源管理系統(tǒng))會將設備(服務器、交換機等)的狀態(tài)變化,附加上工單,作為一個事件記錄到自己的日志中,同時發(fā)布到事件總線里.我在2016 opsworld – 運維的數(shù)據(jù)銀行的分享中有提到,狀態(tài)的變化意味著有變更流程,有變更就有產生風險的可能.
2. AutoGear(服務管理系統(tǒng))會直接對服務器上的軟件環(huán)境產生變更,所以會將哪臺服務器上安裝了什么軟件,或者對什么軟件的參數(shù)進行了怎么樣的修改封裝成一個事件記錄到自己的日志中,同時發(fā)布到事件總線里.
3. AutoPush(代碼發(fā)布系統(tǒng))會在流程上強制要求代碼上線人必須先通過“通告中心”發(fā)布”上線通告“,這條通告會通過釘釘、郵件或者短信發(fā)送給相關人,也會錄入事件庫,然后AutoPush會嘗試讀取這條發(fā)布通告,讀到了才開啟發(fā)布窗口,發(fā)布人才能夠在頁面上進行代碼發(fā)布.發(fā)布窗口期過期后,自動鎖定AutoPush禁止發(fā)布.

故障原因定位策略

我們目前使用的策略

1. 調用鏈越尾端的模塊,越有可能是故障根本原因.
2. 監(jiān)控指標中越下層的,越有可能是故障根本原因.

根據(jù)“模塊調用關系”和“指標分層”的概念,采用遞歸的方法去遍歷所有事件,得到一個疑似故障原因診斷報告.

范例如下

“廣告服務”的接口響應時間異常(為3s),疑似原因為“索引模塊”的服務器xxx.autohome.cc磁盤util異常(為98%).

保留問題現(xiàn)場

業(yè)務層指標是直接反應出服務質量的,是最能代表用戶體驗的,所以在業(yè)務層指標異常發(fā)生的時候,我們通過SaltStack這個遠程執(zhí)行通道在服務器上執(zhí)行snapshot腳本保存當前服務器的運行狀態(tài)快照,該腳本其實是平時運維在發(fā)現(xiàn)問題后登陸服務器上執(zhí)行常規(guī)命令的一個標準化封裝,所做的事情有：

1. 保存uptime指令輸出
2. 保存CPU占用top10
3. 保存free指令輸出
4. 保存內存占用top10
5. 保存df指令輸出
6. 保存ip addr show指令輸出
7. 保存路由表
8. 保存Local DNS
9. 保存?Dig autohome.com.cn?指令輸出
10. 保存?Ping -c 3 autohome.com.cn?輸出
11. 保存TCPDUMP抓包10秒的結果
12. 等等

同時,在監(jiān)控系統(tǒng)的“最新問題”頁面,點擊“現(xiàn)場快照”,上面的信息會直接呈現(xiàn)在頁面上,并且點擊“歷史數(shù)據(jù)”,頁面上會顯示問題發(fā)生時刻前后30分鐘的歷史數(shù)據(jù)曲線,包括CPU,內存,硬盤,IO,網絡流量,等等,方便運維快速定位問題.

日志追蹤

通過ELK構建日志分析系統(tǒng),在如下兩個方面滿足故障定位的需求

1. 搜索服務器A某個時間段內的B應用程序的日志,通過上文“最新問題”頁面可以直接跳轉過來.
2. 通過TraceID搜索單個用戶請求的全流程.

四、小結

監(jiān)控系統(tǒng)的建設真是個任重道遠的活,上文只是部分實現(xiàn)了事件關聯(lián)分析的內容,下一步我們計劃在“決策推理”方面進行研發(fā),以提高定位的精準度,為后續(xù)的故障自愈打下基礎.文中有任何不妥之處,歡迎大家指出.

文章出處：運維幫(訂閱號ID：yunweibang)

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4375.html