翻譯至：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"
},
...
]
}