influxdb continuous queries(cq)从入门到放弃
< 返回列表时间: 2019-10-22来源:OSCHINA
从前一篇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,而且内存占用跑批前后基本无变化。
如下是开发的跑批日志页面,如果出现跑批失败,还可以进行重跑。
热门排行