微服務架構談（6）：從監控到故障定位

衆所周知，trace 架構基本都源自 Google Dapper。  

下圖爲高德在基於 trace 基礎上做的場景應用，比如服務狀態自我診斷、監控追溯等。

上圖爲支付寶 app 通過無線網關的 trace 示意圖，包括應用鏈路，文件存儲。應用鏈路包括 rpc 調用和消息服務。《分佈式服務框架》一書，林峯特別對服務調用鏈價值進行了彙總，體現了對於不同角色，服務調用鏈路跟蹤的價值所在。

開發：

架構優化

消除不合理依賴

性能優化

還可以補充容量評測、設計變更分析等

測試：

識別調用流程

優化測試用例

關鍵路徑覆蓋率

還可以補充自動化端到端測試

運維：

故障定界

故障定位

提前預警

七、不能承受之重：監控

7.1 監控預警的疑難問題

監控最大的問題是消息很多，我來不及看。漏報傷不起，誤報也很煩，說不想半夜三更好好的睡睡覺。總結監控預警的疑難問題，大致可以分爲幾類：

報警多到沒朋友、長期容易懈怠

對於固定閾值的報警，沒有可調適性，可以形成動態閾值方案，在動態閾值上限、下限範圍內都屬於業務正常。

Service 耗時在不斷的增加，一直到瀕臨臨界點爆發。採取常規固定閾值或者同環比的監控，比較難發現問題。

對於上圖，綠色線爲觀測時間，通過變點檢測方法，相比傳統閾值報警發現時間可以做一定的提前。

週期性波動導致的誤報或漏報

週日和工作時間的業務規模，用戶影響業務模型有差別，亦可通過動態閾值方案來儘量減少誤報，規避漏報。週期性可以分爲幾種：按日、按周、按月、按工作日等方式，需要針對不同業務定義不同的預警方式。通過多次優化可以總結出如下預警閾值的優化方法：
7.2 智能定位問題
基於知識經驗的定位

顧名思義，基於知識經驗的定位是把人肉經驗固化的一種方法。特點是見效快，特別是歷史出過的問題，而且可以舉一反三，分門別類。確定是檢測代碼的維護問題，隨着系統變更，調用鏈路和依賴存儲的變化，檢測代碼需要做同步變更。另外，此方案對於發現完全陌生類型的問題，收效存疑。

如上圖所示，其實質是關聯指標法。比如，發現點擊率下降，可以從人工經驗總結的影響 ctr 波動的系統內部（模型、算法、索引、數據等）指標入手，依次檢測是否正常。此類方法，可以描述成一棵可追溯的樹，層次深入。

基於有監督算法的定位

系統風險的發現和定位屬於異常檢測（Anomaly Detection）的範疇，在該領域通常有監督模型法 (SupervisedModel)、聚類模型法(Unsupervised Model)、近鄰法(Nearest Neighbor)、統計法(Statistical)、信息論(Information Theory) 和譜理論 (Spectral Theory) 等。一般來說，標註數據的獲取是一大難題，所以半監督、無監督的算法在這類場景中大量使用，而我們利用故障注入得到種子標註數據，再通過對種子問題做同類擴展，得到大量標註樣本，然後基於樣本構建分類模型，預測每次系統調用的風險，對有問題的調用進行報警，並結合調用參數、系統變更數據對根因進行定位。我們將智能定位問題分爲兩步實現：1、檢測問題；2、定位問題。這裏展開一下檢測問題，定位問題的解法後面專文敘述。

評估智能檢測系統的發現問題的效果一般採用 “系統風險覆蓋率和誤報率”。因爲缺乏標註數據，這兩個指標一直是很難度量的，我們利用故障注入平臺的能力設計了有監督綜合模型將其分解爲 4 個階段來實現定量評估：1、歷史故障；2、同類延伸歷史故障；3、覆蓋用例庫可能出現的故障及其延伸；4、有創造性的智能延伸故障。整體上，業務通過接入故障注入平臺和精細化故障檢測平臺，使業務具備常態化進攻和防守的“左右互搏” 的能力，常態化、週期性拿到系統在風險敞口的指標，輔助或在一些場景幫助業務作出最優決策。

