prometheus的高可用

prometheus作为一个监控的一套方案，他的集群方案确实不好想的。因为他是无状态的。

opentsdb

opentsdb的后台是hbase，他的集群方案可以依赖hbase的集群方案，hbase依赖hdfs,从而做到了他的存储的考可用性。
hbase有hmaster和region,他们是通过zk来互相做交互通知的，zk里有region的切割情况的信息，hmaster可以通过zk的数据，知道存储的情况，及时的做切分，做到压力的分散。region的存活也是通过zk的session的机制做的，zkclient创建临时节点，只要watch临时节点的事件，就可以在进程死掉后获取到或者的状态。
通过上面的简单叙说，我们大概理解了他的集群的实现方式。
首先是最上层是zk，做一些基本信息和存活信息的保存。
然后是管理节点hmaster，可以通过和zk的交互，得到活着的region的信息，并且可以根据状态做故障的处理。
最后是regionserver，其实层次上hmaster和regionserver是同一层，都是在zk配置中心的下面，只是两个的职责有不同，regionserver主要是用来接收数据并且做数据交互的。他会受到hmaster的管理。

prometheus

prometheus自身并没有这样的概念，也就是无人管理的状态，作为一个无状态的存在，我们应该考虑他的特点，那就是进程的能力都是一样的，虽然给的抓取配置是不同的，但是进程都是存储和抓取的能力。
如果做一下类比，相当于regionserver的角色，regionserver每个进程管理的region是不同的，但是他们的主要功能都一样。
如果没有管理者， 那么大家都不知道每个prometheus的状态。其实很麻烦了。我们大概率会想到数据库，数据库的集群也是一样的。他每个进程的能力都是一样的，当然他也有代理的中间件做分库分别。但是从集群的角度看，他做的主要是主备的方案，就是每一台数据库有主和备，备是同步主的信息的，当主宕机后，切换到从库，依旧可以获取到数据。

主备的prometheus

我们的思路也慢慢偏向了数据库的集群方式，毕竟在无状态的进程上开发状态其实开发量还是蛮大的。
选择了主备的方向，那我们的继续考虑数据的问题，数据库的数据是推送的，是客户端推送给数据库的。prometheus则是拉取的，二期是监控数据，我前一篇文章特别讲过，拉取的数据都必须是有不可变性的或者采样性质的。
这里我们也立马想到一个点，例如cpu使用率，一台prometheus采集的时候是50%，另外一台采集的时间不同，延迟1秒，变成了49%。这个对我们有影响吗？没有，因为他反应的都是真实的情况，时间相差不大，这就是好处，我们可以把数据抓取两份，而不是搞同步。

为什么数据库可以同步

数据库一般不会说数据推送到两个库，都是同一个库同步到另外一个库。大家肯定可以想到，如果主宕机了，备启用以后，肯定还少一部分数据，数据的一致性如何保证呢？一般是加缓存。查询的时候先看缓存，没有再看数据库，只要缓存的数据有最新的一部分，那么整体运行是正常的。
这个对业务是可以的，但是对prometheus就不适用了，因为他是采集程序，都是时序的数据。这个数据量太大了，不是说加个redis就能解决的。
而且查询的时候，缓存部分的运算是有限的，时序数据库有丰富的运算，这个是缓存达不到的，这也是为什么不用缓存区补数据的原因。

小结

• prometheus是主备方案
• 多次抓取而不是同步数据
• 时序数据库的能力和缓存不一样，但是数据库的能力和缓存是类似的。