一個系統，搞定閒魚服務端複雜問題告警-定位-快速處理

服務端問題排查對開發而言是屢見不鮮，問題並不可怕但要花大量時間去處理；另外一方面故障的快速解決相當重要。

目前問題排查最大的障礙是什麼呢？咱們認爲有如下幾個緣由：

• 大量的告警信息。
• 鏈路的複雜性。
• 排查過程繁複。
• 依賴經驗。

實際工做中的排查思路並不是無跡可尋，排查思路和手段能夠沉澱出一套經驗模型。

沉澱路徑

下面是個人訂單列表的簡單抽象，其執行過程是先拿到我買到的訂單列表。訂單列表中又用到了賣家，商品以及店鋪信息服務，每一個服務又關聯着單次請求中提供服務對應的主機信息。

以線上常見的服務超時爲例，上圖中由於 127.123.12.12 這臺機器出現異常致使商品服務超時，進而致使個人訂單列表服務超時。根據平常中排查思路能夠總結出如下分析範式：

上面這種分析範式看起來很簡單清晰，可是它首先面臨着如下問題

• 如何準確界定超時/異常。
• 上下游調用鏈路如何生成。
• 本身和下游，如何肯定誰的問題(超時&異常)。
• 下游異常時，如何區分超時/線程池滿/未知異常。

以上問題本質上是底層數據埋點問題，幸運的是阿里集團完備的數據建設使得這些問題基本都能找到很好的解決方案。有了底層數據支撐再配合上層抽象出來的這樣一套分析模型，設計並實現一套徹底自動化問題定位系統是徹底有可能的。

系統架構

咱們認爲這樣一套問題自動定位的系統必定要知足 4 個目標，這同時也是整個系統的難點所在。

• 準(定位準確率不亞於開發人員)
• 快(定位結果早於監控發現)
• 簡單(從問題發現到定位結果之間的最短鏈路)
• 自動化

圍繞着這4大目標，咱們實現了上面這樣一套完整的定位系統，實現了從告警->定位->快速處理這樣一套完整閉環。自下而上劃分爲 4 個模塊，下面講一下每一個模塊解決的問題以及其難點。

數據採集

數據採集模塊主要負責埋點數據的採集與上報，須要解決兩個問題：

• 海量數據。線上的埋點數據每時每刻都在產生，其數據量可達到 80G/ 分鐘。
• 採集時延。快做爲整個系統追求的一大目標，數據採集須要知足低時延。
• 可擴展指標。隨着模型的不斷演進完善，須要實現靈活的增長採集指標( cpu/gc/gc 耗時/線程數等)。

採用 SLS+ 自定義插件庫來實現線上流量埋點數據的採集與上報。SLS 是阿里雲研發針對日誌類數據的一站式服務，其生命週期管理( TTL )以及極低的存儲成本能夠很好的解決海量數據帶來的成本問題。

實時計算

實時計算以數據採集的輸出做爲輸入，負責對數據進行一輪預處理，包括鏈路數據的關聯(請求都有惟一標識，按照標識 group by )，數據清洗(只選取須要的數據)以及事件通知。

• 計算延時。從拿到數據到最後過濾輸出，要儘量壓縮計算延時來提高整個系統的時效性。
• 多數據源協同。數據來源於底層不一樣的數據源，他們以前對應着不一樣的到達時間，須要解決數據等待問題。
• 數據清洗。須要有必定的策略來進行一輪數據清洗，過濾出真正有效的數據，來減小計算量以及後續的存儲成本。
• 存儲成本。雖然通過了一輪數據清洗，可是隨着累積數據量仍是會線性增加。

實時分析

當收到事件通知後根據實時計算產出的有效數據進行自動化的分析，輸出問題的發生路徑圖。須要解決：

• 實時拓撲 vs. 離線拓撲。實時拓撲對埋點數據有要求，須要可以實時還原調用鏈路，但依賴採集數據的完整度。離線拓撲離線生成，不依賴採集數據的完整度，但不能準確反應當前拓撲。最後選擇了實時還原拓撲方式保證準確率。
• 數據丟失。雖然實時計算中有解決數據協同等待的問題，但沒法完全解決數據的丟失問題(數據延時過大/埋點數據丟失)，延時以及丟失數據須要採起不一樣的處理策略。
• 分析準確率。影響準確率的因素不少，主要包括數據完整度以及分析模型的完備度。

聚合展現

按照時間窗口對問題發生路徑進行實時聚合，還原問題發生時的現場。將監控，告警和診斷鏈路進行了互通，最大化的縮短從問題發現到結果展示的操做路徑。

• 實時聚合 vs. 查詢時聚合。查詢時聚合性能差可是很靈活(能夠根據不一樣的條件聚合數據),反之實時聚合犧牲了靈活性來保證查詢性能。這裏咱們選擇保證查詢性能。
• 併發問題。採用實時聚合首先要解決的是併發寫(線上集羣對同一個接口的聚合結果進行修改)。最後採起將圖拆解成原子 key，利用 redies 的線程安全特性保證線上集羣的寫併發問題。
• 存儲成本 vs. 聚合性能。爲了解決併發問題，咱們利用redis的線程安全特性來解決，但帶來的一個問題就是成本問題。分析下來會發現聚合操做通常只會跨越 2～5 個窗口，超過以後聚合結果就會穩定下來。因此能夠考慮將聚合結果持久化。

效果

系統上線以來經受住了實踐的檢驗，故障以及平常問題的定位效率獲得顯著提高，並得到了穩定性的結果。將平常問題/故障定位時間從10分鐘縮短到 5s 之內，如下是隨機選取的兩個真實 case 。

案例1：閒魚發佈受影響，監控系統發現商品發佈接口成功率下跌發出來告警信息，點擊告警診斷直接跳轉到問題現場，發現是由於安全某個服務錯誤率飆升致使，整個過程不到5s。

案例2: 首頁由於單機問題受到影響，閒魚首頁由於單機gc問題抖動觸發大量告警信息，秒級給出問題發生路徑。根據診斷路徑顯示搜索單機出現大量異常。

總結

目前整個系統主要聚焦服務穩定性相關的問題定位，仍然有許多場景有待覆蓋，信息有待補全，措施有待執行，定位只是其中的一環。最終目的必定是建設問題定位，隔離，降級，與快速恢復這樣一個完整閉環。要想實現這樣一個完整閉環，離不開底層各個子系統的數據建設，核心在於兩點一面的建設：

• 底層數據建設。完備的數據支持必定是整個系統可以發揮價值的前提，雖然現階段不少系統在產出這方面的數據，但仍然遠遠不夠。
• 完備的事件抽象。數據不只僅侷限於請求產生的埋點數據，其範圍應該更爲普遍(應用發佈，線上變動，流量波動等)，任意可能對線上形成影響的操做都應該能夠抽象成一個事件。
• 知識圖譜的創建。僅僅有完備的事件並無多大的價值，真正的價值在於把這些事件關聯起來，在問題/故障發生時第一時間還原現場，快速定位問題。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。