前面有两篇 blog 说了一下 influxdb,但是在实际使用过程中还是遇到了很多问题.
首先说说我使用的版本,最开始使用的是0.9.5.1-1,后面由于数据库卡死罢工了,重启 N 次无效后升级到0.10.x, 但使用了半天还是乖乖回到0.9版本,为什么会出现这种情况呢,我不知道,没那么多时间去看代码, boss 还盯着我干活呢,我只能把表象说出来,反正 influxdb 现在无法支撑我的业务,马上就要被砍掉了,接下来我会寻找新的Time Series Databases,在这篇 blog 最后我会简短的说一下我现在的面临的问题,如果有兴趣可以一起探讨.
坑1:并发效率不高
实测可以支撑500TPS 的 put 请求,再高的话,基本上到1000TPS 就开始不稳定了,话说这样一来小的监控,或者纯粹的 IDC 监控,用用倒也能满足要求,不过这里说的是纯插入,还没有说插的时候查询呢,那么往下看
坑2:查询会导致数据库假死
这不是耸人听闻,一般我对接 grafana 的时候我的默认时间跨度是三小时,这个时间段既能满足查询的效率,又能满足对指标的观测,但是这个是时候你手贱了一下,把时间跨度调整到了1d or 7d,那么数据库还是抽风,你能看到的是插入几乎全部超时, CPU 使用率只有5%不到,我看过 pprof, 全部 block 在storage 上, wal 也会被 block, 但这个时候的磁盘IOPS几乎也没有,就像大家都在等什么一样,反正就不工作了,所有请求都会超时,
接下来你去重启 influxdb, 你就发现这个时间段的数据都是一截一截的,不是连续的,我现在是跑单机的,最开始的时候跑集群的,集群问题更大,继续看下一个坑
坑3:分布式异步同步导致数据丢失
最开始的时候我设计的是3节点集群,都是物理机,高性能物理机,但在 leader 不重启的情况下好像每隔一段时间 Leader 就会换一个节点,我记得 raft 协议没有这一条啊,那么我只能怀疑在我睡觉的时候, influxdb 实现的 raft 也会打盹,但这个不影响我的数据,我倒也不在意,关键是出现坑2的时候, leader 的资源消耗一点都没有,但是去看两个 follower, CPU 都到了1000%多了,没错,那是一千,20core 的机器硬生生的被吃掉了一半,我还不知道它在干嘛,磁盘的 IOPS 也没什么,就是跑 CPU
接着我就重启 Leader 那个服务器,然后就开始选举,运气好,原来的 leader 启动起来了,被当选 leader, 数据就和坑2一样,间歇性丢失,运气不好,以前的 follower 当选了 leader, 结果丢的数据几乎要从异常时间开始再往前至少一刻钟,简直无法容忍了
使用建议
- 不要随便使用大跨度时间区间来查询
- 不要用集群,不要用集群,不要用集群,数据量太大,你可以选择部署多个实例,然后分别把不同的 datapoint 存储到不同的实例里面去
- 建立了database 以后,记得一定要修改
RETENTION POLICY,具体怎么改,这里给你一个传送门,自己看文档 - 如有可能最好在前端加上 nginx 做一层代理,缓存查询数据
- 做一个好人,线上程序出问题的可能就会降低很多,比如看完文章后点个赞赏,这玩意我整了好几天,还指着帮我分担一点云服务器的租金呢.
现在的实际情况
我现在是做了 nginx 的实时监控,在每个nginx 节点上安装了自己写的 agent. 然后在汇总到一个单点的 Server 下,现在每秒聚合的日志量在1w 条,用的是我早先开源的网络库,性能非常好,已经平稳运行了快一年了,没有宕机,没有异常,这个我还是非常满意的,
但是这么多的日子要全塞到 influxdb 里面,当然是做不到的,更何况公司的业务还在增长,所以我但是在 Server 端做了一个聚合,每5秒钟把聚合的数据再发到 influxdb, 就这样,有的时候 influxdb 还挂,但总体来说基本上还算可用,可以监控到线上业务或者 EndPoint 的异常,但是粒度非常粗,出了问题大家能看到是什么地方出了问题,然后再细致的去查.
接着,大家开始不满足了,需要我提供更详细的数据,例如哪个 URL 出错了(PS: 我们是 RESTFUL 的 API, 鬼知道有多少种,而且业务部门太多,我不可能知道每个线上 API 的 Style),所以现在需要考虑找一个更强悍的 Time Series Databases ,现在候选的 OpenTSDB, 但是初步试了一下,好像问题挺多的,如果大家有更好的时序数据库也可以介绍
今天说了挺多的,大概也就这样吧,写 blog 还是挺费时间的.
