原文来源：https://tidb.net/blog/7747fec7

故事背景

上周同事收到 tidb 生产集群告警，node_exporter 组件发生了重启，与同事交流了一下相关历史告警，发现 node_exporter 组件总是时不时的重启，并触发告警，并且整个集群各个节点都有发生过这个现象。

这里先简单介绍下 node_exporter 组件相关背景以及它的作用：TiDB 使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案，而 node_exporter 是 Prometheus 的指标数据收集组件。它负责从目标 Jobs 收集数据，并把收集到的数据转换为 Prometheus 支持的时序数据格式。所以在部署集群时，通常会在集群的每个节点都分发并运行 node_exporter 组件。

经过我们对重启现象的排查确认，认为是 node_exporter 组件会偶发性的出现 panic, 导致节点重启，经过与 PingCap 原厂的工程师反馈这个问题后，建议我们尝试将 node_exporter 组件的版本进行升级。

我们在本地镜像源里面检查了一下 node_exporter 组件的版本，发现当前版本是 v0.17.0 版本，也是 PingCap 官方推出的最高版本，而 prometheus 官方已经推出了 v1.3.1 版本的 node_exporter 组件

因此后面计划从 prometheus 官网下载 v1.3.1 版本的 node_exporter 组件包，去不停机升级到我们的测试集群中，在不影响服务的情况下升级，再观察下能否解决这个 panic 的问题。

#node_exporter 组件包下载网址：https://github.com/prometheus/node_exporter

初期遇到的问题

当前集群是本地离线镜像源部署的，这种背景下，我初期大致的的实施思路是这样的：

1/ 下载 node_exporter 组件包上传到离线的生产环境中控机

2/ 使用tiup mirror publish将该组件包发布到本地离线镜像源tiup mirror publish | PingCAP Docs

3/ 使用tiup install或者tiup update更新 node_exporter 组件到 v1.3.1 版本

按照这种思路操作，我发现所有操作都是报 successfully！，但是去检查各个节点的 node_exporter 二进制文件还是 v0.17.0 版本，并且启动的服务的日志也都是 0.17.0 版本，后面尝试过更多官方可能的一些可能的操作，例如tiup cluster patch或者tiup cluster upgrade 等，都没发解决我的问题，后面自己做出了一些猜想：node_exporter 组件不属于“cluster”原生组件，所以并不能使用 tiup 的一些相关命令直接去升级，后面去开帖和社区的朋友们讨论了一波，似乎也论证了我的猜想。

讨论的帖子：如何在线的将本地 node_exporter 组件从在线的 v0.17.0 升级到 v1.3.1 版本（prometheus 已经有该版本，但是 pingcap 只出了 0.17.0 版本） - TiDB / 部署 & 运维管理 - TiDB 的问答社区 (asktug.com)

在线升级 node_exporter 组件解决方案

序言

在前面经过一些尝试与讨论工作之后，个人认为其实官方途径暂时无法解决这个问题，后面我自己采取了一个”挂羊头卖狗肉“的方式去解决了这个问题。由于之前在社区并没有找到相关问题的解决方案，所以记录一下解决过程分享给大家

测试环境简介

1/ 整个测试用到 5 台虚拟机，分别用 ip 最后一位 180，190，200，210，220 简称，其中 190 是中控机

2/ 当前测试中控机有 v5.4.0 版本的离线镜像源，v1.3.1 版本的 node_exporter 组件包

解决方案实施步骤

1/ 确认当前节点 node_exporter 组件进程正常，以保证后续流程正常

命令：tiup cluster exec tidb-test --command='ps -ef |grep node

#tiup cluster exec 命令可以将要执行的命令，由中控机发送到集群各个节点执行

2/ 用 V1.3.1 版本的 node_exporter 组件二进制文件，去替换掉各节点 V0.17.0 版本的二进制文件

2.1、确认节点 node_exporter 可执行文件位置（如各节点部署目录不同，后续命令需调整）

命令：tiup cluster exec tidb-test --command='ls /tidb-deploy/monitor-9100/bin/node_exporter'

