Kong（V1.0.2） Health Checks and Circuit Breakers Reference

介紹

您可讓Kong代理的API使用ring-balancer，經過添加包含一個或多個目標實體的 upstream 實體進行配置，每一個 target指向不一樣的IP地址(或主機名)和端口。ring-balancer將在各類目標之間負載，並基於上游對目標執行健康檢查，使它們不管是否響應都是健康的或不健康的。而後，ring-balancer 只會將流量路由到健康的目標。

Kong有兩種健康檢查方法，可分別或同時使用:

• active checks主動檢查，其中按期請求目標中的特定HTTP或HTTPS端點，並根據其響應肯定目標的健康狀態;
• passive checks被動檢查(也稱爲斷路器)，Kong在其中分析正在代理的流量，並根據目標的行爲響應請求來肯定目標的健康情況。

健康與不健康目標

健康檢查功能的目標是爲給定的Kong節點動態地將目標標記爲健康或不健康。沒有集羣範圍內的健康信息同步:每一個Kong節點分別決定其目標的健康。這是可取的,由於某個Kong節點能夠鏈接到一個目標,但另外一個Kong節點未必能鏈接該目標:第一個節點將考慮它健康,而另外一個將其標記爲不健康的，將請求路由到其餘目標（健康）。

主動探測(在主動健康檢查上)或代理請求(在被動健康檢查上)都會生成用於肯定目標是否健康的數據。請求可能會產生TCP錯誤、超時或HTTP狀態代碼。基於此信息，健康檢查器更新一系列內部計數器:

• 若是返回的狀態碼是配置爲「健康」的狀態碼，將增長目標的「success」計數器，並清除其全部其餘計數器;
• 若是鏈接失敗，則增長目標的「TCP failure」計數器，清除「success」計數器;
• 若是超時，將增長目標的「超時」計數器，清除「成功」計數器;
• 若是返回的狀態代碼被配置爲「不健康」，它將增長目標的「HTTP故障」計數器，並清除「成功」計數器。

若是任何「TCP失敗」、「HTTP失敗」或「超時」計數器達到其配置的閾值，目標將被標記爲不健康。

若是「成功」計數器達到其配置的閾值，則將目標標記爲健康。

HTTP狀態碼爲「健康」或「不健康」的列表，而且每一個計數器的獨立閾值能夠在每一個上游的基礎上進行配置。下面，咱們有一個上游實體的配置示例，展現了用於配置健康檢查的各類字段的默認值。每一個字段的描述包含在Admin API 參考文檔中。

{ "name": "service.v1.xyz", "healthchecks": { "active": { "concurrency": 10, "healthy": { "http_statuses": [ 200, 302 ], "interval": 0, "successes": 0 }, "http_path": "/", "timeout": 1, "unhealthy": { "http_failures": 0, "http_statuses": [ 429, 404, 500, 501, 502, 503, 504, 505 ], "interval": 0, "tcp_failures": 0, "timeouts": 0 } }, "passive": { "healthy": { "http_statuses": [ 200, 201, 202, 203, 204, 205, 206, 207, 208, 226, 300, 301, 302, 303, 304, 305, 306, 307, 308 ], "successes": 0 }, "unhealthy": { "http_failures": 0, "http_statuses": [ 429, 500, 503 ], "tcp_failures": 0, "timeouts": 0 } } }, "slots": 10 }

若是上游的全部目標都不健康，Kong將返回503 Service Unavailable。

注意:

1. 健康檢查僅對活動目標進行操做，不修改Kong數據庫中目標的活動狀態。
2. 不健康的目標不會從負載均衡器中刪除，所以在使用哈希算法時不會對均衡器佈局產生任何影響(它們將被跳過)。
3. DNS caveats and balancer caveats也適用於健康檢查。若是對目標使用主機名，那麼請確保DNS服務器始終返回名稱的完整IP地址集，而且不限制響應。若是不這樣作，可能會致使不執行健康檢查。

Types of health checks

Active health checks

正如其名稱所暗示的那樣，主動健康檢查會主動探測其健康的目標。當上遊實體中啓用活動健康狀態檢查時，Kong將按期向上遊每一個目標的配置路徑發出HTTP或HTTPS請求。這容許Kong根據探測結果probe results自動啓用和禁用均衡器中的目標。

活動健康檢查的週期能夠針對目標的健康或不健康狀況單獨配置。若是任意一個的間隔值設置爲0，則在相應的場景中禁用檢查。當二者都爲零時，活動健康檢查將徹底禁用。

注意:活動健康檢查目前只支持HTTP/HTTPS目標。它們不適用於將協議屬性設置爲「tcp」或「tls」的服務的上行流。

Passive health checks (circuit breakers)

被動健康檢查，也稱爲斷路器，是根據Kong代理的請求(HTTP/HTTPS/TCP)執行的檢查，不生成額外的流量。當目標變得無響應時，被動健康檢查器將檢測到該狀況並將該目標標記爲不健康。戒指均衡器將開始跳過這個目標，因此不會有更多的流量被路由到它。

一旦目標的問題獲得解決，並準備再次接收流量，Kong管理員能夠經過Admin API 端點手動通知健康檢查程序應該再次啓用目標，以下：

curl -i -X POST http://localhost:8001/upstreams/my_upstream/targets/10.1.2.3:1234/healthy
HTTP/1.1 204 No Content

此命令將廣播一個集羣範圍的消息，以便將「健康」狀態傳播到整個Kong集羣。這將致使Kong節點重置在Kong節點的全部worker中運行的health checkers的健康計數器，從而容許ring-balancer再次將流量路由到目標。

被動健康檢查的優勢是不會產生額外的流量，可是它們沒法自動將目標再次標記爲健康:「circuit is broken」，須要系統管理員從新啓用目標。

