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

# Amazon Route 53 如何确定运行状况检查是否正常
<a name="dns-failover-determining-health-of-endpoints"></a>

Amazon Route 53 用来确定运行状况检查是否正常的方法取决于运行状况检查的类型。

## Route 53 如何确定监控端点的运行状况检查的状态
<a name="dns-failover-determining-health-of-endpoints-monitor-endpoint"></a>

Route 53 在世界各地都具有运行状况检查程序。当您创建监控端点的运行状况检查时，运行状况检查程序将开始向您指定的端点发送请求，以确定该端点是否运行良好。您可以选择 Route 53 要使用的位置，也可以指定检查之间的时间间隔：每 10 秒或每 30 秒。请注意，不同数据中心的 Route 53 运行状况检查程序不会彼此协作，因此无论您选择多久的时间间隔，都会遇到有时每秒收到多个请求、然后接下来的几秒根本没有任何运行状况检查请求的情况。

每个运行状况检查程序基于以下两个值评估端点的运行状况：
+ 响应时间。资源可能出于各种原因而响应缓慢或无法响应运行状况检查请求。例如，资源因维护而关闭，受到分布式拒绝服务 (DDoS) 攻击，或者网络已关闭。
+ 端点是否响应您指定的一系列连续运行状况检查 (失败阈值)

Route 53 将聚合运行状况检查程序中的数据并确定端点是否运行正常：
+ 如果超过 18% 的运行状况检查程序报告端点运行状况良好，则 Route 53 将认为它运行状况良好。
+ 如果 18% 或更少的运行状况检查程序报告端点运行状况良好，则 Route 53 将认为它运行状况不佳。

选择 18% 的值是为了确保位于多个区域的运行状况检查程序认为端点运行状况良好。这可以防止端点仅因为网络条件问题导致与部分运行状况检查位置隔离而被视为运行状况不佳。在未来的版本中，这个值可能会更改。

单个运行状况检查程序用于确定端点运行状况是否正常的响应时间取决于运行状况检查的类型：
+ **HTTP 和 HTTPS 运行状况检查** — Route 53 必须能够在四秒内与端点建立 TCP 连接。此外，该端点必须在连接后的两秒内用 2xx 或 3xx 的 HTTP 状态代码来响应。
**注意**  
HTTPS 运行状况检查不验证 SSL/TLS 证书，因此如果证书无效或已过期，检查也不会失败。
+ **TCP 运行状况检查** — Route 53 必须能够在十秒内与端点建立 TCP 连接。
+ **使用字符串匹配的 HTTP 和 HTTPS 运行状况检查** — 与 HTTP 和 HTTPS 运行状况检查一样，Route 53 必须能够在四秒内与端点建立 TCP 连接，并且端点必须在连接后的两秒内使用 HTTP 状态代码 2xx 或 3xx 来响应。

  Route 53 运行状况检查程序在收到 HTTP 状态代码之后，它必须在接下来的两秒内收到来自端点的响应正文。Route 53 将在响应正文中搜索您指定的字符串。该字符串必须完全显示在响应正文的前 5120 个字节中，否则端点将无法通过运行状况检查。如果您使用的是 Route 53 控制台，则需在 **Search String**（搜索字符串）字段中指定字符串。如果您使用的是 Route 53 API，则需在创建运行状况检查时在 `SearchString` 元素中指定字符串。

对于监控终端节点的运行状况检查（TCP 运行状况检查除外），如果来自终端节点的响应包含任何标头，则标头必须采用超文本传输协议 (HTTP/1.1)：消息语法和路由，[第 3.2 节 “标头](https://tools.ietf.org/html/rfc7230#section-3.2)字段” 中 RFC7230定义的格式。

Route 53 在没有足够的数据来确定实际状态、运行正常或不正常时，将新的运行状况检查视为正常。如果您选择了反转运行状况检查状态的选项，则 Route 53 在有足够的数据之前将运行状况检查视为*不正常*。

## Route 53 如何确定监控其它运行状况检查的运行状况检查的状态
<a name="dns-failover-determining-health-of-endpoints-calculated"></a>

运行状况检查可以监控其他运行状况检查的状态；此类型的运行状况检查称为*已计算的运行状况检查*。进行监控的运行状况检查是*父运行状况检查*，受监控的运行状况检查是*子运行状况检查*。一个父运行状况检查可以监控最多 255 个子运行状况检查的运行状况。以下是监控的工作原理：
+ Route 53 将视为运行状况良好的子运行状况检查的数量相加。
+ Route 53 将该数字与运行状况必须正常、否则即认为父运行状况检查的状态不良的子运行状况检查数量进行比较。

有关更多信息，请参阅[您在创建或更新运行状况检查时指定的值](health-checks-creating-values.md)中的[监控其他运行状况检查（已计算的运行状况检查）](health-checks-creating-values.md#health-checks-creating-values-calculated)。

Route 53 在没有足够的数据来确定实际状态、运行正常或不正常时，将新的运行状况检查视为正常。如果您选择了反转运行状况检查状态的选项，则 Route 53 在有足够的数据之前将运行状况检查视为*不正常*。

## Route 53 如何确定监控 CloudWatch 警报的运行状况检查的状态
<a name="dns-failover-determining-health-of-endpoints-cloudwatch"></a>

当您创建基于 CloudWatch 警报的运行状况检查时，Route 53 会监控相应警报的数据流，而不是监控警报状态。如果数据流指示告警的状态为 **OK (正常)**，则认为该运行状况检查正常。如果数据流指示状态为 **Alarm (告警)**，则认为该运行状况检查不正常。如果数据流未提供足够的信息来确定告警的状态，则运行状况检查状态将取决于 **Health check status (运行状况检查状态)** 的设置：运行状况良好、运行状况不佳或上一个已知状态。（在 Route 53 API 中，此设置为 `InsufficientDataHealthStatus`。）

Route 53 不支持跨账户 CloudWatch 警报。

**注意**  
由于 Route 53 运行状况检查监控 CloudWatch 数据流而不是CloudWatch 警报状态，因此您无法使用 CloudWatch [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html)API 操作强制更改运行状况检查的状态。

Route 53 在没有足够的数据来确定实际状态、运行正常或不正常时，将新的运行状况检查视为正常。如果您选择了反转运行状况检查状态的选项，则 Route 53 在有足够的数据之前将运行状况检查视为*不正常*。