一、背景
需求
现在有一套监控系统，我们组需要将它接入进来，用于给组内开发的系统提供监控服务。并且，现在需要将其部署在多活节点上。
监控功能介绍
主要分成两个功能：
- agent服务：按照指标（如net.out.bytes）采集当前机器的数据;
- others服务：处理（如分析、转发、存储等）agent采集后上报的数据，这里其实是细分成四个服务的，为了方便，统称为一个，others服务。
监控系统说明文档
该文档里主要介绍了两部分内容：
- 如何下载监控系统的tar包，并解压缩到哪个目录；
- 如何更改配置文件，并使用什么指令运行该监控服务。
限制点
- 监控系统说明文档关于“如何更改配置文件”的注释，只适用于单节点部署，然而我们组内现在需要多节点部署该监控系统；
- 我自己没有接触过这套监控系统，也只会按照说明文档部署单节点，连上面的“监控功能介绍”的内容都不是很熟悉。
二、过程
与bug相遇
按照“监控系统说明文档”部署单节点的方式，将监控系统部署在三台机器上，发现并没有采集数据。
第一次排查&一无所获
基础信息检查
- 检查服务是否运行
- 检查端口是否开放
- ping检查三节点之间是否互通
结果
都正常
第二次排查&小小的惊喜
已知点
配置文件里字段others的值是ip，并且设置的是127.0.0.1。
思考
127.0.0.1表明需要访问的服务是本地允许的，一直以来都是部署点节点的，现在是在三节点上部署，所以应该要给others字段的值多添加另外两个节点的公网ip。
结果
果然有数据了！但是，前端没有数据，而直接调用api查看response看到有数据
第三次排查&又一个惊喜，但实际是个坑
接口跟踪&数据库检查
- 无数次模拟调接口，看日志，跟踪接口
- 反复查看数据库，校对数据表
结果
接口返回正常，数据库也没问题，数据也正常存储。前端依旧没有展示数据。不死心，重复很多次这些步骤，在这次排查上浪费了很多时间。
突破
组里的同事指点了一下，告诉说“前端要展示的是另外两台机器的数据，你只在多活三节点上部署了”。恍然大悟！也正是这个时候，才真正了解了agent和others的作用。于是赶紧在另外两台机器上也部署了agent，配置文件的里others的值设置成多活三节点的三个公网ip。果然，前端有数据里，欣喜不已！（这就给我后面埋了一个坑）
但是，展示的数据中，比如cpu、mem等指标都有数据，就net没有数据。
第四次排查&陷入坑中无法脱身
入坑
第三次的排查得到了一个特大的正反馈：不仅能采集数据，前端也能展示，而且更是清楚知道了agent和others的分工。也正是因为长时间排查后终于能在前端看到数据，所以我就陷入一个“迷之自信”当中：我坚定地认为配置文件这么设置没有任何问题了，你看，前端都展示数据了，这么配置肯定是对的！
越陷越深
我“坚信”一定是被采集数据的机器上没有net的IO，于是乎，我开始给那两台机器上传下载文件，特意创造net高IO的场景，结果仍然没有数据。然后我又直接调用API查看返回数据，关于cpu、mem等指标都有数据返回，就net指标的返回值是null。其实排查到这，就应该明白了，一定是net指标采集数据有问题，顺藤摸瓜去排查跟net相关的设置就很容易发现问题了。但是！因为“迷之自信”以及长时间的排查无果，已经让我无法冷静，没有维持正常的理性逻辑。以至于我后面甚至又把上面几次排查的步骤重新走了一遍！
强行冷静&开始看底层源码实现
苦苦挣扎，没有结果，我开始冷静并反思：“采集数据没问题，数据存储没问题，API获取数据没问题，前端展示没问题，现在就只缺少net这个指标的数据，那如果我能知道这个监控系统是怎么采集数据的，就应该能解决这个问题。”。冷静下来后，我开始看源码的设计，最后我梳理了采集数据的设计结构，果然发现了问题所在：该系统采集net指标对应的数据时，会先去读取当前机器上的/proc/net/dev。这个文件是存储本机网卡信息的，监控系统读取该文件，获取到网卡名，再跟配置文件里设置的网卡名对比，如果一致就采集，否则不采集。于是我去配置文件将net相关配置检查了一下，果然，网卡字段的值设置的是“eth0”，然而当前部署的这些机器上的网卡实际都是“eno1”，所以它不采集net指标的数据。至此，脱坑！
感悟
- 遇到bug后不能上来就无脑地排查，没有冷静地分析，很容易做无用功。
- 解决bug的过程很多都是一步一步接近真相，在这个过程中，每一步都可能有正反馈，但是有时这些正反馈反而会让你失去冷静，不愿意分析，尤其浪费很长时间都不能解决问题的时候突然解决了一部分，这种正反馈更容易让人松懈。
- 对项目／系统不熟悉，会极大地阻碍你对bug的定位和修复，这时候不如放下执念，去看一看底层源码是如何实现的，磨刀真的不误砍柴工！