【Consul】关于健康检查的一点思考

健康检查是Consul提供的一项主要功能，其配置格式如下：

{
 "check": {
   "id": "redis",
   "name": "redis valid",
   "script": "/usr/local/bin/check_redis.py",
   "interval": "3s",
   "timeout": "1s"
  }
}

如上语义为，每个3s调用外部程序执行redis有效性检查。

Consul规定了外部脚本退出码代表的语义：

Ø 退出代码0 – 正常passing

Ø 退出代码1 – 告警warning

Ø 其他值 - 失败critical

换句话说，健康检查程序返回的状态最多有3种，consul agent会将每次检查的结果上报的consul集群。

在实践过程中出现了一个问题。

实践方案为：5节点Consul集群，每个节点均注册redis服务，并执行redis健康检查，leader节点搜集所有节点的redis状态数据，然后进行异常状态处理。

问题：当某个节点返回passing后，节点直接掉电，Consul存储中的该节点的redis状态数据会一直是passing状态，与实际不符。

基于实践结果，推测，健康检查的状态数据会存放到数据库，由于故障节点掉电导致无法更新数据，导致状态数据一直未passing。

解决办法为：基于session机制

{
  "LockDelay":"10s",
  "Name":"nodex-redis",
  "Node":"nodex",
  "Checks":["redis"],
  "Behavior":"release",
  "TTL":"0s"
}

在外部执行程序中增加与redis服务相关session，当监测是redis有效时就renew，否则destroy；leader节点监测session的存在性，若不存在则相应节点redis服务失效。

另外一种方案，基于服务查询机制，

[tag.]<service>.service[.datacenter].<domain>

leader监测节点的数据中心的注册的服务是否发生变化，但是有如下缺陷，其结果并不一定准确。

DNS查询系统利用健康检查以防止不良节点路由信息。当服务查询时，如果服务健康检查失败或者系统检查失败，服务信息将会从查询结果中删除。为了实现简单的负载平衡，返回的节点集合每次都是随机的。这种机制使得利用DNS接口基于应用级重试实现面向auto-healing服务体现架构变得更加容易。