2.2、删除个节点 node_exporter 组件的二进制文件

命令：tiup cluster exec tidb-test --command='rm -rf /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter'

2.3、将中控机 v1.3.1 版本 node_expor 二进制文件分发到各个节点

命令：tiup cluster push tidb-test /home/tidb/node_exporter-1.3.1.linux-amd64/node_exporter /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter

# 这里需要确认命令中的目录是否需要调整

#tiup cluster push 指令可用来将中控机的文件批量分发到集群各个节点，这里相当于分别执行了 cp、scp 命令复制传输文件

2.4、赋予可执行权限

命令：tiup cluster exec tidb-test --command='chmod u+x /tidb-deploy/monitor-9100/bin/node_exporter/node_exporter'

3/kill 各个节点 node_exporter 进程，自动拉起进程后，验证各节点启动的 node_exporter 组件版本

3.1、先确认下之前分发到各个节点的可执行文件版本

命令：tiup cluster exec tidb-test –command=‘/tidb-deploy/monitor-9100/bin/node_exporter/node_exporter –version’

3.2、Kill 各节点 node_exporter 进程：

命令：tiup cluster exec tidb-test --command='pkill -9 node_exporter '

# 这里我直接将进程名中含 node_exporter 的所有进程全部 kill 了，执行前请先确认自己当前环境进程，是否会误操作

3.3、短暂时间后（我这里通常 1min 内），进程自己恢复，去检查启动日志，验证启动的 node_exporter 版本

# 启动日志位置

命令：tiup cluster exec tidb-test --command='tail -n 100 /tidb-deploy/monitor-9100/log/node_exporter.log'

# 日志中的时间为标准时间，比北京时间早 8 小时，因此日志中的 06：43：33 实际上是北京时间 14：43：33

观察日志：我在 14：47 看到日志中记录在 14：43：33 启动了 node_exporter 组件，且启动的版本是 1.3.1，说明：在线升级 node_exporter 组件成功！

解决扩容节点使用新版本的 node_exporter 组件的问题

序言

前面章节讲述到，如何在线升级集群 node_exporter 组件，但是作为一个优秀的 dba, 我们需要可持续性的解决问题，这里很容易想到在未来如果该集群进行了扩容，是否还会使用高版本的 node_exporter 组件呢？很显然答案是否定的！

本章节就是讲述如何保障后续扩容时也会使用高版本的组件

解决方案实施步骤

1/ 重新设置 node_exporter-v1.3.1-linux-amd64.tar.gz 包

# 这一步重新设置的作用，会在后续 FAQ 专门解答

1.1、解压 node_exporter-v1.3.1-linux-amd64.tar.gz 包

命令：tar -zxvf node_exporter-v1.3.1-linux-amd64.tar.gz

解压后发现，会得到文件夹 node_exporter-v1.3.1.linux-amd64

1.2、将文件夹 node_exporter-v1.3.1.linux-amd64 改名为 node_exporter

命令：mv node_exporter-v1.3.1.linux-amd64 node_exporter

1.3、重新将 node_exporter 文件夹打包成 tar.gz 包

命令：tar zcvf node_exporter-v1.3.1-linux-amd64.tar.gz node_exporter

2/ 发布 & 更换中控环境中的 node_exporter 组件的 tar.gz 包

2.1 将当前镜像源里的 key 目录发送到.tiup 文件夹下

命令：cp -r /home/tidb/tidb-community-server-v5.1.3-linux-amd64/keys /home/tidb/.tiup/

# 这里为什么要发送 keys 目录, 请参考：tiup mirror merge | PingCAP Docs

2.2、将新版本的组件包发布到本地离线镜像源

命令：tiup mirror publish node_exporter v1.3.1 ./node_exporter-v1.3.1-linux-amd64.tar.gz node_exporter/node_exporter --key ./.tiup/keys/4d418a71219c1935-pingcap.json

# 该命令详解请参考：tiup mirror publish | PingCAP Docs

