排查了一个线上服务不断扩容但是找不到扩容原因的问题

早上 OP 给我说有个线上服务在不停扩容，一天扩容了好多次，但是流量很平稳，不像是因为流量导致的。

看了下监控，发生扩容时的流量确实很稳定。那就只能是业务的某个请求导致的问题了。

发生扩容的时候 load 确实很高，一般都是一个请求堵住了，然后用户不停点，没做防刷，然后进程一堆积，load 自然就高上去了。

堵住了的话无非就是那么几个地方，数据库慢查询，或者因为网络抖动导致 MC 、REDIS 慢了，再有就是业务本身的问题。再看眼监控，所有的外部依赖都没有异常，加之发生扩容的只有这一个业务，那网络抖动也可以排除了。原因肯定是业务自己的了。

既然是业务本身的问题，那首先要定位到请求。利用一下 lb 日志，查一下扩容发生时有哪些大于 3s 的请求

域名 and request_time> 3 | select url_extract_path(request_uri) as p, count(1) as cnt group by p order by request_time desc

发现还不少，其实也很好理解，cpu 被抢占之后，所有请求都得不到足够的 cpu ，慢下来也正常，日志没什么帮助那怎么在不看源码的情况下分析一下根本原因呢。

首先我想确定一下是不是业务代码自身导致的问题，容器级的监控只能看到 pod 中的某个 container 在占用 cpu 。

但是别忘了，业务可以 fork 其他程序，想到这里，我就建了一个 process 监控，结果立即发现所有扩容的时候都存在一个 ffmpeg 进程，而且 cpu 占用都排在第一名，哈哈一下就定位到了，连源码都不需要看，马上反馈给业务方来处理一下。

笑死，如果一开始就有这个看板的话就不需要看那么多别的监控图了。

下面是恰饭时间，不喜欢的朋友可以略过了~

阿里云的 cms 配合 grafana 真的非常好用，不过很遗憾 aliyun cms 的插件已经很久没有更新了，angular 写的插件就要不能用了。于是这两天看了下 react ，搞了一个新的 cms 插件出来：aliyun-grafana-datasource 基础功能基本足够定位各种线上问题了。如果需要显示名称、报警和看板可以付费解锁~

另外搞了个交流群，收集一下插件的使用反馈，也可以交流遇到的各种奇怪问题，共同学习~

telegram：t.me/grafana_aliyun

QQ：864818512