作者介紹

團隊介紹

我們是汽車之家運維團隊，是汽車之家技術部裡最為核心的團隊，由op和dev共同組成。我們的目標是為汽車之家集團打造一個高效能，高可擴充套件，低成本，並且穩定可靠的網站基礎設施平臺。 團隊技術部落格地址為 http://autohomeops.corpautohome.com

一、前言

在《汽車之家監控系統的第一次里程碑》](http://autohomeops.corpautohome.com/articles/汽車之家監控系統的第一次里程碑/)之後，我們實現瞭如下幾個小Feature

1. URL監控
2. 日誌監控，並且在告警資訊中帶上錯誤日誌片段

而後，我們又希望能夠實現所謂的“自動故障定位”，來提升問題診斷的效率。

二、思路

我們認為，一個異常問題的發生，必定是有一個或者多個原因導致的，我們用“事件(Event)”來描述這個異常。網站的QPS增大超預期是一個事件，後端介面響應時間變大超預期是一個事件，伺服器的CPU-Load增大超預期是一個事件，有人對MySQL伺服器進行了配置變更是一個事件，有人進行了一次業務程式碼釋出也是一個事件，找出這些事件之間的關係是實現故障定位的關鍵。

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

1. 事件關聯分析
2. 決策樹自動推理

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

三、方案

監控指標分類

為了方便進行分析定位，我們對所有采集的監控指標進行了分類

解釋

• 業務層：該層指標反映出Service的質量，如一個訂單系統的下單成功率
• 應用層：該層指標反映出應用軟體的執行狀態，如Nginx連線數
• 系統層：該層指標反映出作業系統的執行狀態，如平均負載
• 硬體層：該層指標反映出硬體裝置的執行狀態，如CPU溫度

通過分層，我們將問題分類在我們熟知的範圍內。

建立服務樹模型

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

• 模組：提供某種功能的伺服器的組合，屬於同一個模組中的伺服器功能一樣。如“快取模組“，”DB模組“。
• 服務：由多個模組組織在一起提供一種Service，“服務”是對“功能”的一個更高層的抽象。如”訂單拆分服務“。

這兩個概念的定義，為下面的模組呼叫關係奠定了基礎。

建立模組呼叫關係

大寫字母代表”服務“，如A服務；小寫字母代表”模組“，如a模組；箭頭代表呼叫或者結果返回關係

建立”統一事件庫“

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

1. 上面的模組呼叫關係是一種人為定義的確定性關係。
2. 時間相關性，這是一種非確定性的策略，代表了一種相關可能性。
3. 事實相關性，通過對大批量歷史資料進行分析計算，找到事件之間事實上發生的相關性。

那麼，首先我們得需要一個統一的“事件庫”來收集所有事件。

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

我們認為一個物件產生異常的影響因素來自於這幾個方面

1. 自身異常，如硬碟損壞
2. 依賴方異常，如A.b呼叫了A.c的服務，然而A.c服務異常
3. 來自外部的對其產生的變更，如開發者對A.b服務進行了程式碼升級，該伺服器所在交換機故障，局方機房網路割接

對於第一點，我們只要將自身的4層指標監控完整，就能夠做到可控的程度。

對於第二點，需要我們完整確定每個模組的呼叫關係。 對於第三點，是我們尤其擔心的一點，因為我們很難收集全所有的外部事件，我們使用瞭如下的方法來儘量實現這個目標。

• 建立“通告中心”，讓人為已知的確定性變更通過這個方式傳送出來，並且記錄到事件庫中。例如對A.b服務進行程式碼升級。
• 通過訊息佇列的Pub/Sub模型建立一個公共的事件匯流排，讓平臺裡的每個系統都能夠將自己產生的重要變更通過這種鬆耦合的方式對外發布，對該系統的變更感興趣的其他系統就可以有選擇地抓取，如監控系統可以抓取寫入事件庫。

對於事件匯流排這塊，我們這幾個系統的是這樣工作的

1. AutoBank(資源管理系統)會將裝置（伺服器、交換機等）的狀態變化，附加上工單，作為一個事件記錄到自己的日誌中，同時釋出到事件匯流排裡。我在2016 opsworld – 運維的資料銀行的分享中有提到，狀態的變化意味著有變更流程，有變更就有產生風險的可能。
2. AutoGear(服務管理系統)會直接對伺服器上的軟體環境產生變更，所以會將哪臺伺服器上安裝了什麼軟體，或者對什麼軟體的引數進行了怎麼樣的修改封裝成一個事件記錄到自己的日誌中，同時釋出到事件匯流排裡。
3. AutoPush(程式碼釋出系統)會在流程上強制要求程式碼上線人必須先通過“通告中心”釋出”上線通告“，這條通告會通過釘釘、郵件或者簡訊傳送給相關人，也會錄入事件庫，然後AutoPush會嘗試讀取這條釋出通告，讀到了才開啟發布視窗，釋出人才能夠在頁面上進行程式碼釋出。釋出視窗期過期後，自動鎖定AutoPush禁止釋出。

故障原因定位策略

我們目前使用的策略

1. 呼叫鏈越尾端的模組，越有可能是故障根本原因。
2. 監控指標中越下層的，越有可能是故障根本原因。

根據“模組呼叫關係”和“指標分層”的概念，採用遞迴的方法去遍歷所有事件，得到一個疑似故障原因診斷報告。

範例如下

“廣告服務”的介面響應時間異常(為3s)，疑似原因為“索引模組”的伺服器xxx.autohome.cc磁碟util異常(為98%)。

保留問題現場

業務層指標是直接反應出服務質量的，是最能代表使用者體驗的，所以在業務層指標異常發生的時候，我們通過SaltStack這個遠端執行通道在伺服器上執行snapshot指令碼儲存當前伺服器的執行狀態快照，該指令碼其實是平時運維在發現問題後登陸伺服器上執行常規命令的一個標準化封裝，所做的事情有：

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. 等等

同時，在監控系統的“最新問題”頁面，點選“現場快照”，上面的資訊會直接呈現在頁面上，並且點選“歷史資料”，頁面上會顯示問題發生時刻前後30分鐘的歷史資料曲線，包括CPU，記憶體，硬碟，IO，網路流量，等等，方便運維快速定位問題。

日誌追蹤

通過ELK構建日誌分析系統，在如下兩個方面滿足故障定位的需求

1. 搜尋伺服器A某個時間段內的B應用程式的日誌，通過上文“最新問題”頁面可以直接跳轉過來。
2. 通過TraceID搜尋單個使用者請求的全流程。

四、小結

監控系統的建設真是個任重道遠的活，上文只是部分實現了事件關聯分析的內容，下一步我們計劃在“決策推理”方面進行研發，以提高定位的精準度，為後續的故障自愈打下基礎。文中有任何不妥之處，歡迎大家指出。

文章出處：運維幫（訂閱號ID：yunweibang）