TiDB 残余监控信息处理

1. 背景

在 TiDB 使用过程中,缩容或者是TiKV 机器宕机的情况是常见的情况,尤其是在云主机中,机器宕机的时候,不考虑 label 的情况下如果少于多数副本数的 TiKV 机器宕机,是不会影响数据的。 比如五副本,宕机两台不会影响服务,高可用性。但是在处理完down 机或 缩容的节点后,grafana 监控中依然会有残余的监控信息,这里介绍处理的办法。

2. 产生原因

其实这个问题要说到 TiDB 的监控模式, TiDB 3.0 默认的监控架构如下图所示,采用了 pull 的方式采集监控信息。 monitor.png 而早期 push 的结构如下

<div align=center>
</div>

pull 相比push 它有以下几个优点:

  • 如果 Prometheus 需要迁移,无需重启整个 TiDB 集群。调整前,因为组件要调整 push 的目标地址,迁移 Prometheus 需要重启整个集群。
  • 支持部署 2 套独立的 Grafana + Prometheus 的监控平台(非 HA),防止监控的单点。方法是使用 ansible 用不同的 ip 各执行一次部署命令。
  • 去掉了 Pushgateway 这个单点组件。

2.1.3 我们支持了pull 模式,而 2.1 tikv 的监控依然默认采用的是 push 的方式,可以通过 ansible 目录下的配置修改 group_vars/all.yml 里的 tikv_metric_method 修改

监控信息残留会主要发生在 push 结构的监控架构中,从客户反应来看,主要有以下几个问题。

  1. TiKV 下线后,region/leader 中依然有这个节点的信息。
  2. PD 中显示 tombstone 的tikv节点一直存在。 针对上面的问题有以下解决方案

3. 解决方法

  1. PD 中显示 tombstone 的tikv节点一直存在,没有消失。这是为了保留历史信息,目前pd-ctl 中提供了一个命令删除 tombstone 状态节点的信息。
    stores remove-tombstone
    这个命令目前在 2.1.17 之后以及 3.0 可以提供。

  2. TiKV 下线后,grafana中 region/leader 中依然有这个节点的信息。 这是因为老数据依然存在于 pushgateway 中,需要在 pushgateway 中删除,使用如下命令
    curl -X DELETE http://{pushgateway_ip}:{pushgateway_port}/metrics/job/{job_name}/instance/{instance_name}

4.总结

目前 TiDB 在更新监控的时候并不会把之前的监控信息給删掉,而且按照 prometheus 里的gc 时间去保留,以便查看历史监控信息。如果残留的监控信息会导致困扰,可以使用上面的办法手动删除。

Written on March 19, 2020