上圖描述了攻防結合的反饋與優化閉環，精細化智能檢測平臺作爲防守方，涉及故障延伸方法的設計、有監督綜合模型的設計、週期性演練效果的計算三個重要步驟，下面我以某故障爲實例來具體說明：

某故障由於業務規則配置出錯，引起業務量下降導致，從數據上看，表現爲返回參數與正常請求相比有明顯缺失，比如：

顯然，異常系統調用在參數維度 3 上有所體現。通過故障注入，我們便可以拿到歷史故障數據，但是如果僅僅使用這些樣本進行訓練，檢測系統也只能覆蓋歷史出現過的故障，極大的限制了系統的檢測範圍，所以我們將歷史故障數據作爲種子，在上面進行同類故障問題數據的擴展。

8.1 Chaos Principle

Build a Hypothesis around Steady State Behavior：把系統當成黑盒，chaos 專注在系統 does work，而不是儘量驗證它如何工作。 例如當故障或某一個狀態發生到恢復期間，系統的吞吐量，錯誤率，延時分佈等。

Automate Experiments to Run Continuously：chaos 工程師通過手工的故障演練不可持續，因此構建自動化演練的機制。

8.2 故障注入

結合 chaos principle 不難得到結論，由於分佈式系統把 fail 作爲” 常態” 對待，不能等到出現問題採取解決它，應該通過練兵的方式做演習，而演習的目標要做到儘量可重複、安全、接近真實。

故障注入的方式之一通過服務路由來想辦法，比如通過 Filter 模式對於路由進行處理。下圖簡單示意了通過隔離服務路由，導入測試流量到演練機的一般方法。

如上圖所示，系統 A>B>C，系統 A 調用 B，B 調用 C。假設選定對應集羣中 A Monkey、B Monkey、C Monkey 爲測試機，則測試流量進入的時候通過服務路由中設置路由到正確的測試機；而正常流量會按照常規配置的路由策略路由到比如 A-1-30.xxzone 等其他機器中。

目前筆者所見的注入故障分類大致覆蓋調用 / 負載變化、單機服務器故障（比如磁盤、cpu full、內存 full 等）、下游故障（DB 響應變慢、下游返回失敗結果等）。

8.3 常態化演練

分佈式系統有一個不成文的原則，就是面向 fail 設計。任何系統、任何資源都可能不可用，要考慮不可用的異常發生時，對應的解決方案。比如 ebay 的架構原則就有一條，Remember Everything Fails。

在大型互聯網站點的架構師心中都形成了一些共識，比如 Remember Everything Fails、AutomateEverything。如何做到呢？我們可以把 Remember Everything Fails 分爲三個階段：

常態化演練的基本動作包括演練計劃、執行場景 case 注入、觀測、故障止血、總結改進等。常態化也包括一些突襲演練，採用紅藍軍攻防對抗模式，不僅僅模擬系統表現、也是對整體的應急響應處置流程包括組織流程的檢驗。

**總結：**分佈式服務化，服務和存儲拆分都還算容易，但會對基礎設施和技能有更高的要求。如林昊所說，能不服務化的儘量不服務化；無數前輩也告誡過，能不用分佈式事務的儘量不用。一入江湖，不得回頭。隨着業務規模化的發展，在服務治理上需要下的功夫愈走向精細化。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651045275&idx=1&sn=4e8b3e6b43e8234881af4de8ac272040&chksm=8c4c689fbb3be189915ac2b1cc621d4e585fa9835fe26fc2a574383705f8915adef5fc742bbb&scene=178&cur_album_id=1343963749467717633#rd

猜你喜歡