文章目录
- 一.监控现状
- 二.Thanos原理分析
- Sidecar
- Querier
- Store
- Compactor
- 三.Sidecar or Receiver
- Thanos Receiver工作原理
- 四.分布式运维架构
一.监控现状
Prometheus是CNCF基金会管理的一个开源监控项目，由于其良好的架构设计和完善的生态，迅速成为了监控领域事实上的标准，尤其是在云原生领域。
Prometheus的优势有很多，服务自动发现，社区众多exporter基本涵盖了所有的开源软件，与k8s深度结合。对于一家小型公司，Prometheus够用了，足以应对所有监控需求。
但随着监控数据量的不断增多，Prometheus的局限性逐渐显现出来了：
- 扩展性差，Prometheus自身的TSDB是一个单机的数据库，不支持分布式
- 扩展性差的第二个方面在于Prometheus对大量metrics的数据分析能力很差，内存使用 量成线性增长
- Prometheus不支持降采样，单机存储捉襟见肘
Prometheus社区也意识到了这个问题，因此推出了prometheus高可用的解决方案—Thanos
二.Thanos原理分析
分层是一个很好的思想，如果划分一层解决不了的问题，利用分层的思想能将复杂问题化整为零。
长短期指标分离：短期指标用来提供给告警系统高频查询近期数据，长期指标用来提供给人查询时间集。
Thanos架构图如上图所示，主要由四个组件组成：Querier、Slidercar、Store和Compactor。
Sidecar
每个Prometheus节点都配置了一个Sidecar组件，通过k8s的部署可以将Prometheus和Sidecar容器集成到一个容器中，Sidecar主要有两个作用和一个后来新增的可选功能，一是用来代理Querier对Prometheus本地数据的读取；二是将Prometheus本地的监控数据（一般是未压缩的块）通过对象存储接口保存到对象存储中，Sidecar每30s读取一次本地元数据，看是否有新的监控数据产生，如果有则读取本地数据块将其上传到对象存储，标记最新的读取时间并且通过本地的JSON文件保存相关信息，包含块的元信息，例如统计信息，时间范围和压缩机制，避免重复上传。
Querier
Querier是Thanos实现多集群监控以及全局视图的关键。Querier接收HTTP的PromQL查询，组件负责数据查询汇聚，查询流程如下图：
简而言之，就是从基础StoreAPI查询所需的数据返回结果。Querier是完全无状态的并且可以水平扩展。Thanos Querier本质上允许在单个Prometheus Query端点下聚合和可选地对多个度量后端进行重复数据删除。对于Querier来说，可以整个Store API的所有内容，因此可以从任意数量的不同存储中聚合数据，例如：* Prometheus（需要包含Sidecar） * 对象存储 * 记录规则和警报规则 * 符合Promtheus远程读写的标准的数据库 * 另外一个Querier * 非Prometheus系统，例如OpenTSDB Querier不仅可以从多个后端获取数据，将他们汇总还可以对其中的重复数据删除，必须为整个集群选择固定的单个或多个副本标签，然后在启动时将其传递给查询节点。仅通过给定副本标签区分的两个或多个序列将合并为一个时间序列。这也掩盖了单个数据源收集方面的差距。
Store
Store在对象存储中的历史数据之上实现StoreAPI，使对象存储中的数据可以作为Querier查询的后端。Store主要有两个作用，一个在对象存储中数据实现StoreAPI，使对象存储中的数据可以被查询，二是充当一个API网关，可以负责所有StoreAPI的服务发现，因此Store不需要大量的本地磁盘空间。它在启动的时候加入Thanos集群，并发布它可以安全访问的数据。他在本地磁盘上保留有关所有远程块的少量信息，并使它与桶同步。
Compactor
Compator是一个批处理组件，主要针对对象存储的数据压缩，可以将历史的小对象（block，块）合并压缩成大文件对象，对其数据并且删除这些小文件，从而节省存储占用。
Compator是Thanos实现无限存储的关键组件。
Compator主要有两个作用，一个是负责对数据的压缩，另一个是负责历史数据的降准。
三.Sidecar or Receiver
Thanos支持两种方式与Prometheus集成：Sidecar和Receiver
Thanos Sidecar工作原理
如上图所示，为了实现高可用，Prometheus实例与sidecar组件一起运行，sidecar每隔一段时间抓取prometheus数据，存储在对象存储中。此外Sidecar在Prometheus的远程读API上实现了Thanos的Store API,从而可以从Thanos Queries组件中查询Prometheus的数据。因此 Queries组件在Store API中查询历史数据，最新未上传数据可通过Sidecar查询下层Prometheus数据。
Thanos Receiver工作原理
Receiver 是作为一个单独的 StatefulSet 来运行的，在这种方法中，Thanos 的所有其他组件都以与 Sidecar 方式相同的方式存在和运行，但 Receiver 取代了 Sidecar 组件，TSDB 的查询和传输到对象存储的方式发生了巨大的变化。
Receiver 组件实现了 Prometheus 的远程写 API，直接接收 Prometheus 的数据，Receiver 将数据上传到对象存储 Bucket 中去，并且也有自己的保留期，Querier 被配置为通过 Store 查询 Receiver 和存储桶上的数据。
Receiver 则是基于 push 的模式，TSDB 由 Prometheus 实例本身远程写入到 Receiver，从而使 Prometheus 最接近无状态。然后数据从 Receiver 进一步上传到对象存储。
结论：具体应该选用哪种类型，要根据具体的业务场景：如果Sidecar数量非常多且Sidecar距离Queries比较远，每次查询Querise都会调用Sidecar，会消耗很多资源，并且速度很慢，而我们看监控大多数都是看最新的数据。
而Receiver模式下，数据实时push到Receiver组件中，Querise组件无需去sidecar中查询最新数据了。但这种模式下大量的数据汇总到Receiver组件，也会增加Receiver的压力，需要给Receiver较多的计算和存储资源。当然设计这个组件时肯定会考虑这个问题，Receiver 实现了一致性哈希，支持集群部署，所以即使规模很大也不会成为性能瓶颈。
没有完美的方案，具体应用哪种模式，需要我们压测和取舍。
四.分布式运维架构
上一节我们了解了Thanos的力量和能力，总结一下：Thanos提供了可靠、低成本的规模化历史数据存储，在上层提供了统一的全局查询视图，通过降准采样特性满足长时间范围的数据查询分析，全局的告警规则。特别适合集团—子公司这种数据架构的应用场景
注意⚠️：Thanos的每个组件都可以部署多个副本，实现高可用
我们通过架构图描述整个的监控架构
Thanos部署实战可参考：
http://www.dockone.io/article/10053
https://blog.csdn.net/csdnzxm/article/details/120279085
参考文档：
http://dockone.io/article/9988
http://dockone.io/article/6019
https://mp.weixin.qq.com/s/YFx1cY5IsrcHzXFEEu8Z6A
https://zhuanlan.zhihu.com/p/383969247
https://blog.csdn.net/csdnzxm/article/details/120279085
https://blog.csdn.net/u012140251/article/details/121454958
