本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 異地同步備份可觀測
若要能夠在與單一可用區域隔離的事件期間撤除可用區域，您首先必須能夠偵測到故障實際上是隔離到單一可用區域。這需要對系統在每個可用區域中的行為進行高保真度能見度。許多 AWS 服務提供的 out-of-the-box 指標可提供有關您資源的營運見解。例如，Amazon EC2 提供了許多指標，例如CPU使用率、磁碟讀取和寫入以及網路流量進出。
不過，當您建置使用這些服務的工作負載時，您需要的不僅僅是標準指標，還需要更多的可見性。您想要瞭解工作負載所提供的客戶體驗。此外，您還需要將指標與產生指標的可用區域保持一致。這是您需要檢測差異觀察灰色故障的洞察力。該級別的可見性需要儀器。
儀器需要編寫明確的代碼。此代碼應該執行諸如記錄任務需要多長時間，計算成功或失敗的項目數量，收集有關請求的元數據等等。您還需要提前定義閾值，以定義什麼被認為是正常的，什麼是不正常的。您應該概述工作負載中延遲、可用性和錯誤計數的目標和不同嚴重性閾值。Amazon 建置者程式庫文章[檢測分散式系統以獲得操作可見性，提供了許多最佳實](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)務。
指標都應該從服務器端以及客戶端生成。產生用戶端指標和瞭解客戶體驗的最佳做法是使用 [Can](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) ary，該軟體會定期探測您的工作負載並記錄指標。
除了生成這些指標之外，您還需要了解它們的上下文。執行此操作的一種方法是使用[維度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)。維度會為量度提供唯一的身分，並協助說明指標告訴您的內容。對於用來識別工作負載失敗的指標 (例如延遲、可用性或錯誤計數)，您需要使用符合[錯誤隔離界限](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)的維度。
例如，如果您使用 [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC) Web 架構在一個區域中跨多個可用區域執行 Web 服務，則應使用`Region`、、[https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)`Controller``Action`、和作`InstanceId`為維度集的維度 (如果您使用的是微服務，則可以使用服務名稱和HTTP方法而不是控制器和動作名稱)。這是因為您預期不同類型的失敗會被這些邊界隔離。您不會期望 Web 服務的代碼中存在會影響其列出產品以也影響主頁的能力的錯誤。同樣地，您也不會期望單EC2一執行個體上的完整EBS磁碟區會影響其他EC2執行個體提供您的 Web 內容。「可用區域 ID」維度可讓您一致地識別可用區域相關影響。 AWS 帳戶您可以透過多種不同方式在工作負載中找到可用區域 ID。如需一[附錄 A — 取得可用區域識別碼](appendix-a-getting-the-availability-zone-id.md)些範例，請參閱。
雖然本文檔主要使用 Amazon EC2 作為示例中的運算資源，但`InstanceId`可以用 Amazon 彈性容器[服務（AmazonECS）和亞馬 Amazon Elastic [Kubernetes Service（Amazon](https://aws.amazon.com/eks/)EKS）運算資源的容](https://aws.amazon.com/ecs/)器 ID 替換為維度的組件。
如果您的工`Region`作負載具有區域端點 `Controller` `Action``AZ-ID`，您的金絲雀也可以在指標中使用、和作為維度。在這種情況下，請調整您的金絲雀，以便在他們正在測試的可用區域中運行。這樣可確保如果隔離的可用區域事件影響正在執行初期測試的可用區域，則不會記錄使其正在測試的不同可用區域的指標看起來不健康。例如，您的初期測試可以使用其區域名稱來測試 Network Load Balancer (NLB) 或應用程式負載平衡器 (ALB) 後面的服務的每個[區域DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)端點。
![\[顯示在 CloudWatch Synthetics 上運行的金絲雀或測試每個區域端點的 AWS Lambda 函數的圖 NLB\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
透過使用這些維度產生指標，您可以建立 [Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)，以便在這些邊界內發生可用性或延遲變更時通知您。您也可以使用[儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)快速分析該資料。為了有效地使用指標和日誌，Amazon CloudWatch 提供了[嵌入式指標格式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF)，可讓您將自訂指標與日誌資料內嵌。 CloudWatch自動提取自定義指標，以便您可以對其進行可視化和警報。 AWS 為不同的程式設計語言提供數個[用戶端程式庫](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html)，讓您輕鬆開始使用EMF。它們可以與 AmazonEC2，AmazonECS，Amazon EKS 和現場部署環境一起使用。[AWS Lambda](https://aws.amazon.com/lambda/)透過將指標嵌入日誌中，您也可以使用 [Amazon CloudWatch 貢獻者深入解析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)來建立顯示參與者資料的時間序列圖表。在這種情況下，我們可以顯示按維度分組的數據 `AZ-ID``InstanceId`，或`Controller`以及日誌中的任何其他字段類似`SuccessLatency`或`HttpResponseCode`。
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
此記錄有三組維度。它們會以精細度順序進行，從執行個體到可用區域再到區域 (`Controller`此範例一律包含在此範例中)。`Action`它們支援在整個工作負載中建立警示，以指出何時會影響單一執行個體、單一可用區域或整個執行個體中的特定控制器動作 AWS 區域。這些維度用於 2xx、3xx、4xx 和 5xx HTTP 回應量度的計數，以及成功要求量度的延遲 (如果要求失敗，也會記錄失敗要求延遲的量度)。記錄檔也會記錄其他資訊，例如HTTP路徑、要求者的來源 IP，以及此要求是否需要重新整理本機快取。然後，可以使用這些資料點來計算每個API工作負載提供的可用性和延遲時間。
**使用可用性測量結果的HTTP回應代碼的注意事項**
通常情況下，您可以將 2xx 和 3xx 響應視為成功，5xx 作為故障。4xx 響應代碼落在中間的某個地方。通常，它們是由於客戶端錯誤而產生的。也許一個參數超出範圍，導致 [400 響應](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)，或者他們正在請求不存在的東西，導致 404 響應。您不會根據工作負載的可用性來計算這些回應。但是，這也可能是軟件中出現錯誤的結果。
例如，如果您引入了更嚴格的輸入驗證來拒絕之前會成功的要求，則 400 個回應可能會視為可用性下降。或者，也許您正在限制客戶並返回 429 響應。雖然節流客戶可以保護您的服務以維持其可用性，但從客戶的角度來看，該服務無法用於處理其請求。您需要決定 4xx 回應碼是否為可用性計算的一部分。
雖然本節概述了用 CloudWatch 作收集和分析指標的一種方法，但這不是您可以使用的唯一解決方案。您也可以選擇將指標傳送至適用於 Prometheus 和 Amazon 受管的 Grafana (Amazon DynamoDB 表) 的亞馬遜受管服務，或使用第三方監控解決方案。關鍵在於您的工作負載產生的指標必須包含有關工作負載故障隔離界限的內容。
如果工作負載產生維度與錯誤隔離界限一致，您可以建立可檢測可用區域隔離故障的觀察性。下列各節說明三種免費方法，用於偵測單一可用區域的損害所產生的故障。
**Topics**
+ [使用 CloudWatch 複合式警報偵測故障](failure-detection-with-cloudwatch-composite-alarms.md)
+ [使用離群值偵測進行故障偵測](failure-detection-using-outlier-detection.md)
+ [單一執行個體區域資源的故障偵測](failure-detection-of-single-instance-zonal-resources.md)
+ [Summary](summary.md)
# 使用 CloudWatch 複合式警報偵測故障
在 CloudWatch 量度中，每個維度集都是唯一的量度，您可以在每個維度集上建立 CloudWatch 警示。然後，您可以建立 [Amazon CloudWatch 複合警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)來彙總這些指標。
為了準確偵測撞擊，本 paper 中的範例將針對其 CloudWatch 警示的每個尺寸集使用兩種不同的警報結構。每個警報都會使用一分鐘的**期間**，表示每分鐘評估一次量度。第一種方法是通過將「**評估期**」和「數據點」設置為「**警報**」設置為三個來使用連續三個違規數據點，這意味著總共三分鐘的影響。第二種方法將使用「M out N」，當五分鐘視窗中的任何 3 個資料點違反時，方法是將「**評估期間**」設定為 5，將「資**料點設定為警示」設定為 3。**這提供了檢測恆定信號以及在短時間內波動的信號的能力。此處包含的時間持續時間和數據點數量是一個建議，請使用對您的工作負載有意義的值。
## 偵測單一可用區域中的影響
使用此建構，考慮使用`Controller`、`Action``InstanceId``AZ-ID`、和作`Region`為維度的工作負載。工作負載有兩個控制器：產品和首頁，以及每個控制器一個動作、清單和索引分別。它在區域中的三個可用區`us-east-1`域中運作。您可以針對每個可用區域的可用性`Controller`和`Action`組合建立兩個警示，以及每個可用區域的兩個延遲警示。然後，您可以選擇為每個警報和組合建立可用性的複`Controller``Action`合警示。最後，您會建立複合警示，彙總可用區域的所有可用性警示。對於單一可用區域`use1-az1`，使用每個`Controller`和`Action`組合的選用複合警示 (與可用區`use1-az3`域也會存在類似的警示`use1-az2`，但不會顯示為簡單起見)，如下圖所示。
![\[顯示可用性的複合警報結構的圖表 use1-az1\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
您也可以針對延遲建立類似的警示結構，如下圖所示。
![\[顯示延遲的複合警報結構的圖 use1-az1\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
對於本節的其餘數字，只有`az1-availability`和`az1-latency`複合警報會顯示在頂層。對於工作負載的任何部分`az1-latency`，這些複合警示`az1-availability`和，將告訴您是否可用性低於或延遲超過特定可用區域中定義的閾值。您也可以考慮測量輸送量，以偵測可防止單一可用區域中的工作負載接收工作的影響。您也可以將金絲雀發出的指標產生的警報集成到這些複合警報中。如此一來，如果伺服器端或用戶端看到可用性或延遲的影響，警示就會建立警示。
## 確保影響不是區域
另一組複合警報可用於確保只有隔離的可用區域事件才會啟動警示。這是透過確保可用區域複合警示處於`ALARM`狀態，而其他可用區域的複合警示處於`OK`狀態來執行。這將導致您使用的每個可用區域產生一個複合警報。下圖顯示了一個範例 (請記住，和、、、和中`use1-az2`有延遲和可用性的警示 `use1-az3` `az2-latency` `az2-availability` `az3-latency``az3-availability`，這些警示並未顯示為簡單起見)。
![\[顯示複合警報結構的圖表，用於偵測與單一 AZ 隔離的衝擊\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## 確保影響不是由單一執行個體造成
單一執行個體 (或整體叢集的一小部分) 可能會對可用性和延遲指標造成不成比例的影響，這些指標可能會使整個可用區域看起來受到影響，但事實上並非如此。與撤除可用區域相比，移除單一有問題的執行個體更快速且有效。
執行個體和容器通常會被視為暫時資源，通常會被等服務取代。[AWS Auto Scaling](https://aws.amazon.com/autoscaling/)每次建立新執行個體時都很難建立新 CloudWatch 警示 (但當然可以使用 [Amazon EventBridge 或 Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) [Auto Scaling 生命週期勾](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)點)。相反，您可以使用[CloudWatch 參與者見解](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)來識別可用性和延遲指標的貢獻者數量。
例如，對於 HTTP Web 應用程式，您可以建立規則，以識別每個可用區域中 5xx HTTP 回應的主要貢獻者。這將識別哪些執行個體導致可用性下降 (上面定義的可用性指標是由存在 5xx 錯誤驅動)。使用記EMF錄範例，使用的索引鍵建立規則`InstanceId`。然後，按`HttpResponseCode`字段過濾日誌。此範例是`use1-az1`可用區域的規則。
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch 也可以根據這些規則來創建警報。您可以使用度量數學和具有[量度的`INSIGHT_RULE_METRIC`函數](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)，根據參與者見解規則建立警示。`UniqueContributors`除了可用性，您還可以使用延遲或錯誤計數等指標的 CloudWatch 警示來建立其他「參與者見解」規則。這些警示可與隔離的可用區域影響複合警示搭配使用，以確保單一執行個體不會啟動警示。見解規則的量度`use1-az1`可能如下所示：
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
當此量度大於臨界值時，您可以定義警示；例如，本範例為 2。當 5xx 回應的獨特貢獻者超過該閾值時，就會啟動此功能，表示影響來自兩個以上的執行個體。此警報使用大於比較而不是小於的原因是為了確保唯一貢獻者的零值不會引發警報。這告訴您，影響*不*是來自單一執行個體。針對您的個別工作負載調整此閾值。一般指南是將此數字設定為可用區域中總資源的 5% 或更多。在足夠的樣本數量下，超過 5％ 的資源受到影響顯著表現出統計顯著性。
## 整合練習
下圖顯示單一可用區域的完整複合警示結構：
![\[顯示用於確定單一可用區衝擊的完整複合警報結構圖\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
當指示隔離可用區域對延遲或可用性造成的影響的複合警示處於`ALARM`狀態，`use1-az1-aggregate-alarm`以及根據該可用區域的 Contributor Insights 規則的警示也處於`ALARM`狀態 (表示影響超過單一執行個體) 時，會啟動最終複合警示。`use1-az1-isolated-impact` `not-single-instance-use1-az1`您可以為工作負載使用的每個可用區域建立此警示堆疊。
您可以在此最終警報上附加 [Amazon 簡單通知服務](https://aws.amazon.com/sns/)（AmazonSNS）警報。所有先前的警報都是在沒有動作的情況下設定的。該警報可以通過電子郵件通知操作員開始手動調查。它也可以啟動自動化以撤離可用區域。但是，請注意樓宇自動化以響應這些警報。在可用區域撤離發生之後，結果應該是緩解提高的錯誤率，並且警示會回到`OK`狀態。如果其他可用區域發生影響，則自動化可能會撤除第二個或第三個可用區域，進而可能會移除工作負載的所有可用容量。在採取任何行動之前，自動化應檢查是否已執行疏散。在疏散成功之前，您可能還需要擴展其他可用區域中的資源。
當您將新的控制器或動作添加到 MVC Web 應用程序，或新的微服務或一般情況下，要單獨監視的任何其他功能時，只需要在此設置中修改一些警報即可。您將為該新功能建立新的可用性和延遲警示，然後將這些警示新增至適當的可用性區域對齊可用性和延遲複合警示，以`az1-latency`及我們`az1-availability`在此處使用的範例中。其餘的複合警報在配置完成後仍保持靜態。這使得使用此方法的新功能成為更簡單的過程。
# 使用離群值偵測進行故障偵測
當您在多個可用區域中看到由於*不相*關原因而發生的錯誤率提高時，可能會出現與先前方法的一個差距。假設您有跨三個可用區域部署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 指標警示，並更新複合警示階層中的下一層以包含這些警示。警報結構的其餘部分保持靜態。
# 單一執行個體區域資源的故障偵測
在某些情況下，您可能擁有區域資源的單一作用中執行個體，通常需要單一寫入器元件的系統，例如關聯式資料庫 (例如 AmazonRDS) 或分散式快取 (例如 [Amazon ElastiCache (Redis OSS](https://aws.amazon.com/elasticache/redis/)))。如果單一可用區域減損影響主要資源所在的可用區域，則可能會對存取資源的每個可用區域造成影響。這可能會導致每個可用區域超過可用性閾值，這表示第一種方法無法正確識別單一可用區域的影響來源。此外，您可能會在每個可用區域看到類似的錯誤率，這表示異常值分析也不會偵測到問題。這意味著您需要實現其他可觀察性以專門檢測此情況。
您所關心的資源很可能會產生有關其健康狀況的指標，但在可用區域損害期間，資源可能無法提供這些指標。在這種情況下，您應該創建或更新警報以了解您何*時失明*。如果您已經監控並開啟警示的重要指標，您可以設定警示以將[遺失的資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)視為違規。這將幫助您了解資源是否停止報告數據，並且可以包含在同*一行中*，以及先前使用*的 n 個警報中的 m* 個。
也有可能在某些指示資源健康狀態的指標中，當沒有活動時，它會發佈零值資料點。如果減值阻止了與資源的交互，則不能對這些類型的指標使用缺少的數據方法。您也可能不想在值為零時發出警報，因為可能存在正常閾值之內的合法情況。檢測這種類型的問題的最佳方法是使用此依賴項的資源生成的指標。在這種情況下，我們想要使用複合警報來偵測*多個*可用區域中的影響。這些警示應使用與資源相關的少數重要指標類別。下面列出了幾個例子：
+ **輸送量** — 傳入工作單位的速率。這可能是事務，讀取，寫入等。
+ **可用性** — 測量成功與失敗工作單位的數量。
+ **延遲** — 測量多個延遲百分位數，以便在關鍵操作中成功執行的工作。
再一次，您可以為每*個要測量的度量類別中的每個量度建立連**續的 n 個量度警示和 m* 個量度警示。和以前一樣，這些可以合併為複合警報，以確定此共用資源是跨可用區域的影響來源。您希望能夠使用複合警示識別對多個可用區域的影響，但影響並不一定需要是*所有*可用區域。這種方法的高級複合報警結構如下圖所示。
![\[圖表顯示建立警示以偵測單一資源對多個可用區域的影響的範例\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
您會注意到，此圖表對於應使用哪種類型的度量警示以及複合警示的階層架構較不具規定性。這是因為發現這種問題可能很困難，並且需要仔細注意共享資源的正確信號。這些信號也可能需要以特定的方式進行評估。
此外，您應該注意到`primary-database-impact`警示與特定可用區域沒有關聯。這是因為主要資料庫執行處理可以位於設定要使用的任何可用區域中，而且沒有 CloudWatch測量結果可指定它所在的位置。當您看到此警示啟動時，您應該使用它作為資源可能有問題的信號，並啟動容錯移轉至另一個可用區域 (如果尚未自動完成)。將資源移至另一個可用區域之後，您可以等待並查看隔離的可用區域警示是否已啟動，或者您可以選擇先發製呼叫可用區域撤離計劃。
# Summary
本節說明三種協助識別單一可用區域損害的方法。每種方法都應該一起使用，以提供工作負載健康狀況的全面檢視。
CloudWatch 複合警示方法可讓您找出可用性偏差在統計學上並不顯著的問題，例如 98% (受損的可用區域)、100% 和 99.99% 的可用性，這不是由單一共用資源引起的。
離群值偵測將有助於偵測單一可用區域損傷，如果您在多個可用區域中發生不相關的錯誤，這些錯誤都超過了警示閾值。
最後，識別單一執行個體區域資源的降級有助於探索可用區域損害何時會影響跨可用區域共用的資源。
這些模式中的每一種產生的警示都可以組合到 CloudWatch 複合警示階層中，以探索單一可用區域損壞的發生時間，以及對工作負載的可用性或延遲造成影響。