事情是这样的，上周的一个早上阿粉高高兴兴的上班，刚到座位上早饭都还没来得及吃，就收到一条企业微信，是运维老大发来的，说有个服务 A 的 nginx 日志暴增。从平时的每天 133M 一下子暴增到 29G，看到这里突然想起来前一天刚好发过版本，一下子早餐也吃不下了，赶紧拿着电脑跑到运维那边排查问题。

首先找到对应服务 A 的 nginx 日志，通过 tail -f xxx.log 查看日志数据，发现日志里面输出最多的是对一个获取配置信息的接口的调用。这个接口是一个很简单的接口，就是加载数据库的数据存入缓存，然后对外提供接口访问，本身不存在业务逻辑。确定了接口以后，通过 nginx 日志看到请求都是来自一个核心的服务 B。

到这里基本上可以断定是服务 B 的逻辑有问题了，问题的方向已经确定下来了。定位了一下在服务 B 中调用了该接口的地方，总共有两处，一处是每五分钟调用一次，进行内存缓存，这块的逻辑是一直都有的，不会有问题;另一处是一个自定义的普罗米修斯的指标采集，普罗米修斯每 15 秒会进行一次数据的采集，这么一想那问题肯定是出在这里了。

看了一下逻辑，这块的代码是做了一个自定义的指标采集，用于在 Grafana 上面采集相应的数据，刚好生产上有 Prometheus 每 15 秒 Pull 一次数据，再加上生产环境的数据量较大，这段代码里面调用接口的逻辑写在了一个循环里面，从而导致了，每 15 秒会触发一次循环，每次循环的数据量很大并且每次都调用接口，并且服务 B 还是多实例部署，导致接口的调用次数暴增，从而引发了此次”血案“。

问题定位出来了，解决就比较简单了，将接口的调用从循环体内迁移到外面，方案做了一些变动，改完过后合并了一下代码，打了一个 tag，升级了其中一台服务器进行观察，发布完过后，整个接口调用的次数就下降了，观察了一会没有异常就全网了。

事后对这个问题做了一下复盘，事故的本身没有引起业务的异常，但是还好发现的早，不然每天产生如此大的日志量迟早会占满磁盘空间出事情。再深度复查一下发现接入普罗米修斯的这块自定义指标其实并没有实际使用价值，这块的逻辑前前后后改动过好多版本，但是没有一个最终的版本，不知道在哪个版本将代码提交上去了。这也体现出我们的版本规划是有问题的，很多需求前前后后经常变动和插入，没有严格的按照版本执行也是导致此次问题的一个重要原因。

这里也提醒一下大家一定要严格按照版本迭代进行开发和发布。不然哪天踩了这样的坑就比较尴尬了。

工作中难免会出现失误，但是有些失误能犯有些不能犯，每个程序员都会写出 bug，写出 bug 问题不大，但是能不能及时解决就很关键了。真正影响到线上业务的 bug，时间就是金钱，多消耗一分钟就损失一分钟的钱，有的时候一分钟的钱没多少，有的时候一分钟的钱足以倒闭一家公司。

所以我们每个程序员都应该要敬畏线上。

原文来自：

本文地址：//q13zd.cn/loop-statement.html编辑：圆蛋，审核员：逄增宝

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：