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

x33g5p2x  于2021-12-20 转载在 其他  
字(1.2k)|赞(0)|评价(0)|浏览(459)

    健康检查是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服务体现架构变得更加容易。

相关文章