本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 使用離群值偵測進行故障偵測 當您在多個可用區域中看到由於*不相*關原因而發生的錯誤率提高時，可能會出現與先前方法的一個差距。假設您有跨三個可用區域部署EC2執行個體且可用性警示閾值為 99% 的案例。然後，會發生單一可用區域損害，隔離許多執行個體，並導致該區域中的可用性降至 55%。同時，但在不同的可用區域中，單一EC2執行個體會耗盡其EBS磁碟區上的所有儲存空間，而且無法再寫入記錄檔。這會導致它開始傳回錯誤，但它仍會通過負載平衡器健康狀態檢查，因為這些檢查不會觸發要寫入的記錄檔。這會導致該可用區域中的可用性降至 98%。在此情況下，您的單一可用區域影響警示不會啟動，因為您看到多個可用區域中的可用性影響。但是，您仍然可以通過撤離受損的可用區域來減輕幾乎所有的影響。 在某些類型的工作負載中，您可能會在所有可用區域中一致地遇到錯誤，而先前的可用性指標可能沒有用處。舉個 AWS Lambda 例子。 AWS 可讓客戶建立自己的程式碼，以便在 Lambda 函數中執行。要使用該服務，您必須將代碼上傳到ZIP文件中，包括依賴關係，並定義該函數的入口點。但是有時候客戶錯了這個部分，例如，他們可能會忘記ZIP檔案中的關鍵相依性，或者在 Lambda 函數定義中輸入錯誤的方法名稱。這會導致函數無法被調用並導致錯誤。 AWS Lambda 一直看到這些錯誤，但它們並不表示任何事情都不一定是不健康的。但是，類似可用區域的損害也可能導致出現這些錯誤。 若要尋找這類雜訊中的訊號，您可以使用離群值偵測來判斷可用區域之間的錯誤數目是否存在統計上顯著的偏斜。雖然我們看到跨多個可用區域的錯誤，但是如果其中一個可用區域確實發生故障，我們預期會在該可用區域中看到與其他可用區域相比較高的錯誤率，或者可能低得多。但是多少更高或更低？ *執行此分析的其中一種方法是使用[卡方](https://en.wikipedia.org/wiki/Chi-squared_test) (2) 測試來偵測可用區域之間錯誤率的統計顯著差異 (執行[離群值偵測有許多不同的演算法](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html))。*讓我們來看看卡方測試是如何工作的。 卡方測試評估可能發生某些結果分佈的可能性。在這種情況下，我們感興趣的是在一些已定義的集合中的錯誤分佈AZs。在此範例中，若要簡化數學作業，請考慮四個可用區域。 首先，建立 *null 假*設，它定義了你認為默認結果是什麼。在此測試中，Null 假設是您預期錯誤會平均分配到每個可用區域。然後，產生*替代假設*，即錯誤未平均分佈，表示可用區域減值。現在，您可以使用指標中的數據來測試這些假設。為了達到這個目的，您將從五分鐘的視窗抽樣您的指標。假設您在該視窗中取得 1000 個已發佈的資料點，其中您會看到 100 個總錯誤。您預期在平均分佈的情況下，錯誤會在四個可用區域中每個區域中發生 25% 的時間。假設下表顯示了與您實際看到的相比，您所期望的內容。 *表 1：看到的預期與實際錯誤* | AZ | 預期 | 實際 | | --- | --- | --- | | use1-az1 | 25 | 20 | | use1-az2 | 25 | 20 | | use1-az3 | 25 | 25 | | use1-az4 | 25 | 35 | 因此，您會看到現實中的分佈不均勻。但是，您可能認為這是由於您採樣的數據點中某種程度的隨機性而發生的。有一定程度的概率，這種類型的分佈可能發生在樣本集中，並且仍然假設 null 假設是真的。這導致了以下問題：至少如此極端獲得結果的可能性是多少？ 如果該概率低於定義的閾值，則拒絕零假設。在[https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance)，此概率應為 5％ 或更低。 1 1 克拉帕羅, 羅伯特 ·M. (2007). 「意義水平」。在薩爾金德，尼爾 ·J· 測量和統計百科全書 3. 加州千橡市：SAGE出版刊物，第 889—891 頁。ISBN1-412-91611-9. 你如何計算這個結果的概率？ 您可以使用 *2 統*計信息，該統計信息提供了非常好的研究分佈，並且可以用於確定使用此公式獲得極端或更極端結果的可能性。 ![\[適用於 E i i、O 和 X 2 的公式\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png) 對於我們的例子，這會導致： ![\[使用我們的示例 E ii，O 和 X 2 的公式，得到 6 的答案。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png) 那麼，在我們的概率方面`6`意味著什麼？ 您需要查看具有適當自由度的卡方分佈。下圖顯示了針對不同自由度的數個卡方分佈。 ![\[顯示不同自由度的卡方分佈的圖形\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png) 自由度的計算方式比測試中的選擇數少一。在這種情況下，由於有四個可用區域，所以自由度為三個。然後，您想知道 *k = 3* 繪圖上 *x ≥ 6* 的曲線下面積（積分）。您也可以使用具有常用值的預先計算表來近似該值。 *表 2：卡方臨界值* | 自由度 | 概率小於臨界值 | | **0.75** | **0.90** | **0.95** | **0.99** | **0.999** | | --- | --- | --- | --- | --- | --- | --- | --- | | 1 | 1.323 | 2.706 | 3.841 | 6.635 | 10.828 | | 2 | 2.773 | 4.605 | 5.991 | 9.210 | 13.816 | | 3 | 4.108 | 6.251 | 7.815 | 11.345 | 16.266 | | 4 | 5.385 | 7.779 | 9.488 | 13.277 | 18.467 | 對於三個自由度，6 的卡方值落在 0.75 和 0.9 機率欄之間。這意味著這種分佈發生的機會大於 10％，這不低於 5％ 的閾值。因此，您接受 *Null 假設*，並判斷可用區域之間的錯誤率在統計上*沒*有顯著差異。 指標數學原生不支援執行卡方統計測試，因此您需要從運算環境 (例如 Lambda) 中 CloudWatch 收集適用的錯誤指標， CloudWatch 然後在運算環境中執行測試。您可以決定在MVC控制器/動作或個別微服務層級，或在可用區域層級執行此測試。您需要考慮可用區域的損害是否會平等地影響每個控制器/動作或微服務，或者類似DNS失敗的事情可能會對低輸送量服務造成影響，而不是在高輸送量服務中造成影響，這可能會在彙總時遮罩影響。無論是哪一種情況，都可以選取適當的維度來建立查詢。細微程度等級也會影響您建立的產生的 CloudWatch 警示。 收集指定時間範圍內每個 AZ 和控制器/動作的錯誤計數量度量。首先，將卡方測試的結果計算為 true（存在統計上顯著的偏斜）或 false（沒有，即空假設成立）。如果結果為 false，請將 0 資料點發佈至您的指標串流，以取得每個可用區域的卡方結果。如果結果為 true，請針對可用區域發佈 1 個資料點，其中的錯誤距離預期值最遠，發佈其他資料點為 0 (如需可在 Lambda 函數中使用的範[附錄 B-示例卡方計算](appendix-b-example-chi-squared-calculation.md)例程式碼，請參閱)。您可以遵循與先前可用性警示相同的方法，方法是根據 Lambda 函數產生的資料點，建立連 CloudWatch 續 3 個 CloudWatch 量度警示和 5 個指標警示中的 3 個。與前面的例子一樣，這種方法可以修改為在較短或更長的窗口中使用更多或更少的數據點。 然後，將這些警示新增至控制器與動作組合的現有可用區域可用性警示，如下圖所示。 ![\[圖顯示整合卡方統計測試與複合警報\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png) 如前所述，當您在工作負載中啟動新功能時，您只需要建立特定於該新功能的適當 CloudWatch 指標警示，並更新複合警示階層中的下一層以包含這些警示。警報結構的其餘部分保持靜態。