引言

服務端問題排查(服務穩定性/基礎設施異常/業務資料不符合預期等)對於開發而言是家常便飯，問題並不可怕，但是每天都要花大量時間去處理問題會很可怕；另一方面故障的快速解決至關重要。那麼目前問題排查最大的障礙是什麼呢？我們認為有幾個原因導致：

1. 大量的告警資訊。
2. 鏈路的複雜性。
3. 排查過程繁複。
4. 依賴經驗。
   然而實際工作中的排查過程並非無跡可尋，其排查思路和手段是可以沉澱出一套經驗模型。

沉澱路徑

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

以線上常見的服務超時為例，上圖中因為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問題抖動觸發大量告警資訊，秒級給出問題發生路徑。根據診斷路徑顯示搜尋單機出現大量異常。

總結

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

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

本文作者：閒魚技術-吳白

原文連結

本文為雲棲社群原創內容，未經