从前一篇influxdb的文章 prometheus基于influxdb的监控数据持久化存储方案 完成之后，就一直在折腾influxdb发布测试和生产环境的问题，经过接近2个月的验证，最终发现使用influxdb自带cq的方案对存储的io要求挺高的。
为什么会说cq对io要求高？是因为进行方案验证时，均是在集成测试和测试的openstack controller节点上进行的测试，刚好这几台主机是配的ssd，非常愉快就完成了POC。但是上线的时候，测试环境申请的openstack的虚拟机，结果发现influxdb一会儿就会重启，重启原因就是influxdb报出oom的异常，同时也有“engine: error syncing wal”的异常 # Aug 14 18:37:08 sz680961 influxd: fatal error: runtime: cannot allocate memory Aug 14 18:37:05 sz680961 influxd: ts=2019-08-14T10:37:05.227282Z lvl=info msg="Write failed" log_id=0HFvsoi0000 service=write shard=14 error="engine: error syncing wal"
当时没有想到是io问题导致的，又在controller上建了相同内存32G的influxdb docker进行同时测试，发现以前的测试数据并没有问题，分析差异主要是磁盘io，原因可能是openstack虚拟机使用ceph磁盘，io和本地ssd相差了几个量级，导致cq执行时有大量数据缓存在数据库中，同时又有大量数据插入io响应不过来，最终用完可用的操作系统内存导致进行崩掉。
临近上线，没有更好的方案只能硬着头皮上线，主要原因是1. 生产环境数据比测试环境数据量少，2.如果cq执行还是要导致influxdb崩溃，就先把cq关闭。
就这样留着缺陷上线，观察了一个月偶尔还是存在influxdb oom重启的情况，估计和vmware集群整体的io压力有关。
生产环境的数据量会逐渐增大，这样下去肯定不是办法，但如果不进行降频又满足了长时间存储监控数据的需求，经过新一轮设计和poc制定了变化相对较小的方案： 关闭influxdb cq 自行研发跑批python，主要变化就是将cq中一次性加载和计算所有measurement中数据修改为自行控制，依次执行measurement的降频sql

经过poc验证在使用ssd情况下，相同数据量由原cq需要4分钟降低为只需要是30s，而且内存占用跑批前后基本无变化。
如下是开发的跑批日志页面，如果出现跑批失败，还可以进行重跑。