consul代理---健康檢測

翻譯至：https://www.consul.io/docs/agent/checks.html

代理的主要角色之一是系統級和應用級健康檢測的管理。若是健康檢查與服務相關聯，則認爲它是應用級。若是不與服務關聯，則健康檢測監視整個節點的健康情況。
健康檢測在配置文件中定義，或者在運行時經過HTTP接口添加。經過HTTP接口建立的健康檢測會在該結點進行持久化。

有五種不一樣的健康檢測：

腳本+時間間隔 - 這些檢查依賴於調用外部應用程序來執行健康情況檢查，以適當的退出代碼退出，並可能產生一些輸出。腳本與調用間隔（例如每30秒）組合使用。這與Nagios插件系統相似。腳本檢查的輸出限制爲4KB，大於4kb的輸出將被截斷。默認狀況下，腳本檢查將配置30秒的超時時間，也能夠在檢測定義時經過timeout字段來自定義腳本檢查的超時時間。當Windows達到超時時間，Consul將等待腳本產生的任何子進程完成；其餘系統一旦超時，Consul將嘗試強制終止檢測腳本和它產生的任何子進程。在Consul 0.9.0和更高版本中，代理必須配置enable_script_checksset爲true以啓用腳本檢測

HTTP +間隔 - 這些檢查每隔一個間隔（例如每隔30秒）向指定的URL發出HTTP GET請求。服務的狀態取決於HTTP響應代碼：任何2xx代碼都被視爲檢測經過，429是太多請求的警告，其餘任何狀態碼都表明檢測失敗。這種類型的檢查應該優於腳本使用curl或其餘外部進程來檢測簡單的http操做。默認狀況下，HTTP檢查是GET請求，除非method字段指定了不一樣的方法。能夠經過header字段來設置其它header字段信息，以字符串列表映射的形式設置，例如， {「x-foo」：[「bar」，「baz」]}。默認狀況下，HTTP檢查請求超時等於檢查時間間隔，最大值爲10秒，可是也能夠經過在檢查定義中配置timeout 字段來自定義HTTP檢查超時值。http檢查的輸出限制爲4KB，大於4kb的輸出將被截斷。 HTTP檢查也支持SSL。默認要求有效的SSL證書。能夠經過在檢查定義中將tls_skip_verify字段設置爲true來關閉證書驗證。

TCP +間隔 - 這種檢方式是每隔一個間隔（例如每30秒）對指定的IP /主機名和端口進行TCP鏈接嘗試。若是沒有指定主機名，則默認爲「localhost」。服務的狀態取決於鏈接嘗試是否成功（即 - 端口當前正在接受鏈接）。若是鏈接被接受，則服務的狀態是成功的，不然是失敗的。在主機名同時解析爲IPv4和IPv6地址的狀況下，將嘗試鏈接這兩個地址，而且首次成功的鏈接嘗試將致使成功的檢查。若是是簡單的套接字操做檢測內裏優先選擇這種檢測方式，默認狀況下，TCP檢查的請求超時等於檢查時間間隔，最大值爲10秒。能夠經過在檢查定義中指定timeout字段來配置自定義TCP檢查超時值。

TTL檢測 - ttl檢測會在ttl時間內保留上次的檢測狀態，檢測狀態必須經過HTTP接口按期更新，若是外部系統沒法在給定的TTL內更新狀態，則檢查設置爲失敗狀態。這個檢測機制依靠應用程序直接報告其健康情況。例如，健康的應用程序能夠按期向HTTP端點發送狀態更新;若是應用程序失敗，TTL將過時，健康檢查進入危險狀態。 TTL檢查還將其最後一次已知的狀態保存到磁盤。這容許Consul代理重啓後能夠恢復檢查的最後一個已知狀態，持久化的檢測狀態的有效期爲從上次檢查時間起到TTL結束時。

Docker+時間間隔 - 這些檢查依賴於調用Docker容器中打包的外部應用程序。應用程序經過Docker Exec API在正在運行的容器中觸發。Consul代理用戶須要訪問Docker HTTP API或unix套接字。 Consul使用$ DOCKER_HOST來肯定Docker API端點。應用程序將對在容器內運行的服務執行健康檢查，並使用適當的退出代碼退出。檢查應與調用間隔一塊兒使用。須要執行檢查的shell是可配置的，這使得能夠在同一主機上運行具備多個不一樣shell的容器。 Docker的檢查輸出限制爲4KB。任何大於此的輸出將被截斷。在Consul 0.9.0和更高版本中，代理必須配置enable_script_checks設置爲true以啓用Docker運行情況檢查。

檢測定義

腳本檢測:

{
"check": {
"id": "mem-util",
"name": "Memory utilization",
"args": [
"/usr/local/bin/check_mem.py",
"-limit",
"256MB"
],
"interval": "10s",
"timeout": "1s"
}
}

http檢測:

{
"check": {
"id": "api",
"name": "HTTP API on port 5000",
"http": "https://localhost:5000/health",
"tls_skip_verify": false,
"method": "POST",
"header": {
"x-foo": [
"bar",
"baz"
]
},
"interval": "10s",
"timeout": "1s"
}
}

TCP 檢測:

{
"check": {
"id": "ssh",
"name": "SSH TCP on port 22",
"tcp": "localhost:22",
"interval": "10s",
"timeout": "1s"
}
}

