Thanos，一组通过跨集群联合、跨集群无限存储和全局查询为Prometheus 增加高可用性的组件。

基本功能

prometheus单点能够支持百万的metrics，但是在规模越来越大的系统中，已经不能满足要求，需要集群的功能来处理更加庞大的数据，基于这个情况，thanos诞生了，thanos的主要功能：

  1. 去重，单点问题，可以让prometheus高可用，实现多采集情况下的数据查询，query是无状态的，可以使用负载均衡
  2. 聚合，实现不同prometheus的数据的聚合，匹配prometheus的hashmode功能，实现集群的方式
  3. 数据备份，主要是基于s3的，相当于远程存储，我们没有使用，直接将数据写入到了kafka

基本组件

Sidecar

Sidecar作为一个单独的进程和已有的Prometheus实例运行在一个server上，互不影响。Sidecar可以视为一个Proxy组件，所有对Prometheus的访问都通过Sidecar来代理进行。通过Sidecar还可以将采集到的数据直接备份到云端对象存储服务器。

Querier

所有的Sidecar与Querier直连，同时Querier实现了一套Prometheus官方的HTTP API从而保证对外提供与Prometheus一致的数据源接口，Grafana可以通过同一个查询接口请求不同集群的数据，Querier负责找到对应的集群并通过Sidecar获取数据。Querier本身无状态的也是水平可扩展的，因而可以实现高可部署，而且Querier可以实现对高可部署的Prometheus的数据进行合并从而保证多次查询结果的一致性，从而解决全局视图和高可用的问题。

Store

Store实现了一套和Sidecar完全一致的API提供给Querier用于查询Sidecar备份到云端对象存储的数据。因为Sidecar在完成数据备份后，Prometheus会清理掉本地数据保证本地空间可用。所以当监控人员需要调取历史数据时只能去对象存储空间获取，而Store就提供了这样一个接口。Store Gateway只会缓存对象存储的基本信息，例如存储块的索引，从而保证实现快速查询的同时占用较少本地空间。

store和sidecar都提供了相同gprc的api，给外部client进行查询，其实是一回事。

Comactor

Compactor主要用于对采集到的数据进行压缩，实现将数据存储至对象存储时节省空间。单独使用，和集群没有什么关系。主要是将对象存储 Bucket 中的多个小 的相同的Block 合并成 大 Block

基本使用

sidecar

sidecar部署在prometheus机器上,直接使用二进制文件配置不同的启动参数来启动

/opt/promes/thanos-sidecar/thanos sidecar --log.level=debug --tsdb.path=/data --prometheus.url=http://localhost:9099

query

query用于查询，单独部署，然后和prometheus一样使用

/opt/promes/thanos-query/thanos query --query.timeout=15s --store.response-timeout=15s --log.level=debug --store=10.243.53.96:19091 --store=10.243.53.100:19091 --store=10.243.53.101:19091 --store=10.243.53.186:19091

sd

thanos有三种sd的方式

  • Static Flags

    最简单的就是在参数中配置列表，就是我们上面使用的方式

    –store参数指定的是每个sidecar的grpc端口，query会根据–store参数列表找到对应的prometheus进行查询，所有组件的端口都是有默认值的，如果需要修改则指定参数

    Component Interface Port
    Sidecar gRPC 10901
    Sidecar HTTP 10902
    Query gRPC 10903
    Query HTTP 10904
    Store gRPC 10905
    Store HTTP 10906
    Receive gRPC (store API) 10907
    Receive HTTP (remote write API) 10908
    Receive HTTP 10909
    Rule gRPC 10910
    Rule HTTP 10911
    Compact HTTP 10912

  • File SD

    –store.sd-files=和 –store.sd-interval=<5m>来获取对应的prometheus列表

  • DNS SD

    –store=dns+stores.thanos.mycompany.org:9090 –store=dnssrv+_thanosstores._tcp.mycompany.org –store=dnssrvnoa+_thanosstores._tcp.mycompany.org

基本原理

Thanos 在每一台 Prometheus 服务器上运行一个sidecar组件，并提供了一个用于处理 PromQL 查询的中央 Querier 组件，因而在所有服务器之间引入了一个中央查询层。这些组件构成了一个 Thanos 部署，并基于 memberlist gossip 协议实现组件间通信。Querier 可以水平扩展，因为它是无状态的，并且可充当智能逆向代理，将请求转发给sidecar，汇总它们的响应，并对 PromQL 查询进行评估。

实现细节

  1. Thanos 通过使用后端的对象存储来解决数据保留问题。Prometheus 在将数据写入磁盘时，sidecar的 StoreAPI 组件会检测到，并将数据上传到对象存储器中。Store 组件还可以作为一个基于 gossip 协议的检索代理，让 Querier 组件与它进行通信以获取数据。
  2. 我们使用基本的过滤器（基于时间范围和外部标签）过滤掉不会提供所需数据的 StoreAPI（叶子），然后执行剩余的查询。然后将来自不同来源的数据按照时间顺序追加的方式合并在一起。
  3. Querier 组件可以基于用户规模自动调整密度（例如 5 分钟、1 小时或 24 小时）
  4. StoreAPI 组件了解 Prometheus 的数据格式，因此它可以优化查询执行计划，并缓存数据块的特定索引，以对用户查询做出足够快的响应，避免了缓存大量数据的必要。

  5. 我们通过为所有 Prometheus+ sidecar实例提供唯一的外部标签来解决多个边车试图将相同的数据块上传到对象存储的问题，例如：

    First:

"cluster": "prod1"

"replica": "0"

Second:

"cluster":"prod1"

"replica": "1"

    由于标签集是唯一的，所以不会有什么问题。不过，如果指定了副本，查询层可以在运行时通过“replica”标签进行除重操作。

  6. Thanos 还提供了时间序列数据的压缩和降采样（downsample）存储。Prometheus 提供了一个内置的压缩​​模型，现有较小的数据块被重写为较大的数据块，并进行结构重组以提高查询性能。Thanos 在Compactor 组件（作为批次作业运行）中使用了相同的机制，并压缩对象存储数据。Płotka 说，Compactor 也对数据进行降采样，“目前降采样时间间隔不可配置，不过我们选择了一些合理的时间间隔——5 分钟和1 小时”。压缩也是其他时间序列数据库（如 InfluxDB 和 OpenTSDB ）的常见功能。

遇到的问题

  1. 查询速度较慢，在数据量基本特别大的时候，查询会超时。
  2. thanos 目前还不能支持默认查询lookback时间，promehteus可以设置默认查询时间，thanos默认是根据规模自动调整的，目前发现有10m，20m等，这边可以暂时表达式加时间处理这个问题。
  3. sidecar的启动参数–cluster-peers是什么作用

扩展

在prometheus的聚合和集群发展中，出现了很多的相同的项目，大部分都是使用了远程存储的概念，比如cortex，M3DB，victoriametrics，thanos在调研落地的过程中，各方面还是相对做到比较好的，适合做为prometheus的扩展和聚合方案。

2019.9.9

victoriametrics在存储和查询上更加的优秀，目前比较推荐victoriametrics。