本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 对单实例区域资源进行故障检测
<a name="failure-detection-of-single-instance-zonal-resources"></a>

在某些情况下，您可能拥有区域资源的单个活动实例，最常见的系统需要单写器组件，例如关系数据库（例如 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)视为违例。这有助于您了解资源是否停止报告数据，并且可以包含在以前使用的*连续*和 *M（最大为 N）*警报中。

在某些表明资源运行状况的指标中，也有可能在没有活动时发布一个值为零的数据点。如果损坏情况阻碍了与资源的交互，那么您无法对这类指标使用缺失数据方法。您可能也不希望在值为零时发出警报，因为在某些合法场景中，该值可能在正常阈值之内。检测此类问题的最佳方法是使用此依赖项由资源生成指标。在本例中，我们希望使用复合警报来检测*多个*可用区域的影响。这些警报应使用与资源相关的几个关键指标类别。下面列出了几个例子：
+  **吞吐量** – 传入工作单元的速率。这可能是事务、读取、写入等。
+  **可用性** – 衡量成功与失败的工作单元的数量。
+  **延迟** – 测量跨关键操作成功执行工作的延迟的多个百分位数。

   同样，您可以为要衡量的每个指标类别中的每个指标创建*连续*和 *M（最大为 N）*指标警报。和以前一样，这些警报可以合并成一个复合警报，以确定此共享资源是各个可用区的影响来源。您希望能够使用复合警报发现对多个可用区的影响，但影响不一定波及*所有*可用区。这种方法的复合警报的高级结构如下图所示。  
![\[该图显示了创建警报来检测单个资源对多个可用区造成影响的示例\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)

您会注意到，此图表对应使用哪种类型的指标警报以及复合警报的层次结构的规定较少。这是因为发现此类问题可能很困难，并且需要仔细注意共享资源的正确信号。可能还需要以特定的方式评估这些信号。

此外，您应该注意到该 `primary-database-impact` 警报并未与特定可用区关联。这是因为主数据库实例可以位于其配置为使用的任何可用区中，并且没有一个 CloudWatch指标可以指定其位置。当您看到此警报已激活时，应将其用作资源可能存在问题的信号，并启动失效转移到另一个可用区（如果尚未自动执行）。将资源转移到另一个可用区后，您可以稍等一下，看看隔离的可用区警报是否已激活，也可以选择先发制人，调用您的可用区撤离计划。