本文收录于 云原生监控高可用集群 Thanos 架构剖析 | 内容合集 ，如有需要请查阅。

Thanos Sidecar 和 Thanos Receiver 是 Thanos 和 Prometheus 进行数据交互的两个核心组件，我们来看看这两个组件有什么区别，分别都是怎么使用的。

Thanos Sidecar

Thanos Sidecar 组件需要和 Pormetheus 实例一起部署，它主要起到两个作用，第一代理 Thanos Query 组件对本地 Prometheus 数据读取， 允许 Query 使用通用、高效的 StoreAPI 查询 Prometheus 数据。第二是将 Prometheus 本地监控数据通过对象存储接口上传到对象存储中，这个上传是实时的，只要发现有新的监控数据保存到磁盘，会将这些监控数据上传至对象存储。

详细来说就是：Thanos Sidecar 组件在 Prometheus 的 remote-read API 之上实现了 Thanos 的 Store API。这使得 Query 可以将 Prometheus 服务器视为时间序列数据的另一个来源，而无需直接与它的 API 进行交互。

因为 Prometheus 每 2 小时生成一个时序数据块，Thanos Sidecar 会每隔 2 小时将这个块上传到一个对象存储桶中。这样 Prometheus 服务器就可以以相对较低的存储空间运行，同时通过对象存储提供历史数据，使得监控数据具有持久性和可查询性。

但是这样并不意味着 Prometheus 可以完全无状态，因为如果 Prometheus 崩溃并重新启动，我们将失去大约 2 个小时的指标数据，所以 Prometheus 在实际运行中还是需要持久性磁盘的。如果想要接近无状态的的模式，或者 Prometheus 如果崩溃了，在理想的情况下只丢失数秒的监控数据，我们可以考虑使用 Thanos Receiver 组件，具体我们过会儿再看。

Thanos Sidecar 可以查看 Prometheus 的告警规则和配置，通过 Sidecar 模式连接 Thanos 集群的 Prometheus 服务器有一些安全操作的限制和建议:

• 推荐使用 Prometheus 版本是 2.2.1 或更高版本(包括最新版本)，这个只是一个底线，能用最新版本更好。这是因为之前版本中的 Prometheus 不稳定，并且 Prometheus 1.x 和 2.x 的数据存储结构都不一样。

• Prometheus 配置文件的 external_labels 部分在整个 Thanos 系统中具有唯一的标签。这些 external_labels 将被 Sidecar 和 Thanos 在许多地方使用。

• --web.enable-admin-api 参数设置为打开状态（enabled）支持 Sidecar 从 Prometheus 获取元数据，比如 external_labels 。

• --web.enable-lifecycle 参数如果设置为打开，那么可以使用 Sidecar 的重载特性。

如果你选择使用 Sidecar 将数据上传到对象存储:

• 必须通过 --objstore.* 相关参数指定对象存储

• 它只上传未压缩的 Prometheus 数据块。

• Prometheus 在启动的时候 --storage.tsdb.min-block-duration 和 --storage.tsdb.max-block-duration 这两个参数在设置的时候必须相等，以禁用本地数据压缩，这样 Thanos sidecar 才可以正常上传数据。否则 Sidecar 只暴露 StoreAPI 供 Query 查询，Prometheus 的和数据会在本地保留，不会上传到对象存储。这个默认值是 2h ，推荐使用。

Thanos Compactor 组件的在工作的时候，上边的两个参数必须设为相等的值，这样才可以保证 Thanos 在对数据进行压缩的时候不会损坏数据，维持数据的一致性。

将上边两个参数设置为相等后，你会发现 Prometheus 的内部指标 prometheus_tsdb_compactions_total 还在增加，不需要对这个产生疑惑，原因是 Prometheus 通过其内部压缩机制将初始头块写入文件系统，但是如果你在 Prometheus 加载数据之前使用了 Sidecar 模式，Prometheus 是不会修改数据。

Thanos sidecar 启动时会对 Prometheus 的参数设置检测，如果 Prometheus 启动时配置不正确，那么它会并记录错误或警告。

Prometheus 的本地保留时间建议不低于最小块持续时间的 3 倍，所以如果上边两个参数设置了是 2h ，那么本地建议保留 6 小时。这样结合对象存储就实现了数据的弹性使用，如果对象存储故障，那么还有本地的数据可以实时使用，并且故障恢复以后，之前没有上传的数据块会继续上传到对象存储中。