ttl檢測:

{
"check": {
"id": "web-app",
"name": "Web App Status",
"notes": "Web app does a curl internally every 10 seconds",
"ttl": "30s"
}
}

Docker檢測:

{
"check": {
"id": "mem-util",
"name": "Memory utilization",
"docker_container_id": "f972c95ebf0e",
"shell": "/bin/bash",
"args": [
"/usr/local/bin/check_mem.py"
],
"interval": "10s"
}
}

每種類型的定義都必須包含一個名稱，而且能夠選擇性地提供一個id和notes字段。每一個代理的id都必須是惟一的，不然相同的id號只有最後被定義的檢查將被註冊。若是沒有設置ID而且檢查被嵌入在服務定義中，則consul會自動生成惟一的檢查ID。不然，id將被設置爲name。若是name可能衝突，應提供惟一的ID

注意：Consul 0.9.3和以前的版本須要可選的檢查ID來檢查嵌入在服務定義中的檢查，以經過CheckID字段進行配置。 Consul 1.0同時接受id和CheckID，但後者已被棄用，並將在Consul 1.1中被刪除。

notes字段對於Consul而言是不透明的，可是能夠用來提供對檢查當前狀態的可讀描述。經過腳本檢查，該字段被設置爲腳本生成的任何輸出。一樣，外部程序能夠經過HTTP接口更新TTL檢查的notes值。

健康檢測能夠經過包含token字段來提供ACL token,這個token用於與檢測目錄的任何交互，包括反熵同步和取消註冊

Script, TCP, Docker 和HTTP 檢測必需包含有 interval 字段. 這個字段會被Go的time包解析,並具備如下格式規範:

時間字符串描述多是有符號的十進制數字序列，每一個都有可選的小數和單位後綴，如「300ms」，「-1.5h」或「2h45m」。有效的時間單位是「ns」，「us」（或「μs」），「ms」，「s」，「m」，「h」。

在Consul 0.7和更高版本中，與服務關聯的檢查也可能包含一個可選的deregister_critical_service_after字段，該字段與interval和ttl的Go時間格式相同。若是檢查處於危險狀態超過此配置值，則其相關服務（及其全部相關檢查）將自動取消註冊。最小超時時間爲1分鐘，收集危險狀態服務的進程每30秒運行一次，所以可能須要比配置的超時稍長的時間來觸發註銷。一般應該將這個值配置成比給定服務預期的可恢復中斷時間長得多的值。

配置檢測時，不管是經過-config-file選項提供給代理，或者將其放置在代理的-config-dir中，該文件必須以「.json」的擴展名結尾才能被consul加載。檢測定義也能夠經過向代理髮送SIGHUP來更新。或者，可使用HTTP API動態註冊檢測

檢測腳本

腳本檢測一般能夠自由地作任何事情來肯定檢查的狀態。惟一的限制是退出代碼必須遵照如下約定：

Exit code 0 -檢測經過
Exit code 1 -檢測告警
Any other code -檢測失敗
這是consul依賴的惟一的約定。腳本的任何輸出都將被捕獲並存儲在notes字段中，以便操做人員能夠查看

在Consul 0.9.0和更高版本中，代理必須配置enable_script_checks設置爲true以啓用腳本檢查。

在Consul 1.0以前，檢測只使用script字段來定義要運行的命令，而且老是在shell中運行。在Consul 1.0中，添加了args數組,所以沒有shell的狀況下也能夠運行檢查，script字段已棄用，您應該將shell包含在args中以在shell下運行腳本，例如。 「args」：[「sh」，「-c」，「...」]。
»初始化健康檢查狀態

默認狀況下，一量健康檢測在Consul代理註冊成功，狀態會當即設置爲「critical」。這是爲了防止服務在被確認爲健康以前被註冊爲「經過」並進入服務池。在某些狀況下，可能須要指定健康檢查的初始狀態。這能夠經過在指定檢測定義的status字段來實現，以下所示

{
"check": {
"id": "mem",
"args": [
"/bin/check_mem",
"-limit",
"256MB"
],
"interval": "10s",
"status": "passing"
}
}
上面這個服務定義中，檢測狀態會被註冊爲 "passing".

服務綁定檢測

健康檢測能夠綁定到指定的服務，這樣能夠保證檢測狀態隻影響到當前服務而不是整個節點，服務綁定健康檢測能夠經過添加service_id字段來實現：

Health checks may optionally be bound to a specific service. This ensures that the status of the health check will only affect the health status of the given service instead of the entire node. Service-bound health checks may be provided by adding a service_id field to a check configuration:

{
"check": {
"id": "web-app",
"name": "Web App Status",
"service_id": "web-app",
"ttl": "30s"
}
}
在上述配置中，若是web-app服務健康檢測爲失敗狀態，則只會影web-app服務的可用性。節點提供的其餘服務將保持不變。

定義多個檢測

能夠經過關鍵字checks來定義多個健康檢測：

{
"checks": [
{
"id": "chk1",
"name": "mem",
"args": [
"/bin/check_mem",
"-limit",
"256MB"
],
"interval": "5s"
},
{
"id": "chk2",
"name": "/health",
"http": "http://localhost:5000/health","interval": "15s"},{"id": "chk3","name": "cpu","script": "/bin/check_cpu","interval": "10s"},...]}