神探產品定位

線上 問題的 發生往往會帶來兩個影響： 一 是大量的 時間投 入 ，二 是低效率 解決問題導 致的 用戶體驗和公司 利益 的持續 受損。因此無論從業務穩定性還是業務的快速開發迭代出發，都需要提高底層效率，提高問題定位能力，使開發人員注入更多的精力在開發和業務本身。

神探系統應運而生，神探是一款面向服務端穩定性問題自動定位並輔助快速解決故障的線上排查工具。

神探目標

神探圍繞四大指標解決線上故障問題，分別爲：

• 準 - 定位準確率不亞於開發人員。

• 快 - 系統目標定位結果要早於監控發現。

• 簡單 - 沉澱出從問題發現到定位結果之間，最短的鏈路，儘可能縮減定位時間和定位成本。

• 自動化 - 神探系統的開發旨在解放人力，全程不需要開發人員參與。自動定位到具體鏈路環節，打通告警、預警、故障鏈路

競品分析

爲響應故障報警最快解決，集團內部很多團隊都在做故障定位系統，這裏對常見的解法做簡單介紹。

• 基於專家經驗的決策樹模式目前最成熟，做的最多的方案是基於專家經驗，對以往排查路徑進行沉澱收斂，以決策樹模型進行上鑽下鑽分析。但這種模型具有先天的缺陷，即專家經驗的真實性、時效性、體系化等方面的欠考量。神探系統區別於傳統決策樹模型，將專家經驗沉澱轉化爲一種分析範式，通用性、擴展性方面表現良好。

• 基於監控平臺優化/基於報警信息部分團隊故障定位是基於監控平臺做優化，調整閾值使之成爲高敏感度監控平臺，帶來的問題是大量無效報警。基於報警信息的模式本質上，發現故障要晚於監控報警，神探可做到故障定位早於報警信息，對系統安全方面，具有更高價值。

• 基於機器學習的根因下鑽算法這種方案，特色在於上下游調用以及因果關係影響是通過嚴謹的邏輯關係證明而來，比常見的推測法更具說服力，因此，這種方案准確率高達95%以上。其因果關係下鑽分析使用KMeans等機器學習算法給出最佳波動組合。這種方案模型複雜，必須依靠強大的分佈式時序數據庫來保證系統的快速查詢能力，且採用全鏈路數據成本高。神探也是基於邏輯證明去推測因果關係，因果邏輯算法部分與此係統互爲補充。

閒魚整體架構

神探實現原理

線上環境中，全面瞭解應用運行狀況，需要：

• 掌控上下級調用關係鏈路中所有入口服務的【耗時、狀態】

• 掌控每個入口服務關聯資源的【耗時、狀態】

針對以上問題排查思路並非無跡可尋，其排查思路和手段可以沉澱出一套經驗模型。將故障簡單歸結爲【慢調用】和【異常】，根據日常排查思路可以總結出以下分析範式：

上圖範式模型，使用完備的數據埋點體系，可以很清晰的做到：準確界定慢調用/異常；生成上下游調用鏈路；本身和下游準確界定是誰的問題；下游異常時準確區分線程池滿、超時、未捕獲異常。除此之外，系統設計模型還滿足以下兩點：

• 模型覆蓋線上複雜多變的場景。包括流量波動、發佈波動、機器問題、代碼異常、依賴異常等；區分可容忍異常和不可容忍異常；兼容異常一直上報導致請求直接失敗退出的場景；兼容異常在底層被吞掉，請求不會失敗，但會導致業務異常的場景。

• 模型是易於擴展的。可以實時根據要求將經驗添加到模型之中

整體結構圖

本系統做到從告警/預警/故障->定位->快速處理這樣一套完美閉環，自上而下分爲數據採集、實時計算、實時分析、聚合展示四大模塊。神探採用決策樹模型來進行故障分析定位，通過對排查思路的歸納總結將決策樹體系化成一套通用範式。

模型基於決策樹機制實現，整個系統中模型原子節點抽象爲：

• 監控對象：即關注的監控實體抽象，例如，某個服務、一個主機、數據庫、jvm實例、中間件服務、日誌、網絡等，監控對象之間存在關聯關係。

• 指標：指監控對象本身攜帶的監控特徵，例如，系統負載（Load）、CPU利用率、內存使用率、網絡I/O、磁盤利用率、服務是否超時、日誌特點。

• 規則：指構建決策邏輯的最小單位，由指標和邏輯組成。

• 知識庫：指專家經驗的總結沉澱，即系統最終異常的根因分析。

決策樹推理過程可以總結爲：

• 監控數據實時採集聚合，存儲統計數據到TSDB

• 根據要定位的對象找到決策樹根節點

• 判斷當前決策樹節點對應規則是否滿足