2.3、将中控机将.tiup 中下原来 0.17.0 版本的 tar.gz 包删除

命令：rm -rf /home/tidb/.tiup/storage/cluster/packages/node_exporter-v0.17.0-linux-amd64.tar.gz

2.4、将之前重新设置的 1.3.1 版本的 node_exporter 的 tar.gz 包发送到.tiup 下

命令：cp node_exporter-v1.3.1-linux-amd64.tar.gz /home/tidb/.tiup/storage/cluster/packages/node_exporter-v1.3.1-linux-amd64.tar.gz

2.5、赋予可执行权限

命令：chmod u+x /home/tidb/.tiup/storage/cluster/packages/node_exporter-v1.3.1-linux-amd64.tar.gz

最后效果：

FAQ

问题一：为什么要重新设置 v1.3.1 版本 node_exporter 组件的 tar.gz 包？直接 git_hub 下载的不能用吗？

解答：因为在后续进行扩容的过程中，会将/home/tidb/.tiup/storage/cluster/packages/ 下的 node_exporter 组件包发送到新增节点，而启动时，会通过脚本调用启动组件包中的 node_exporter 二进制文件，而脚本中写死的的调用路径为 node_exporter/node_exporter, 第一个 node_exporter 为该组件包解压后目录的名字，所以我需要专门提前把解压后的目录名改成 node_exporter

验证方式：

1/ 找一个 pingcap 官方的 node_exporter 组件包解压，你会发现解压后目录名是 node_exporter

2/ 直接去查看各节点调 node_exporter 的脚本内容，发现是写死的

扩容测试

1/ 编辑扩容文件（扩容一个 220 节点），执行扩容命令

命令： vi scale-out-tikv.yaml

扩容命令：tiup cluster scale-out tidb-test scale-out-tikv.yaml

2/ 到扩容的 220 上确认 node_exporter 进程正常

3/ 查看 220 上 node_exporter 组件的启动日志，验证启动的 node_exporter 版本

4/ 验证分发到 220 这个节点的可执行文件 node_exporter 组件版本

测试结论：

经过之前的解决步骤后，后续的扩容完全会使用 1.3.1 版本的 node_exporter 组件，解决方案能解决扩容的问题！

其他相关 FAQ

问题一：集群版本进行升级后（离线升级），是否会将各个节点的已升级的 node_exporter 组件给覆盖掉？升级后再扩容还会使用高版本的 node_exporter 组件吗？

解答一：集群升级后，已升级的各个节点的 node_exporter 组件并不会被覆盖掉导致版本回退，但是由于本地离线升级后镜像源更换，会重新从新镜像源里面加载该镜像源里面 node_exporter 组件到.tiup 下，导致后面扩容使用低版本组件，这里需要执行以下上一章节《解决扩容节点使用新版本的 node_exporter 组件的问题》，可解决未来的扩容问题。

问题二：我们是否可以直接部署集群前，就定制包含高版本，例如 v1.3.1 版本的 node_exporter 组件的镜像源使用？

解答二：可以！

实现步骤简介：

1/ 直接将镜像源里面的 node_exporter 组件包删除

2/ 使用 publish 将高版本的组件包发布到镜像源

# 作者认为：看过文章前面部分，就会知道这两步具体怎么操作，我就不再复述啦！

作者想说：

1/ 文章篇幅太长，难免出现纰漏，阅读过程中有任何疑问，欢迎直接在评论区提出来进行讨论

2/ 在背景故事中，我们最终目的其实是为了解决 node_exporter 组件的 ”panic”，目前已经在测试环境进行升级，一段时间后观察到问题解决了，会在文章评论区答复，欢迎关注本文章

3/ 其实作者希望这篇文章能帮助解决组件相关的一类的问题，不仅仅是 node_exporter 组件，希望以后碰到类似问题也可以用本文章相关内容，进行类比尝试

4/ 关于组件的其他改造使用可以参考另一篇：专栏 - 记一次 tidb 离线环境下安装非本地镜像源组件的过程 | TiDB 社区

##