Google Cloud 提供可設定的健康狀態檢查，適用於Google Cloud 負載平衡器後端、Cloud Service Mesh 後端 ，以及代管執行個體群組的應用程式型自動修復。本文涵蓋健康狀態檢查的重要概念。
除非另有註明，否則 Google Cloud 健康狀態檢查是由專用軟體工作實作，會根據健康狀態檢查資源中指定的參數連線至後端。每次嘗試連線的作業稱為「探測」。 Google Cloud 會記錄每次探測是成功還是失敗。
系統會根據可設定的連續探測成功或失敗次數，計算每個後端的整體健康狀態。成功回應達設定次數的後端就會視為「健康狀態良好」。在可另外設定的次數內無法成功回應的後端，就是「健康狀態不良」。
每個後端的整體健康狀態會決定其是否能接收新的要求或連線。您可以設定定義成功探測的條件。詳情請參閱「健康狀態檢查的運作方式」一節。
專用軟體工作執行的健康狀態檢查會使用虛擬私有雲 (VPC) 網路中未定義的特殊路徑。詳情請參閱「健康狀態檢查路徑」。
健康狀態檢查類別、通訊協定和通訊埠
健康狀態檢查有「類別」和「通訊協定」。這兩種類別分別是「健康狀態檢查」和「舊版健康狀態檢查」，支援的通訊協定如下：
健康狀態檢查
- 區域 (gRPC、TCP、SSL、HTTP、HTTPS 或 HTTP/2)
- 區域 gRPC (採用 TLS) (預先發布版)
- 全域 (gRPC、TCP、SSL、HTTP、HTTPS 或 HTTP/2)
- 全球 gRPC (採用 TLS) (預先發布版)
舊版健康狀態檢查：
通訊協定和通訊埠會決定健康狀態檢查探測要求的方式。舉例來說，健康狀態檢查可以使用 TCP 通訊埠 80 上的 HTTP 通訊協定，也可以針對執行個體群組中的已命名通訊埠使用 TCP 通訊協定。
您無法將舊版健康狀態檢查轉換為健康狀態檢查，反之亦然。
選取健康狀態檢查
健康狀態檢查必須與負載平衡器 (或 Cloud Service Mesh) 的類型和後端類型相容。選取健康狀態檢查時，請考量下列因素：
- 類別：健康狀態檢查或舊版健康狀態檢查。只有以目標集區為基礎的外部直通式網路負載平衡器需要舊版健康狀態檢查。其他產品則會使用一般健康狀態檢查。
- 通訊協定： Google Cloud 用來探測後端的通訊協定。 我們「強烈」建議您，在選擇健康狀態檢查 (或舊版健康狀態檢查) 時，要使用其通訊協定與負載平衡器的後端服務或目標集區所用的通訊協定相同的健康狀態檢查 (或舊版健康狀態檢查)。不過，健康狀態檢查通訊協定「不必」與負載平衡器通訊協定相同。
- 通訊埠規格：與通訊協定搭配使用的通訊埠。 Google Cloud 您必須為健康狀態檢查指定通訊埠。健康狀態檢查有兩種通訊埠規格方法：
--port和--use-serving-port。舊版健康狀態檢查提供一種方法：--port。如要進一步瞭解各負載平衡器的健康狀態檢查通訊埠規定，請參閱「通訊埠規格標記」。
下一節將說明各類負載平衡器和後端適用的健康狀態檢查選項。
負載平衡器指南
下表列出各負載平衡器類型支援的健康狀態檢查類別和範圍。
| 負載平衡器 | 健康狀態檢查類別和範圍 |
|---|---|
|
全域外部應用程式負載平衡器 傳統版應用程式負載平衡器 * 全域外部 Proxy 網路負載平衡器 傳統版 Proxy 網路負載平衡器 跨區域內部應用程式負載平衡器 跨區域內部 Proxy 網路負載平衡器 |
健康狀態檢查 (全球) |
|
區域性外部應用程式負載平衡器 區域性內部應用程式負載平衡器 區域性內部 Proxy 網路負載平衡器 區域性外部 Proxy 網路負載平衡器 |
健康狀態檢查 (區域) |
| 外部直通式網路負載平衡器 | 後端服務型負載平衡器：健康檢查 (區域性) 目標集區型負載平衡器：舊版健康狀態檢查 |
| 內部直通式網路負載平衡器 | 健康狀態檢查 (全域或 區域) |
| 負載平衡器模式 | 支援舊版健康狀態檢查 |
|---|---|
全域外部應用程式負載平衡器 傳統版應用程式負載平衡器 |
如果符合下列兩項條件，即可使用：
|
| 區域性外部應用程式負載平衡器 | 否 |
其他使用須知
如果是 VM 執行個體群組後端，健康狀態檢查只會針對已啟動的 VM 執行個體執行。已停止的 VM 執行個體不會收到健康狀態檢查封包。
針對內部直通式網路負載平衡器，您只能採用
TCP或UDP來做為後端服務的通訊協定。如果您從內部直通網路負載平衡器後方的 VM 提供 HTTP 流量，則使用 HTTP 通訊協定來執行健康狀態檢查是很合理的。以目標集區為基礎的外部直通式網路負載平衡器必須使用舊版 HTTP 健康狀態檢查。無法使用舊版 HTTPS 健康狀態檢查或任何非舊版健康狀態檢查。如果您使用以目標集區為基礎的外部直通網路負載平衡器來平衡 TCP 流量，就必須在已負載平衡的 VM 上執行 HTTP 服務，好讓這些 VM 能回應健康狀態檢查探測作業。
對於 幾乎所有其他類型的負載平衡器，您「必須」使用一般 (非舊版) 健康狀態檢查，且通訊協定須與負載平衡器的後端服務通訊協定相符。如果後端服務使用 gRPC 通訊協定，請只使用 gRPC 或 TCP 健康狀態檢查。請勿使用 HTTP(S) 或 HTTP/2 健康狀態檢查。
使用混合式 NEG 後端的特定 Envoy 負載平衡器不支援 gRPC 健康狀態檢查。詳情請參閱混合式 NEG 總覽。
使用 Cloud Service Mesh 進行健康狀態檢查
使用健康狀態檢查搭配 Cloud Service Mesh 時，請注意下列行為差異。
使用 Cloud Service Mesh 時，
INTERNET_FQDN_PORT和NON_GCP_PRIVATE_IP_PORT類型的網路端點健康狀態檢查行為，與其他類型的網路端點健康狀態檢查行為不同。Cloud Service Mesh 會透過 Envoy Proxy 執行網際網路 NEG (INTERNET_FQDN_PORT端點) 和混合式 NEG (NON_GCP_PRIVATE_IP_PORT端點) 的健康狀態檢查，而非使用專屬軟體工作。Envoy 支援下列健康狀態檢查通訊協定：
- HTTP
- HTTPS
- HTTP/2
- TCP
如果 Cloud Service Mesh 與 Service Directory 整合，且您將 Service Directory 服務繫結至 Cloud Service Mesh 後端服務，則無法在後端服務上設定健康狀態檢查。
健康狀態檢查的運作方式
下列各節說明健康狀態檢查的運作方式。
探測
建立健康狀態檢查或舊版健康狀態檢查時，您可以指定下列旗標或接受其預設值。您建立的每項健康狀態檢查或舊版健康狀態檢查，都是由多個探測實作。這些旗標可控制「每個」探測評估執行個體群組中的執行個體，或區域 NEG 中的端點的頻率。
您無法針對各個後端進行健康狀態檢查設定。健康狀態檢查會與整個後端服務建立關聯。如果是以目標集區為基礎的外部直通式網路負載平衡器，舊版 HTTP 健康狀態檢查會與整個目標集區建立關聯。因此，針對指定後端服務或目標集區參照的所有後端，探測作業的參數都是相同的。
| 設定旗標 | 用途 | 預設值 |
|---|---|---|
檢查時間間隔check-interval |
檢查時間間隔是從「某個探測器發出」一次探測作業開始，到「同一探測器發出」下一次探測作業開始之間的時間長度。單位為秒。 | 5s (5 秒) |
逾時timeout |
逾時是 Google Cloud 等待探測回應的時間長度，這個值必須小於或等於檢查時間間隔。單位為秒。 | 5s (5 秒) |
探測 IP 範圍和防火牆規則
如要讓健康狀態檢查正常運作，您必須建立 ingress allow 防火牆規則，讓 Google Cloud 探測器流量可連線至後端。如需操作說明，請參閱「建立必要的防火牆規則」。
下表列出各負載平衡器要允許的來源 IP 範圍：
| 產品 | 健康狀態檢查探測來源 IP 範圍 |
|---|---|
|
如要將 IPv6 流量傳送至後端：
|
如要將 IPv6 流量傳送至後端：
|
|
|
|
| 外部直通式網路負載平衡器 3 |
後端的 IPv4 流量：
如要將 IPv6 流量傳送至後端：
|
| 內部直通式網路負載平衡器 |
後端的 IPv4 流量：
如要將 IPv6 流量傳送至後端：
|
| Cloud Service Mesh，搭配網際網路 NEG 後端和混合型 NEG 後端 | 執行 Envoy 軟體的 VM IP 位址 如需設定範例，請參閱 Cloud Service Mesh 說明文件。 |
1 混合式 NEG 不必允許來自 Google 健康狀態檢查探測器範圍的流量。不過，如果您在單一後端服務中同時使用混合式和區域 NEG，則必須允許區域 NEG 接收來自 Google 健康狀態檢查探測範圍的流量。
2 對於區域性網際網路 NEG，健康狀態檢查為選用功能。使用區域網際網路 NEG 的負載平衡器流量，會來自僅限 Proxy 的子網路，然後透過 Cloud NAT 轉譯為 NAT IP 位址 (手動或自動分配)。這類流量包括健康狀態檢查探測，以及負載平衡器傳送至後端的使用者要求。詳情請參閱「區域性 NEG：使用 Cloud NAT 閘道」。
3 以目標集區為基礎的外部直通式網路負載平衡器僅支援 IPv4 流量，且可能會透過中繼資料伺服器 Proxy 健康狀態檢查。在這種情況下，健康狀態檢查封包來源會與中繼資料伺服器的 IP 位址 (169.254.169.254) 相符。您不必建立防火牆規則，允許來自中繼資料伺服器的流量。來自中繼資料伺服器的封包一律允許。
探測 IP 範圍的安全性考量
規劃健康狀態檢查和必要防火牆規則時，請注意下列資訊：
探查 IP 範圍屬於 Google。 Google Cloud 會使用虛擬私有雲網路外部但 Google 實際工作環境網路內部的特殊路徑，在健康狀態檢查探查器與後端 VM 之間進行通訊。
探查 IP 範圍僅供 Google 的實際工作環境網路用於健康狀態檢查和負載平衡。 Google Cloud Google 的實際工作環境網路會強制執行下列事項，防止探查 IP 範圍用於任何其他用途：
如果封包從探查 IP 範圍偽造來源 IP 位址，Google 邊緣路由器會捨棄來自網際網路的封包。
您無法在虛擬私有雲網路的子網路中使用探測 IP 範圍。詳情請參閱「禁止使用的 IPv4 子網路範圍」和「IPv6 規格」。
防火牆規則的重要性
Google Cloud ，您必須建立必要的輸入allow防火牆規則，允許探測器傳送流量至後端：
探查 IP 範圍是探查器Google Cloud 可能使用的完整 IP 位址集。如果您使用
tcpdump或類似工具，可能無法觀察所有探測 IP 範圍中所有 IP 位址的流量。最佳做法是建立輸入防火牆規則，允許所有探測 IP 範圍做為來源。 Google Cloud 可以自動實作新的探測器，且不會另行通知。最佳做法是只允許健康狀態檢查使用的通訊協定和通訊埠。
如果沒有允許健康狀態檢查的輸入 allow 防火牆規則，默示 deny 輸入規則就會封鎖連入流量。如果探測器無法與後端聯絡，負載平衡器會將後端視為健康狀態不良。
多重探測和頻率
Google Cloud 會從多個備援系統 (稱為探測器) 傳送健康狀態檢查探測。探測器會使用特定來源 IP 範圍。 Google Cloud 不會只依賴一個探測器來執行健康狀態檢查，而是由多個探測器同時評估執行個體群組後端中的執行個體，或區域 NEG 後端中的端點。如果探測器失敗，Google Cloud 會繼續追蹤後端健康狀態。
您為健康狀態檢查設定的時間間隔和逾時設定，會套用於所有探測器。對於指定的後端，軟體存取記錄檔和 tcpdump 顯示的探測會比您的設定更頻繁。
這是意料中的行為，您無法設定 Google Cloud 用於健康狀態檢查的探測器數量。不過，您可以考慮下列因素，估計多個同步探測作業的效果。
如要預估每個後端服務的探測頻率，請考慮下列事項：
每個後端服務的基本頻率。每個健康狀態檢查都有一個關聯的檢查頻率，與設定的檢查時間間隔成反比：
1⁄(檢查時間間隔)
將健康狀態檢查與後端服務相關聯時，就會建立每個探測器用於該後端服務上後端的基本頻率。
探針縮放比例係數。後端服務的基本頻率乘以 Google Cloud 同時使用的探測器數量。這個數字可能不盡相同，但通常介於 5 到 10 之間。
內部直通式網路負載平衡器的多個轉送規則。如果您設定了多個指向同一地區內部後端服務的內部轉送規則 (各有不同的 IP 位址)，則Google Cloud 會使用多個探測器檢查每個 IP 位址。每個後端服務的探測頻率乘以設定的轉送規則數量。
外部直通式網路負載平衡器的多個轉送規則。如果您設定了多個指向同一後端服務或目標集區的轉送規則， Google Cloud 就會使用多個探測器檢查每個 IP 位址。每個後端 VM 的探測頻率乘以設定的轉送規則數量。
外部應用程式負載平衡器的多個目標 Proxy。 如果您有多個目標 Proxy 將流量導向同一網址對應， Google Cloud 會使用多個探測器檢查與每個目標 Proxy 相關聯的 IP 位址。每個後端服務的探測頻率乘以設定的目標 Proxy 數量。
外部 Proxy 網路負載平衡器和區域內部 Proxy 網路負載平衡器可使用多個目標 Proxy。如果您設定了多個目標 Proxy，將流量導向同一個後端服務，Google Cloud 會使用多個探測器檢查與每個目標 Proxy 相關聯的 IP 位址。每個後端服務的探測頻率乘以設定的目標 Proxy 數量。
後端服務總和。如果後端由多個後端服務使用，系統與後端執行個體連線的頻率，等於每個後端服務的健康狀態檢查頻率總和。
如果使用區域 NEG 後端，就很難確定健康狀態檢查探測的確切數量。舉例來說，同一個端點可以在多個區域 NEG 中。這些區域 NEG 不一定擁有相同的一組端點，而且不同的端點可以指向同一個後端。
探查封包的目的地
下表列出健康狀態檢查探測器傳送封包的網路介面和目的地 IP 位址，視負載平衡器類型而定。
如果是外部直通式網路負載平衡器和內部直通式網路負載平衡器，應用程式必須繫結至負載平衡器的 IP 位址 (或任何 IP 位址 0.0.0.0)。
| 負載平衡器 | 目的地網路介面 | 目的地 IP 位址 |
|---|---|---|
|
|
|
|
|
|
| 外部直通式網路負載平衡器 | 主要網路介面 (nic0) |
外部轉送規則的 IP 位址。 如果多個轉送規則都指向相同的後端服務 (如果是以目標集區為基礎的外部直通式網路負載平衡器，則為相同的目標集區)， Google Cloud 就會將探測作業傳送至各個轉送規則的 IP 位址。這可能會導致探測次數增加。 |
| 內部直通式網路負載平衡器 | 對於執行個體群組後端和具有 GCE_VM_IP 端點的區域 NEG 後端，使用的網路介面取決於後端服務的設定方式。詳情請參閱後端服務和網路介面。 |
內部轉送規則的 IP 位址。 如果多個轉送規則都指向相同的後端服務， Google Cloud就會將探測作業傳送至各個轉送規則的 IP 位址。這可能會導致探測次數增加。 |
HTTP、HTTPS 和 HTTP/2 的成功標準
HTTP、HTTPS 和 HTTP/2 健康狀態檢查一律需要在健康狀態檢查逾時前收到 HTTP 200 (OK) 回應碼。其他所有 HTTP 回應代碼 (包括 301 和 302 等重新導向回應代碼) 都會視為不正常。
除了需要 HTTP 200 (OK) 回應代碼外，您還可以：
設定各個健康狀態檢查探測器，將 HTTP 要求傳送至特定要求路徑，而非預設要求路徑
/。設定每個健康狀態檢查探測器，檢查 HTTP 回應主體中是否有預期的回應字串。預期的回應字串只能包含單一位元組的可列印 ASCII 字元，且位於 HTTP 回應主體的前 1,024 個位元組內。
下表列出適用於 HTTP、HTTPS 和 HTTP/2 健康狀態檢查的要求路徑和回應旗標有效組合。
| 設定旗標 | 探測器行為 | 成功標準 |
|---|---|---|
未指定 --request-path 和 --response
|
探測器會使用 / 做為要求路徑。 |
僅限 HTTP 200 (OK) 回應代碼。 |
同時指定 --request-path 和 --response
|
探測器會使用設定的要求路徑。 | HTTP 200 (OK) 回應碼和 HTTP 回應內文的前 1,024 個 ASCII 字元，都必須與預期的回應字串相符。 |
僅指定 --response
|
探測器會使用 / 做為要求路徑。 |
HTTP 200 (OK) 回應碼和 HTTP 回應內文的前 1,024 個 ASCII 字元，都必須與預期的回應字串相符。 |
僅指定 --request-path
|
探測器會使用設定的要求路徑。 | 僅限 HTTP 200 (OK) 回應代碼。 |
SSL 和 TCP 的成功標準
TCP 和 SSL 健康狀態檢查有下列基本成功標準：
如果是 TCP 健康狀態檢查，健康狀態檢查探測器必須在健康狀態檢查逾時前，成功開啟與後端的 TCP 連線。
如果是 SSL 健康狀態檢查，健康狀態檢查探測器必須成功開啟與後端的 TCP 連線並完成 TLS/SSL 交握，才能在健康狀態檢查逾時前完成檢查。
如果是 TCP 健康狀態檢查，必須透過下列其中一種方式關閉 TCP 連線：
- 健康狀態檢查探測器傳送 FIN 或 RST (重設) 封包，或
- 後端傳送 FIN 封包。如果後端傳送 TCP RST 封包，且健康狀態檢查探測器已傳送 FIN 封包，則探測可能會視為失敗。
下表列出適用於 TCP 和 SSL 健康狀態檢查的要求和回應旗標有效組合。要求和回應旗標都只能包含單一位元組的可列印 ASCII 字元，且每個字串的長度不得超過 1,024 個字元。
| 設定旗標 | 探測器行為 | 成功標準 |
|---|---|---|
未指定 --request 或 --response
|
探測器不會傳送任何要求字串。 | 僅限基本成功標準。 |
同時指定 --request 和 --response
|
探測器會傳送設定的要求字串。 | 基本成功條件和探測器收到的回應字串必須與預期的回應字串完全相符。 |
僅指定 --response
|
探測器不會傳送任何要求字串。 | 基本成功條件和探測器收到的回應字串必須與預期的回應字串完全相符。 |
僅指定 --request
|
探測器會傳送設定的要求字串。 | 僅限基本成功條件 (不會檢查任何回應字串)。 |
gRPC 的成功標準
gRPC 健康狀態檢查僅適用於 gRPC 應用程式、 Google Cloud 負載平衡器和 Cloud Service Mesh。 Google Cloud 支援兩種類型的 gRPC 健康狀態檢查：
GRPC_WITH_TLS(搶先版) 健康狀態檢查用於檢查已啟用 TLS 的 gRPC 後端健康狀態。這些健康狀態檢查支援未經驗證的 TLS 加密，因此不會驗證伺服器身分。GRPC健康狀態檢查用於檢查不安全的 gRPC 後端。這些憑證不支援驗證和加密，因此無法用於啟用 TLS 的 gRPC 後端。
如果您使用 gRPC 健康狀態檢查 (無論是否採用 TLS)，請確認 gRPC 服務會傳送 RPC 回應，其中包含 OK 狀態，且狀態欄位會相應設為 SERVING 或 NOT_SERVING。
如要瞭解詳情，請參考下列資源：
舊版健康狀態檢查的成功標準
如果舊版健康狀態檢查探測器收到的回應為 HTTP 200 OK，則探測器會視為成功。所有其他 HTTP 回應代碼 (包括重新導向 (301、302)) 都視為不正常。
健康狀態
Google Cloud 會使用下列設定旗標，判斷每個負載平衡後端的整體健康狀態。
| 設定旗標 | 用途 | 預設值 |
|---|---|---|
良好健康狀態判定門檻healthy-threshold |
良好健康狀態判定門檻會指定探測結果連續成功次數，據此將先前健康狀態不良的後端認定為健康狀態良好。 | 探測門檻值為 2。 |
不良健康狀態判定門檻unhealthy-threshold |
不良健康狀態判定門檻會指定探測結果連續失敗次數，據此將先前健康狀態良好的後端認定為健康狀態不良。 | 探測門檻值為 2。 |
Google Cloud 會在符合這個健康狀態判定門檻後，將後端視為健康狀態良好。健康狀態良好的後端就可以接收新的連線。
如果達到不良健康狀態判定門檻，Google Cloud 會將後端認定為健康狀態不良。健康狀態不良的後端將無法接收新的連線，但現有的連線「不會」立即終止。連線會一直保持開啟，直到發生逾時或流量中斷為止。
現有連線可能無法傳回回應，具體取決於導致探測失敗的原因。如果健康狀態不良的後端重新達到健康狀態判定門檻，就會是健康狀態良好的後端。
當所有後端都處於異常狀態時，具體行為會因使用的負載平衡器類型而有不同：
| 負載平衡器 | 所有後端運作狀態皆不良時的行為 |
|---|---|
| 傳統版應用程式負載平衡器 | 如果所有後端健康狀態都不良，則會向用戶端傳回 HTTP `502` 狀態碼。 |
|
全域外部應用程式負載平衡器 跨區域內部應用程式負載平衡器 區域性外部應用程式負載平衡器 區域性內部應用程式負載平衡器 |
如果所有後端健康狀態都不良，則會向用戶端傳回 HTTP `503` 狀態碼。 |
| Proxy 網路負載平衡器 | 在所有後端健康狀態不良時，終止新的用戶端 TCP 連線。 |
| 內部直通式網路負載平衡器 後端服務型外部直通式網路負載平衡器 |
根據容錯移轉設定、後端權重和後端健康狀態，分配新的連線。詳情請參閱： |
| 目標集區型外部直通式網路負載平衡器 | 將流量分配至所有後端 VM，這是所有後端健康狀態不良時最不得已的做法。 |
其他注意事項
以下各節提供在 Google Cloud上使用健康檢查的其他注意事項。
憑證和健康狀態檢查
Google Cloud 健康狀態檢查探測器不會執行憑證驗證，即使通訊協定要求後端使用憑證 (SSL、HTTPS 和 HTTP/2) 也是如此，例如：
- 您可以使用自行簽署的憑證，也可以使用任何憑證授權單位 (CA) 簽署的憑證。
- 我們接受過期或尚未生效的憑證。
CN和subjectAlternativeName屬性都不需要與Host標頭或 DNS PTR 記錄相符。
標頭
使用任何通訊協定的健康狀態檢查 (舊版健康狀態檢查除外)，都可讓您使用 --proxy-header 標記設定 Proxy 標頭。
使用 HTTP、HTTPS 或 HTTP/2 通訊協定的健康狀態檢查和舊版健康狀態檢查，都允許您使用 --host 標記指定 HTTP Host 標頭。
如果您使用任何自訂要求標頭，請注意，負載平衡器只會將這些標頭新增至用戶端要求，不會新增至健康狀態檢查探針。如果後端需要授權專用的標頭，但健康狀態檢查封包中缺少該標頭，健康狀態檢查可能會失敗。
健康狀態檢查範例
假設您設定的健康狀態檢查如下：
- 間隔：30 秒
- 逾時：5 秒
- 通訊協定：HTTP
- 不良健康狀態判定門檻：2 (預設)
- 健康狀態良好的判定門檻：2 (預設)
採用這些設定後，健康狀態檢查的行為如下：
- 多個備援系統會同時設定健康狀態檢查參數。時間間隔和逾時設定會套用至每個系統。詳情請參閱多個探測器和頻率。
每個健康狀態檢查探測器都會執行下列動作：
如果至少有一個健康狀態檢查探測系統執行下列動作，後端就會被視為健康狀態不良：
- 連續兩次探測作業都未收到
HTTP 200 (OK)回應代碼。舉例來說，連線可能遭到拒絕，或是連線或通訊端逾時。 - 連續收到兩則不符合通訊協定專屬成功條件的回覆。
- 連續兩次探測作業都未收到
如果至少有一個健康狀態檢查探測系統收到兩個連續回應，且符合通訊協定專屬的成功條件，後端就會視為健康狀態良好。
在本範例中，每個探測器每 30 秒會啟動一次連線。無論逾時時間長度為何 (連線是否逾時)，探測器嘗試連線之間都會間隔 30 秒。換句話說，逾時時間長度必須一律小於或等於時間間隔，且逾時時間長度絕不會增加時間間隔。
在本例中，每個探測器的時間軸如下 (以秒為單位)：
- t=0：開始探測 A。
- t=5：停止探測器 A。
- t=30：開始探測 B。
- t=35：停止探測 B。
- t=60：開始探測 C。
- t=65：停止探查 C。