翻译至:https://www.consul.io/docs/agent/checks.htmlhtml
代理的主要角色之一是系统级和应用级健康检测的管理。若是健康检查与服务相关联,则认为它是应用级。若是不与服务关联,则健康检测监视整个节点的健康情况。
健康检测在配置文件中定义,或者在运行时经过HTTP接口添加。经过HTTP接口建立的健康检测会在该结点进行持久化。node
脚本+时间间隔 - 这些检查依赖于调用外部应用程序来执行健康情况检查,以适当的退出代码退出,并可能产生一些输出。脚本与调用间隔(例如每30秒)组合使用。这与Nagios插件系统相似。脚本检查的输出限制为4KB,大于4kb的输出将被截断。默认状况下,脚本检查将配置30秒的超时时间,也能够在检测定义时经过timeout字段来自定义脚本检查的超时时间。当Windows达到超时时间,Consul将等待脚本产生的任何子进程完成;其余系统一旦超时,Consul将尝试强制终止检测脚本和它产生的任何子进程。在Consul 0.9.0和更高版本中,代理必须配置enable_script_checksset为true以启用脚本检测ios
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来关闭证书验证。web
TCP +间隔 - 这种检方式是每隔一个间隔(例如每30秒)对指定的IP /主机名和端口进行TCP链接尝试。若是没有指定主机名,则默认为“localhost”。服务的状态取决于链接尝试是否成功(即 - 端口当前正在接受链接)。若是链接被接受,则服务的状态是成功的,不然是失败的。在主机名同时解析为IPv4和IPv6地址的状况下,将尝试链接这两个地址,而且首次成功的链接尝试将致使成功的检查。若是是简单的套接字操做检测内里优先选择这种检测方式,默认状况下,TCP检查的请求超时等于检查时间间隔,最大值为10秒。能够经过在检查定义中指定timeout字段来配置自定义TCP检查超时值。docker
TTL检测 - ttl检测会在ttl时间内保留上次的检测状态,检测状态必须经过HTTP接口按期更新,若是外部系统没法在给定的TTL内更新状态,则检查设置为失败状态。这个检测机制依靠应用程序直接报告其健康情况。例如,健康的应用程序能够按期向HTTP端点发送状态更新;若是应用程序失败,TTL将过时,健康检查进入危险状态。 TTL检查还将其最后一次已知的状态保存到磁盘。这容许Consul代理重启后能够恢复检查的最后一个已知状态,持久化的检测状态的有效期为从上次检查时间起到TTL结束时。shell
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运行情况检查。json
脚本检测:api
{
"check": {
"id": "mem-util",
"name": "Memory utilization",
"args": [
"/usr/local/bin/check_mem.py",
"-limit",
"256MB"
],
"interval": "10s",
"timeout": "1s"
}
}数组
http检测:bash
{
"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"},...]}