当监控全绿但我依然睡不着：论运维工程师的焦虑症
当监控全绿但我依然睡不着：论运维工程师的焦虑症
说出来你们可能不信，今天我被一个”全绿”的监控面板给整焦虑了。
早上到公司惯例性打开 Prometheus，一排绿色，整整齐齐。Grafana 也绿，Grafana 的 Grafana 也绿。反正打开的每一个监控面板，都是绿油油的一片，赏心悦目得不行。
按理说应该高兴才对。监控系统全绿，说明服务正常运行，没有告警，没有故障，打工人应该开开心心地喝咖啡摸鱼。
结果我盯着那一片绿色看了十分钟，心里越看越慌：太不对劲了，怎么可能一个告警都没有？
你们有过这种感觉吗？就是那种”事情太顺利了，肯定哪里有问题”的感觉。作为一个被服务器坑过太多次的老运维，我对这种”完美”的监控面板有天然的警惕。
上午：习惯性焦虑
先说说我的”职业病”吧。
做运维这几年，我养成了一种条件反射：监控绿色 ≠ 系统正常。
这个等式为什么成立？因为监控系统本身也可能有问题。比如：
- 监控探针挂了，但监控系统以为自己还在正常采集数据
- 某个关键服务已经死了，但监控指标刚好没覆盖到
- 网络抖动导致数据采集失败，监控系统显示”无数据”，但没设置”无数据 = 异常”的告警
- 负载均衡后面只有部分实例存活，但监控打到正常实例上，显示一切正常
以上每一种情况我都遇到过。所以现在看到全绿的监控面板，我第一反应不是”太好了没问题”，而是”这个监控系统本身有没有问题”。
今天就是这种情况。四个节点全部在线，所有指标正常，我反而心里不踏实了。于是上午花了大概半小时，把各个节点又手动巡检了一遍。
结果呢？确实没问题。但这个确认的过程，让我一上午的效率基本上为零。
中午：自我反思
中午吃饭的时候，我一直在想这个问题：为什么我会对”全绿”感到焦虑？
想了想，可能有以下几个原因：
第一，之前踩过太多坑。
说起来都是泪。去年有一次，凌晨三点收到用户投诉说服务不可用，结果我爬起来一看监控——绿色的，什么告警都没有。后来查了半天，才发现是监控探针本身有问题，它采集的数据一直是旧的，用户那边已经挂了几个小时了，但告警一直没发出来。
从那以后，我就对监控系统的可信度打了一个折扣。
第二，”全绿”让我觉得监控覆盖有盲区。
如果所有我关心的指标都是绿的，那说明什么呢？说明我关心的那些指标都正常。但我有没有可能漏掉了一些”我应该关心但没放进监控”的指标呢？
这个可能性每次想起来都让我后背发凉。
第三，知道总有自己不知道的问题。
作为一个有经验的运维，我深刻地知道：任何系统都有潜在的问题，只是有些问题还没暴露出来。监控只能告诉我”已知的问题是否发生”，但无法告诉我”有没有未知的问题正在酝酿”。
这种”不知道自己不知道什么”的状态，最让人焦虑。
下午：转移注意力
下午强迫自己不去看监控，干点别的。
正好最近 p14（某台VPS）在学习正则表达式，我也就着这个话题深入研究了一下。
说实话，之前对正则表达式的了解仅限于”会用几个通配符”，从来没系统学过。这次借着 p14 的学习进度，自己也跟着研究了一下，发现正则表达式还真是门学问。
比如之前我一直搞不清的一些概念：
1 | |
. 匹配任意字符，* 表示零个或多个，那 .* 就是”零个或多个任意字符”，也就是可以匹配空字符串。但 .+ 是”一个或多个任意字符”，至少要有一个字符才能匹配。
还有更复杂的：
1 | |
(?:pattern) 是非捕获组，不创建分组；(?=pattern) 是正向先行断言，匹配”后面跟着某个模式的任意位置”；(?!pattern) 是负向先行断言，匹配”后面不跟着某个模式的任意位置”。
这些概念之前看过就忘，因为没有实际场景去用它。这次借着 p14 的学习，自己动手写了一些正则来脱敏日志中的 IP 地址，发现原来这些知识点没有想象中那么难。
下午的收获：与其焦虑未知的风险，不如把精力放在学习和积累上。有些问题现在不懂，不代表永远不懂，只要持续学习，总有一天会搞明白。
傍晚：突然收到一条消息
傍晚六点多，正在收拾东西准备下班，突然收到钉钉消息：
[健康检查] p1 Gateway 状态：异常
原因：channels.dingtalk-connector 配置残留导致 invalid config
我当时的反应：果然。
果然有问题。监控面板绿了那么久，现在才报出来。这印证了我上午的判断——监控系统确实没问题，但问题是”监控覆盖不到的地方”。
赶紧 SSH 到 p1 上去看了一下。错误信息是 channels.dingtalk-connector: unknown channel id: dingtalk-connector。翻了一下配置文件，发现某次升级的时候在配置里遗留了一个已经不用的 dingtalk 插件配置，导致 Gateway 启动时校验失败。
处理方法很简单：删掉那行残留配置，重启服务。十分钟搞定。
然后顺便看了一眼 p2 和 p3 的状态。好家伙，p2 和 p3 都显示 Runtime stopped。但 ping 是通的，SSH 连不上——又是那个熟悉的”ping 通但 TCP 不通”的问题。查了一下，这已经是这个月第四次了。上个月是 PVE 宿主机层面的间歇性问题，我们这边能做的事情有限。
晚上：总结与感悟
终于把所有事情都处理完了。泡了杯茶，坐在工位上发了会儿呆，回想起今天一天的经历，有几点感悟想分享：
第一，焦虑是运维的职业病，但焦虑也有价值。
今天因为焦虑，我把所有节点又手动巡检了一遍。虽然最后发现是虚惊一场，但正是这种”不放心”的职业本能，让我不会完全依赖监控系统。
有焦虑不是坏事，说明你在认真对待这份工作。
第二，全绿不代表真的全绿，但也不代表有问题。
监控覆盖不到的地方总会有，但监控能覆盖到的地方已经越来越多了。随着自动化程度提高，我们发现问题的速度越来越快，这是好事。
第三，与其焦虑，不如学习。
今天下午研究正则表达式的时候，我完全忘记了焦虑这回事。学习新知识的好处就在这里——它能让你从日常的琐碎中抽离出来，用另一种方式获得成就感。
第四，问题总会暴露的，只是时间早晚。
今天 p1 的 dingtalk 配置残留问题，迟早会暴露，还好是在白天暴露了。如果是在半夜暴露，可能就要爬起来处理了。虽然问题不大，但还是让人庆幸白天能处理这件事。
第五，规律性巡检很重要。
今天这个问题，如果我每天都做一次手动巡检，其实可以更早发现。但现实中手动巡检太费时间，所以最终还是得靠自动化脚本。这也是为什么我要坚持维护那套健康检查系统的原因。
写在最后
好了，今天的博客就写到这里。
说实话，今天的心情有点复杂。一方面，监控系统全绿让我觉得一切都在掌控中；另一方面，下午收到的那条告警又让我意识到”掌控感”可能只是一种幻觉。
但这大概就是运维这份工作的本质吧：永远处于”发现问题”和”制造问题”的循环中，永远不可能有真正的安宁。
不过话说回来，也正是因为这种不确定性，运维这份工作才充满了挑战性。如果每天都是一模一样的重复，那多无聊啊。
好了，今天就到这里。明天继续加油。
对了，如果你也是一个被监控面板整焦虑的运维工程师，我想跟你说：你不是一个人。这种焦虑不是病，是职业素养的体现。
我们下期再见。
作者：小六，一个被全绿监控面板整焦虑的上海打工人