Consul的一個基本功能是提供系統級和應用級健康檢查。如果健康檢查與某個服務關聯，則稱為是應用級的；如果不予服務關聯，則監控整個節點的健康。

check定義在配置檔案中，或執行時通過HTTP介面新增。Check是通過HTTP與節點保持一致。

有五種check方法：

        通過執行外部應用進行健康檢查：這種外部程式具有退出程式碼，並可能產生一些輸出；指令碼按照指預置時間間隔來呼叫（比如，每30秒呼叫一次），類似於Nagios外掛系統，指令碼輸出限制在4K以內，輸出大於4K將截斷。預設情況下，指令碼超時時間為30秒——可通過timeout來配置。

示例：

{
  "check": {
    "id": "mem-util",
    "name": "Memoryutilization",
    "script": "/usr/local/bin/check_mem.py",
    "interval": "10s",
    "timeout": "1s"
  }
}
 

1.1.2  HTTP+ Interval

        這種檢查將按照預設的時間間隔建立一個HTTP “get”請求。HTTP響應程式碼來標示服務所處狀態：任何2xx程式碼視為正常，429表示警告——有很多請求；其他值表示失敗。

這種型別的檢查應使用curl或外部程式來處理HTTP操作。預設情況下，HTTP Checks中，請求超時時間等於呼叫請求的間隔時間，最大10秒。有可能使用客制的HTTP check，可以自由配置timeout時間，輸出限制在4K以內，輸出大於4K將截斷。

{
  "check": {
    "id": "api",
    "name": "HTTPAPI on port 5000",
    "http": "http://localhost:5000/health",
    "interval": "10s",
    "timeout": "1s"
  }
}
 

1.1.3  TCP+ Interval

        將按照預設的時間間隔與指定的IP/Hostname和埠建立一個TCP連線。服務的狀態依賴於TCP連線是否成功——如果連線成功，則狀態是“success”；否則狀態是“critical”。如果一個Hostname解析為一個IPv4和一個IPv6，將嘗試連線這兩個地址，第一次連線成功則服務狀態是“success”。

        如果希望通過這種方式利用外部指令碼執行健康檢查，那麼指令碼應該採用“netcat”或者簡單的socket操作。

預設情況下，TCP checks中，請求超時時間等於呼叫請求的間隔時間，最大10秒。也是可以自由配置的。

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

1.1.4  Timeto Live（TTL）

        這種checks為給定TTL保留了最後一種狀態，checks的狀態必須通過HTTP介面週期性更新，如果外部介面沒有更新狀態，那麼狀態就會被認定為不正常。

        這種機制，在概念上類似“死人開關”，需要服務週期性彙報健康狀態。比如，一個健康的APP可以週期性的將狀態put到HTTP端；如果app出問題了，那麼TTL將過期，健康檢查將進入Critical狀態。用來為給定check更新健康資訊的endpoint都是pass endpoint和fail endpoint。（參見agent http endpoint）

        TTL checks同時會將其最後已知狀態更新至磁碟，這允許Agent通過重啟後恢復到已知的狀態。通過TTL端上一次check來維持健康狀態的有效性。

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

1.1.5  Docker+ interval

        這種檢查依賴於呼叫封裝在docker容器內的外部程式。執行的docker通過docker Exec API來觸發外部應用。

        我們期望，consul Agent使用者訪問Docker HTTP API或UNIX套接字。Consul使用$DOCKER_HOST來確定Docker API端點。應用程式將執行，並對在容器內執行的服務執行健康檢查，並返回適當的退出程式碼。Check按照指定的時間間隔呼叫。

        如果在同一個host主機上有多重shell，那麼同樣需要配置shell引數。

輸出限制在4K以內，輸出大於4K將截斷。

{
"check": {
    "id": "mem-util",
    "name": "Memoryutilization",
    "docker_container_id": "f972c95ebf0e",
    "shell": "/bin/bash",
    "script": "/usr/local/bin/check_mem.py",
    "interval": "10s"
  }
}

1.1.6 小結

        每一種check都必須包含name，id和notes兩個是可選的。如果沒有提供id，那麼id會被設定為name。在一個節點中，check的ID都必須是唯一的。如果名字是衝突的，那麼ID就應該設定。

        欄位Notes主要是增強checks的可讀性。Script check中，notes欄位可以由指令碼生成。同樣，適用HTTP介面更新TTL check的外部程式一樣可以設定notes欄位。

1.1.7  Check指令碼

        Check指令碼可以自由地做任何事情確定check的狀態。唯一的限制是：退出程式碼必須遵循下面的約定：

1. 退出程式碼0 – 正常
2. 退出程式碼1 – 告警
3. 其他值 - 失敗。

        Consul依賴此約定。指令碼其他的輸出都儲存在notes欄位中，可以供人檢視。

1.1.8  健康狀態初始化

        預設情況下，當checks註冊到Consul agent時，健康狀態立即被設定為“Critical”。可以防止服務直接被註冊為通過（“passing”）狀態，在進入service pool前認為是健康狀態。在某些情況下，checks可能需要指定健康檢查的初始狀態，可以通過設定“status”欄位來實現。

如下：

{
  "check": {
    "id": "mem",
    "script": "/bin/check_mem",
    "interval": "10s",
    "status": "passing"
  }
}

初始狀態設定為passing。

1.1.9  Service-boundchecks

        健康檢查（Health checks）或者有可能繫結到指定的服務。這將確保健康檢查的狀態只會影響給定的服務而不是整個節點。服務繫結健康檢查需要提供一個service_id欄位。

{
  "check": {
    "id": "web-app",
    "name": "WebApp Status",
    "service_id": "web-app",
    "ttl": "30s"
  }
}

        在上述示例中，web-app健康檢查如果失敗了，只會影響web-app服務的有效性，本節點的其他服務是不受影響的。

1.1.10  MultipleCheck Definitions

多個check定義，可以使用欄位“checks”，示例：

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