prometheus的协助方案thanos

prometheus作为一站式监控方式（进程包含抓取，存储，sql查询等等功能）被大家广泛接受，如果作为一个短期或者一段时期的监控，他的功能非常齐全，在小规模的采集中，完全不需要依赖其他组件就可以达到监控的目的，这里说的是监控的目的，接入grafana那个是展示的部分。但是应对大集群，大数据量的情况，他的表现如何，需要我们带着这个问题分析一下。

prometheus的不足

• 弱集群化
  prometheus的方案和数据库类似，主要是水平的切割，例如1w的集群，10台prometheus抓取，那么一台prometheus负责抓取100个进程。可能有人会提出prometheus是有联邦模式的，集群的部署方式如下，为了保证高可用，一个进程的信息被两台或者更多的prometheus抓取，这样即使宕机了一台，其余两台可以继续工作。这里必须说明的是，这样的多活其实是多次抓取，算不上一个数据的同步过程了，因为3台prometheus抓取同一个进程3次，很可能是取到的是三个状态，有明显的ABA的问题，但是在监控中，这个是可以接受的，只要不是一直维护的状态，瞬间的变化并不会带来影响，典型的cpu飙高，1毫秒上升到90%然后下降，这个状态，是否能捕捉到并不影响我们诊断。最后多台prometheus相当于一个集群，用一个只读的prometheus去代理查询就可以了。这个集群的方案确实不是什么特别好的方案。
• 数据没有保障
  之所以说上面的方案不是一个很好的方案，是因为数据是分散在多台prometheus的。在变动或者长期存储的时候，他依赖了本地磁盘，这个是一个很严重的问题，本地磁盘并不是一个高可用的存储方案，他的数据变的没有保障。

thanos的功能补充

thanos的存在则补充了上面的一些问题。
thanos query 专业做查询调度的组件，角色相当于代理只读的prometheus。
thanos sidecar 接受query查询的载体，他有两个功能，一个是作为prometheus的代理，如果有查询过来，是通过 sidecar与prometheus进行交互，而不是直接和prometheus交互，另外一个是搬运prometheus的数据到高可用的文件系统里。
thanos compactor 可以做压缩和下采样，由于prometheus自身其实是有这种功能的，这个组件就相当于是一个集群环境下的一个专业的组件吧。
thanos store 这个组件相当重要，我们的数据存储到一个高可用的存储里的时候，prometheus是无法直接读取查询的，这样就必须出现一个可以读取高可用系统文件的角色，这就是store。query发起查询的时候，会给store和sidecar，在查询角度看store和sidecar都是一种可以返回结果的代理。

解决的方式

数据没有保障的问题，就是通过sidecar把他传送到高可用的存储系统里，这样就保障了数据的可靠性。
现在再来分析这个系统，集群化方案更完美了。prometheus主要变成了一个保存一段时间数据的载体。
thanos store是可以根据时间做分片的，我们现在看这个系统，就是根据时间分片，现在看整个时间的跨度，变成了多个store和一个sidecar。最终组成了整个时序的数据，数据已经有了横向和纵向的切割，水平方向分prometheus抓取，纵向分时间查询，这样就很好的保证了数据的量的减少，并且提高了数据查询的并行度，例如查询5天的数据，store可以变成1到2一个区间，3到5一个区间，查询的时候2个store可以同时工作查询，而且更好的利用compactor进行数据的压缩和下采样，让数据点更少了。数据最终汇集到query，query会进行整理和去重。
这里需要解释一下为什么要去重，prometheus的高可用主要靠的是多活，但是带来的一个问题是他的数据会被采集多分，我们要的只是一个进程的一个时间序列而已，并不需要重复的数据，例如三个prometheus就有会出现三个类似接近的时间序列，去重主要是应对这种状态的，还有就是store分割的有重复也会带来重复的数据，因为store是可以做相对时间的切分的，例如最近1d的数据，最近2d的数据，这就需要一个同步数据的过程，最好的做法就是边界都带上，保证在查询的时候不会因为大家的同步的程度不一样，导致边界的数据丢失的情况。