Summary of pros and cons

• 主動健康檢查能夠自動從新啓用ring-balancer中的目標，只要它再次健康。被動的健康檢查不能。
• 被動健康檢查不會給目標帶來額外的流量。而主動健康檢查會產生。
• 主動健康檢查程序要求將目標中具備可靠狀態響應的已知URL配置爲探測端點(能夠簡單到「/」)。被動健康檢查不須要這樣的配置。
• 經過爲主動健康檢查器提供自定義探針端點，應用程序能夠肯定本身的健康指標，並生成供Kong使用的狀態代碼。即便目標繼續爲在被動健康檢查器看來健康的流量提供服務，它也可以以失敗狀態響應主動探測，本質上是請求從接受新流量中解脫出來。

把這兩種模式結合起來是可能的。例如，能夠啓用被動健康檢查，僅根據其流量監視目標健康情況，並在目標不健康時才使用主動健康檢查，以便自動從新啓用它。

Enabling and disabling health checks啓用和禁用健康檢查

Enabling active health checks啓用積極的健康檢查

要啓用活動健康檢查，須要指定healthchecks.active下的配置項，該配置項在Upstream object中處於活動狀態。您須要指定必要的信息，以便Kong可以對目標執行按期探測，以及如何解釋結果信息。

你可使用healthchecks.active.type屬性以指定是執行HTTP仍是HTTPS探測(將其設置爲「HTTP」或「HTTPS」)，還能夠經過簡單的測試可否鏈接給定主機和端口的(將其設置爲「tcp」)來指定。

要配置探測，您須要指定:

• healthchecks.active.http_path - 向目標發出HTTP GET請求時應該使用的路徑。默認值是「/」。
• healthchecks.active.timeout -  探測的HTTP GET請求的鏈接超時限制。默認值是1秒。
• healthchecks.active.concurrency - 在活動健康檢查中要併發檢查的目標數量。

您還須要爲運行探測的間隔指定正值:

• healthchecks.active.healthy.interval -對健康目標的活動健康檢查之間的間隔(以秒爲單位)。值爲0表示不該該對健康目標執行主動探測。
• healthchecks.active.unhealthy.interval - 活動健康檢查不健康目標之間的間隔(秒)。值爲0表示不該該對不健康的目標執行活動探測。

這容許您調整活動健康檢查的行爲，不管您但願健康和不健康目標的探測以相同的間隔運行，仍是但願一個比另外一個更頻繁。

若是使用HTTPS healthcheck，還能夠指定如下字段:

• healthchecks.active.https_verify_certificate - 在使用HTTPS執行活動健康檢查時，是否檢查遠程主機的SSL證書的有效性。
• healthchecks.active.https_sni - 使用HTTPS執行活動健康狀態檢查時用做SNI(服務器名標識)的主機名。當使用IPs配置目標時，這尤爲有用，這樣目標主機的證書就能夠用適當的SNI進行驗證。

注意，失敗的TLS驗證將增長「TCP失敗」計數器;「HTTP失敗」僅指HTTP狀態代碼，不管探測是經過HTTP仍是HTTPS完成的。

最後，您須要配置Kong應該如何解釋探測，方法是在health counters上設置各類閾值，一旦達到閾值將觸發狀態更改。反閾值字段爲:

• healthchecks.active.healthy.successes - 活動探測(由healthcheck .active.health .http_statuses定義)中考慮目標是否健康的成功次數。
• healthchecks.active.unhealthy.tcp_failures - 活動探測中認爲目標不健康的TCP失敗或TLS驗證失敗的次數。
• healthchecks.active.unhealthy.timeouts - 活動探測中認爲目標不健康的超時次數。
• healthchecks.active.unhealthy.http_failures - 活動探測(由healthcheck .active.unhealth .http_statuses定義)中考慮目標不健康的HTTP失敗次數。

Enabling passive health checks

被動健康檢查沒有探測功能，由於它們經過分析來自目標流量來工做。這意味着，要啓用被動檢查，您只須要配置其計數器閾值:

• healthchecks.passive.healthy.successes - 代理流量中的成功次數(由healthcheck .passive.health .http_statuses定義)，以考慮目標的健康，如被動健康檢查所觀察到的。當啓用被動檢查時，這須要爲正數，以便正常的流量重置不健康的計數器。
• healthchecks.passive.unhealthy.tcp_failures - 被動健康檢查所觀察到的，代理流量中認爲目標不健康的TCP失敗次數。
• healthchecks.passive.unhealthy.timeouts -經過被動健康檢查觀察到，代理通訊流中認爲目標不健康的超時次數。
• healthchecks.passive.unhealthy.http_failures -代理的流量(由healthchecks.passive.unhealthy.http_statuses定義)中HTTP失敗的數量，以考慮目標不健康，如被動健康檢查所觀察到的。

Disabling health checks

在healthcheck配置中指定的全部計數器閾值和間隔中，將值設置爲0意味着禁用該字段所表示的功能。將探測間隔設置爲0將禁用探測。一樣，您能夠經過將某些類型的檢查的計數器閾值設置爲零來禁用它們。例如，要在執行healthcheck時不考慮超時，能夠將兩個超時字段(用於主動和被動檢查)都設置爲零。這爲您提供了對健康檢查器行爲的細粒度控制。

總之，要徹底禁用上游的活動健康檢查，您須要將healthcheck .active.health .interval和healthcheck .active.unhealth .interval都設置爲0。

要徹底禁用被動健康檢查，須要在healthcheck下設置全部計數器閾值。被動使其各類計數器爲零。

healthcheck中的全部計數器閾值和間隔默認爲零，這意味着在新建立的上行流中，默認狀況下徹底禁用健康檢查。