记一次prometheus监控服务器cpu飙升的事件

背景： 公司的promethes监控系统为单机，数据存在本地，告警也通过本地服务器实现
问题点：有一次下午，突然出现了prometheus服务器的cpu过高的告警，然后过一会又突然好了，
当时就没怎么注意。但是后续的几天陆陆续续还是会出现监控服务器cpu告警的情况，并且是cpu持续飚高，软重启和硬重启prometheus都没有用，于是开始重点排查。

排查点1： 检查各个target，把连接状态异常的target都从配置中取消，取消后cpu就降下来了，但是后续仍然出现了cpu告警，说明根本原因不是这个。
排查点2：检查grafana下各个dashboard下的查询视图中的语句，将性能比较低的泛查询都优化一遍，增加标签过滤，仍然无效。

排查点3： 检查系统/var/log/messages日志，发现每次cpu飙升前后都会出现grafana-server的错误日志
类似于error="http: proxy error: context canceled"，然后也发现基本的都是同一个dashboard报的错，并且是在查询周期大于等于24h的时候cpu必然飙升，由此初步定位出告警的根源可能是这个dashboard下存在异常
排查点4： 重点排查这个dashboard下的查询语句，于是开始修改各项设置参数，比如这种语句topk(3, histogram_quantile(0.99, sum(rate(db_thread_msg_latency_bucket{app=~"$app",instance=~"$instance",job=~"$job"}[2m])) by (le, opertaion)))原来是top10，可能现在就改成了top3了，修改完后仍然不奏效。

排查点5： 查看资料，网上各种资料基本原因包括’优化查询’，‘降低group by的条数’，'增加配置’等几种，由于这个prometheus系统以前从未出现过此类cpu飙升的问题，所以我认为不至于就加了几条新查询就导致了这个问题，于是我开始修改各项dashboard参数，并且我发现有几个数据视图右上角’刷新图标’一直处于刷新的状态，所以我感觉可能就是这个视图的原因，但是这里面的查询语句已经相当优化了，不可能再次被精简优化，所以我就尝试调整dashboard下的刷新间隔，由原来的5s修改为30s，这么一修改后，cpu就降下来了，由此基本确定了问题就出在这里了，于是我将这个dashboard下的最小刷新时间改为了30s，这样就能避免此类问题再次出现了。

回顾问题点：
1.有些查询语句由于返回的数据较多，因此计算时间可能会超过5s，如果没有人为点开grafana-server是不触发问题的
2.当人为点开grafana-server的时候，一旦刷新时间设置为5s，那么这个视图就会一直刷新，并且持续占有大量的cpu，由此就导致了cpu持续飙升。