重新加载配置

如果 Prometheus 启动的时候使用了 --web.enable-lifecycle 参数 ，那么 Thanos 可以查看 Prometheus 配置的变化并重新加载 Prometheus 配置 。

可以通过 --reloader.rule-dir=DIR_NAME 参数配置监视哪个目录中的变化。

基本配置

下面是 Prometheus 启动的基本配置

prometheus \  --storage.tsdb.max-block-duration=2h \  --storage.tsdb.min-block-duration=2h \  --web.enable-lifecycle

下面是 Thanos Sidecar 的启动配置参数

thanos sidecar \    --tsdb.path        "/path/to/prometheus/data/dir" \    --prometheus.url   "http://localhost:9090" \    --objstore.config-file  "bucket.yml"

这两个结合，基本就可以正常工作了。

上传压缩块

如果是从一个纯粹的 Prometheus 实例迁移到 Thanos，并且必须保留历史数据，您那么可以使用标参数 --shipper.upload-compact。这样 Thanos 也会上传被 Prometheus 压缩的数据块。。

Receiver

Thanos Receiver 通过 thanos receive 命令实现了 Prometheus 远程写 API。它构建在现有的 Prometheus TSDB 之上，并保持其实用性，同时通过长期存储、水平可伸缩性和下采样扩展其功能。Prometheus 实例被配置为连续地向它写入度量，然后 Thanos Receiver 默认每 2 小时将时间序列格式的监控数据块上传到一个对象存储的桶中。Thanos Receiver 公开了 StoreAPI，以便 Thanos Query 可以实时查询接收到的指标。

我们推荐这个组件在这些场景使用，比如本次磁盘存储空间不足，或者网络有限制只能出不能进，在使用的时候要考虑使用的利弊。

Thanos Receive 通过使用标签支持多租户。Thanos Receive 支持通过远程写入来获取监控指标。

默认情况下，如果 --tsdb.max-exemplars 设置为 0 ，那么 exemplar 会被丢弃。所以可以把 --tsdb.max-exemplars 设为一个非零的值，会开始 exemplar 存储，它公开了 ExemplarsAPI，以便 Thanos Queriers 可以查询存储的范例。

对于 Thanos Receiver 来说，Prometheus 的 external label 也是重要的标签，用来对监控数据进行区分。

基本配置

首先我需要先启动 Thanos Receiver ，这样 Prometheus 才能知道数据该往哪里推送。

thanos receive \    --tsdb.path "/path/to/receive/data/dir" \    --grpc-address 0.0.0.0:10907 \    --http-address 0.0.0.0:10909 \    --receive.replication-factor 1 \    --label "receive_replica=\"0\"" \    --label "receive_cluster=\"eu1\"" \    --receive.local-endpoint 127.0.0.1:10907 \    --receive.hashrings-file ./data/hashring.json \    --remote-write.address 0.0.0.0:10908 \    --objstore.config-file "bucket.yml"

hashring.json 文件的内容大致如下：

[    {        "endpoints": [            "127.0.0.1:10907",            "127.0.0.1:11907",            "127.0.0.1:12907"        ]    }]

有了这样的配置，任何 receive 都监听 <ip>:10908/api/v1/receive 上的远程写入，并且如果需要进行租期和复制，将转发到哈希环中纠正一个。

Thanos Receiver 启动好以后，就可以在 Prometheus 的 配置里添加如下的远程写地址：

remote_write:- url: http://<thanos-receive-container-ip>:10908/api/v1/receive

这样 Prometheus 到 Thanos Receiver 的数据流转就可以正常运行了。

小结

对于 Thanos Sidecar 和 Thanos Receiver ，选择任何一个够可以构建集群，我认为，使用 Sidecar 来构建集群，对对象存储的可靠性要求可以低一些，极端条件下，对象存储挂掉一两个小时起来，Sidecar 会将之前没有上传的数据继续上传，并没有什么影响。就是 Prometheus 走到哪里都要带着这个 Sidecar 。

使用 Receiver，Prometheus 可以做到很轻量，数据都会实时写到对象存储中，对对象存储的可靠性和 Receiver 的稳定性要求较高。

同学们在生产环境中使用哪个组件可以自行评估。