• 判斷規則遊走路徑，下鑽到下一個決策節點

• 如果是知識庫則輸出

具體推理過程自下而上，可以由採集數據拿到具體異常監控指標值，最終通過上下游調用關係，聚合成拓撲鏈路，直觀顯示故障位置，如下圖所示。

範式異常情況擴 展——多方佐證分析

正常情況下，這兩個耗時由客戶端建立請求、服務端發出響應和客戶端接受響應的具體耗時簡化而來，可現實項目中，存在許多異常情況，很多場景下我們不能完全取到這三個指標，我們將採用多方佐證來輔助給出定位結果。場景舉例：

• 多方佐證是針對數據丟失來校準診斷，數據丟失情況經過系統羅列，也可以總結出一套分析模型，以tddl爲例，當DB庫出現問題，會有部分等待排隊耗時埋點丟失，服務端耗時丟失時，下鑽分析當前節點有沒有明確的客戶端耗時，若存在大量客戶端耗時高事件，則判斷是當前節點問題，若沒有，則判斷是依賴方問題。

釘釘鏈路打通，告警鏈路實時定位

• 神探目前針對日常故障/問題排查，定位時間可以達到5s以內。

• 與告警以及預警平臺進行打通，做到監控和預警出來的故障、異常能夠秒級定位到根因。

• 神探具備下游依賴、DB、容器（CPU、LOAD、線程池滿）、單機異常、多原因綜合定位，滿足日常絕大部分故障、日常定位需求。

實際案例

XXXX年X月XX日全站交易下跌超過20%，閒魚也受影響。 報警羣“閒魚-發佈”，“閒魚-留言”等多接口下跌，神探系統秒級定位*異常導致閒魚多個服務受到影響，繼而第一時間對*進行了降級。

發現路徑(最短路徑): 打通告警信息,告警羣出告警後,可直接點擊卡片,打開診斷頁面

日常單機問題排查，解決人工排查難區分單機還是集羣問題。例如， 搜索單機問題(11.15.. 這臺機器)導致首頁接口異常,直接定位到如下結果。

故障定位結果提供快恢預案，保駕故障快速恢復。

系統優化展望

神探系統目前已經穩定運行，主要聚焦服務穩定性相關問題定位，仍然有許多場景未覆蓋，要實現問題定位->隔離->降級->快速恢復完整閉環，還需要更完備的底層數據建設、完備的事件抽象、以及將事件關聯起來的知識圖譜。

數據成本控制

• 問題描述：海量數據問題——線上埋點數據可達80G/分鐘，多租戶模式匹配後帶來成本指數增長問題，數據成本問題優化需要保證埋點定位準確度不變的前提下，優化數據存儲。

• 數據清洗方案：【粗過濾】基於自定義的閾值過濾規則

• 神探支持粗過濾場景。自定義閾值過濾規則是基於某些中間件服務調用，例如，RPC、MQ、數據庫訪問、緩存等，可以明確規定出響應時間 > x ms =>異常響應的場景，可以高效率進行數據過濾。

• 數據清洗方案：【自動化閾值】基於自動化閾值維護的清洗規則

• 自動化閾值維護是根據前N-1個正常閾值，經過嚴謹的邏輯計算得來。維護規則根據數據規模有所不同，N取太大，則對第N個閾值影響微乎其微，所以N的選擇根據系統數據規模得出。

• 自動化閾值理論上計算強依賴於前段時間正常的響應波動，目前採用動態均值算法，定義如下：

系統拓展至端

• 神探系統接下來會接入終端數據，包括移動端APP，H5，PC端等，將系統拓展至端可以覆蓋更全面的異常場景，例如，流量下跌/流量突漲，神探使用上鑽分析，將現有拓撲進一步上鑽補全，構造完整鏈路，端上流量彙集到故障入口，根據端上數據監控，可以明確給出：

• 具體哪個端流量波動？

• 端上哪個接口抖動？是否進行限流？

• APP/PC端流量波動原因？是大促？還是異常？

• 流量波動對本系統的整體影響鏈路？

多租戶擴展

• 神探未來將會接入除閒魚外的其他應用，做到多租戶擴展，發展成爲適用性強的一款故障定位工具。

豐富DB指標

• 神探目前針對DB抖動，只能定位到IP以及請求方IP，覆蓋指標不夠豐富。未來我們會接入新的數據源，接入DB庫的監控信息，豐富定位指標，降低之前慢調用因信息不全而多方佐證帶來的一定概率誤差。DB庫監控數據接入，將有效關聯數據打通串聯，快速應用到神探。DB監控數據的接入將豐富我們指標監控：

• 可定位到故障機房

• 可定位到故障IP，請求方IP，對數據丟失鏈路進行佐證定位

• 可定位到故障具體數據庫

• 可定位到故障具體表