consul代理---健康檢測有五種不同的健康檢測：檢測定義檢測腳本服務綁定檢測定義多個檢測

代理的主要角色之一是系統級和應用級健康檢測的管理。如果健康檢查與服務相關聯，則認為它是應用級。如果不與服務關聯，則健康檢測監視整個節點的健康狀況。

健康檢測在配置檔案中定義，或者在運作時通過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檢測:

"id": "api", "name": "HTTP API on port 5000", "tls_skip_verify": false, "method": "POST", "header": { "x-foo": [ "bar", "baz" ] },

TCP 檢測:

"id": "ssh", "name": "SSH TCP on port 22", "tcp": "localhost:22",

ttl檢測:

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

Docker檢測:

"docker_container_id": "f972c95ebf0e", "shell": "/bin/bash", "/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字段來實作，如下所示

"id": "mem", "/bin/check_mem", "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:

"service_id": "web-app", 在上述配置中，如果web-app服務健康檢測為失敗狀态，則隻會影web-app服務的可用性。節點提供的其他服務将保持不變。

可以通過關鍵字checks來定義多個健康檢測：

"checks": [ "id": "chk1", "name": "mem", "interval": "5s" "id": "chk2", "name": "/health", "interval": "15s" "id": "chk3", "name": "cpu", "script": "/bin/check_cpu", ... 本文轉自 emma_cql 51CTO部落格，原文連結: http://blog.51cto.com/chenql/2044811