本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 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 連線，而且端點必須在連線後兩秒內以 2xx 或 3xx 的 HTTP 狀態碼回應。

  Route 53 運作狀態檢查在收到 HTTP 狀態碼之後，必須在接下來的兩秒內收到來自端點的回應本文。Route 53 在回應本文中搜尋指定的字串。字串必須在回應本文的前 5,120 個位元組中完全顯示，否則端點的運作狀態檢查會失敗。如果您使用的是 Route 53 主控台，請在 **Search String (搜尋字串)** 欄位中指定字串。如果您使用的是 Route 53 API，請在建立運作狀態檢查時於 `SearchString` 元素中指定字串。

若是用來監控端點的運作狀態檢查 (除了 TCP 運作狀態檢查以外)，如果來自端點的回應包含任何標頭，則標頭必須使用 RFC7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, [section 3.2, "Header Fields"](https://tools.ietf.org/html/rfc7230#section-3.2) 中定義的格式。

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 會將新的運作狀態檢查視為*不佳*， 直到有足夠的資料。