手记

thanos的数据切分的坑

thanos作为一个解决prometheus各种不足的组件,功能上已经是比较强大了,而且针对prometheus的缺陷进行了补充和完善的方案。今天主要说一下他对prometheus存储的补充和坑点。

prometheus的存储模式

prometheus有两种方式对数据进行存储,一种是直接存储到本地磁盘,一种是远程写。远程写可以写opentsdb等。就是把抓取的数据全部写到远程的时序数据库。
本地存储的主要问题就是机器的磁盘有限,而且并不是分布式的存储,有单点故障的问题。
远程写的问题是写的速度要慢,尤其是写到opentsdb这种分布式数据库(底层是hbase)。他需要做多副本,所以写的速度要远比本地磁盘慢。

thanos是解决方式

thanos 做了一层抽象存储的方式进行了优化,解决了速度的问题,也解决了单点故障的问题。

qurey query
store sidecar
ceph prometheus
其余时间数据 7d

prometheus从上往下表示了层级结构,query可以代理所有的查询,他可以从两部分进行数据的查询,一部分是代理prometheus的sidecar,一部分是代表高可用存储的store(store本身会加载索引到store的本地的机器)。
prometheus存储一段时间的数据,例如上图的7d。超多7d的数据就丢弃掉。ceph里存储所有的数据,数据是sidecar存prometheus里直接搬运到ceph的。这里搬运的是块,算是批处理的处理数据,这个解决了远程写慢的问题,查询的实时性则是需要prometheus和ceph同时出数据,最后做一次合并处理。例如查13d的数据,sidecar 2h同步一次数据,那么prometheus里可以查到最近7d的数据,ceph里存储的数据只差最近2h的,query会发起查询store从ceph获取最近2小时到13d的数据,promethes会提供,最近7d的数据,最后在query里进行去重处理,最后整合出最近13d的数据。
单点的问题的解决则是通过promethues双活的机制实现的。

thanos的坑

在上面的方案,可以明显的感到一个问题,就是所有的数据都存放在ceph,随着数据越来越多,查询肯定会越来越慢。
prometheus现在提供了一个compactor组件来处理这个事情,他有两个功能,一个是做压缩,就是把旧的数据不断的合并。另外一个是降采样,他会把存储的数据,按照一定的时间,算出最大,最小等值,会根据查询的间隔,进行控制,返回采样的数据,而不是真实的点,在查询特别长的时间的数据的时候,看的主要是趋势,精度是可以选择下降的。
通过以上的方式,有效了优化了查询,但是并不是万能的。毕竟数据可以再增长,一直可以增长到他查询变慢。
这里就需要考虑业务了,我们需要对业务有一定的估算,例如存储ceph的时候不同的业务存储在不同bucket里。做数据的水平切割,例如有5个bucket,我们准备5个store进行代理查询。
事先规划是比较好的方案,否则的话就只能选择数据的拆分,这个就相对比较麻烦了,数据的搬运也是一个很耗时的操作。
第二个方案是时间切片,现在thanos的分支里有一个时间切片的分支,就是store可以选择查询多长时间的数据。支持两种表达,一种是基于相对时间的,例如3d前到5d前的。一种是基于绝对时间的,19年3月1号到19年5月1号。例如想查询3个月的数据,一个store代理一个月的数据,那么就需要3个store来合作。

小结

针对存储的问题,最好是可以有效的规划,在存储上做到数据的拆分。当数据达到一种级别后,可以选择store做时间的切片,当时间切片也不能满足的时候,就需要考虑数据存储的再次拆分,或者说有合理的删除策略,保证数据不会一直无限变大。

0人推荐
随时随地看视频
慕课网APP