故事背景
上周同事收到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组件解决方案
序言
在前面经过一些尝试与讨论工作之后，个人认为其实官方途径暂时无法解决这个问题，后面我自己采取了一个”挂羊头卖狗肉“的方式去解决了这个问题。由于之前在社区并没有找到相关问题的解决方案，所以记录一下解决过程分享给大家
测试环境简介
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 社区