「技术干货」Thanos的架构剖析

作者/赵一晗

为了解决Prometheus缺少多集群监控的全局视图，以及对历史数据的存储问题，Improbable开源了他们的Prometheus高可用解决方法Thanos，Thanos与Prometheus无缝集成，并为Prometheus带来了全局视图和不受限制的历史数据存储能力。

Prometheus多集群监控方案

每个集群内部都部署一套单独的Prometheus，在通过Grafana等展示工具分别查看每个集群的资源监控情况，如果保证数据的高可用，则每个集群还需要一套数据备份方案以及历史数据存储方案。

Prometheus联邦

联邦实现

扩展单个Prometheus的采集能力和存储能力，多个Prometheus组成联邦，如下图所示：

最上面一层Prometheus是联邦节点，负责从下面的Prometheus中定时获取数据并汇总，部署多个联邦节点是为了实现高可用，下面一层的Prometheus负责不同区域的数据采集，在多机房的部署架构中，每个Prometheus又可以部署到单个机房，充当代理。这种架构不仅降低了单个Promtheus的采集压力，而且通过联邦汇聚核心数据，降低了本地存储的压力，为了避免下层Prometheus的单点故障，可以部署多套Prometheus节点，但是效率上会差很多，每个监控对象会被重复采集，数据会被重复保存。

联邦方案的不足

1. 这种架构配置相对复杂，缺少统一的全局视图；

2. 对历史存储问题仍未得到解决，必须依赖第三方存储，并且缺少针对历史数据的降准采样能力；

3. Prometheus在设计之初就是一款实时的监控系统。

Thanos

Thanos是一组组件，可以组成具有长期存储功能的高可用性Prometheus设置。其主要目标是简化操作并保留Prometheus的可靠性。Thanos依赖于Prometheus,且仅支持Prometheus2.0版本之后的数据格式。

Thanos的实现

Thanos架构图如下图所示，主要由四个组件组成：Querier、Slidercar、Store和Compactor。

Sidecar

每个Prometheus节点都配置了一个Sidecar组件，通过k8s的部署可以将Prometheus和Sidecar容器集成到一个容器中，Sidecar主要有两个作用和一个后来新增的可选功能，一是用来代理Querier对Prometheus本地数据的读取；二是将Prometheus本地的监控数据（一般是未压缩的块）通过对象存储接口保存到对象存储中，Sidecar每30s读取一次本地元数据，看是否有新的监控数据产生，如果有则读取本地数据块将其上传到对象存储，标记最新的读取时间并且通过本地的JSON文件保存相关信息，包含块的元信息，例如统计信息，时间范围和压缩机别，避免重复上传。还有一个可选功能， Sidecar可以查看Prometheus规则和配置，并在需要时解压缩和替换环境变量，并Ping Prometheus以便重新加载规则和配置。

Querier

Querier是Thanos实现多集群监控以及全局视图的关键。Querier接收HTTP的PromQL查询，组件负责数据查询汇聚，查询流程如下图：

简而言之，就是从基础StoreAPI收集评估查询所需的数据，评估查询并返回结果。Querier是完全无状态的并且可以水平扩展。Thanos Querier本质上允许在单个Prometheus Query端点下聚合和可选地对多个度量后端进行重复数据删除。对于Querier来说，后端是实现gRPC StoreAPI的所有内容，因此我们可以从任意数量的不同存储中聚合数据，例如：* Prometheus（需要包含Sidecar） * 对象存储 * 记录规则和警报规则 * 符合Promtheus远程读写的标准的数据库 * 另外一个Querier * 非Prometheus系统，例如OpenTSDB Querier不仅可以从多个后端获取数据，将他们汇总还可以对其中的重复数据删除，必须为整个集群选择固定的单个或多个副本标签，然后在启动时将其传递给查询节点。仅通过给定副本标签区分的两个或多个序列将合并为一个时间序列。这也掩盖了单个数据源收集方面的差距。

Thanos公开的查询API保证与Prometheus 2.x API兼容。但是，对于Prometheus之上的其他Thanos功能，Thanos添加了三个特色的功能：部分反应行为、部分新增的参数字段、自定义响应字段。

1. 部分反应

Querier可以从多个后端查询数据，当其中的一个StoreAPI返回错误或者超时，另两个返回成功结果（很可能出现），并不意味丢失数据，可能是因为出问题的StoreAPI没有查询到数据，则会汇聚有数据的查询返回。如果发生部分响应，则StoreAPI会返回可读的警告，现在支持两种策略：

2. 新增的部分参数

Deduplication replica labels

这将覆盖query.replica-label cli标志，以允许在查询时使用动态副本标签。

Deduplication Enabled

这控制是否应使用副本标签对查询结果进行重复数据删除。

Auto downsampling

最大源分辨率是我们要用于查询数据的最大分辨率（以秒为单位）。

0 -> we will use only raw data.

5m -> we will use max 5m downsampling.

1h -> we will use max 1h downsampling.

Partial Response Strategy

// TODO(bwplotka): Update. This will change to “strategy” soon as PartialResponseStrategy enum here

如果为True，则所有将不可用的StoreAPI（因此不返回任何数据）将不会导致查询失败，而是返回警告。

3. 自定义响应数据结构

type queryData struct {
ResultType promql.ValueType `json:"resultType"` Result  promql.Value  `json:"result"`


// Additional Thanos Response field.
Warnings  []error  `json:"warnings,omitempty"`
}

Store

Store在对象存储中的历史数据之上实现StoreAPI，使对象存储中的数据可以作为Querier查询的后端。Store主要有两个作用，一个在对象存储中数据实现StoreAPI，使对象存储中的数据可以被查询，二是充当一个API网关，可以负责所有StoreAPI的服务发现，因此Store不需要大量的本地磁盘空间。它在启动的时候加入Thanos集群，并发布它可以安全访问的数据。他在本地磁盘上保留有关所有远程块的少量信息，并使它与桶同步。通常，对象存储桶中存储的每个TSDB块平均需要6MB的本地磁盘空间，但是对于带有大标签集的高基数块，它甚至可以增加到30MB甚至更多。它用于预先计算的索引，其中包括符号和发布偏移量以及元数据JSON。

Store查询对象存储的历史数据时，查看对象存储中的所有数据，并根据查询的时间范围将其返回，将对象存储的数据转化为Querier所需的数据格式，并且Thanos Store –min-time，–max-time标志使您可以基于恒定时间或相对于当前时间的持续时间对Thanos Store进行分片。Thanos Store Gateway可能不会立即获取新块，因为时间划分部分是在异步块同步作业中完成的，默认情况下每3分钟完成一次。此外，某些对象存储实现还提供了最终的写后读一致性，这意味着Thanos Store可能不会立即获得新创建和上载的块。建议与Thanos Sidecar和其他Thanos Store网关有重叠的时间范围，因为这将提高您的故障应变能力。

Thanos Store Gateway支持索引缓存，以加快从TSDB块索引进行发布和系列查找的速度。支持两种类型的缓存：in-memory（默认）和memcached。

Compactor

Compator是一个批处理组件，主要针对对象存储的数据压缩，可以将历史的小对象（block，块）合并压缩成大文件对象，对其数据并且删除这些小文件，从而节省存储占用。通常，它在不是并发安全的， 必须针对存储桶以单例方式进行部署，并且由于没有针对所有对象存储提供的安全锁定机制，因此，您现在需要自己确保只有单个Compactor针对单个存储桶中的单个块流运行。

Compator是Thanos实现无限存储的关键组件。

Compator主要有两个作用，一个是负责对数据的压缩，另一个是负责历史数据的降准。

数据压缩

Compator负责将多个块压缩成一个，跟Prometheus中进行的减少块数和压缩索引的过程是一样的，根据时间以及数据量的不断增长，Compator将Sidecar上传的数据压缩成2h的块，然后在对历史数据再进行压缩，根据设定的步长倍数递增，如果步数为3、步长为3，则块的大小分别为2h、6h、18h。数据量继续增长，Compator会将小的block合成一个大的block从而节约空间，也便于对数据进行检索。

数据降准

对历史数据的检索需要用降准的方式进行：如果检索一天的数据，则通常以h或者10min中为维度；如果检索一个月的数据，则通常以d或者h为维度，因为，在浏览器渲染数据的时候，如果检索时间很长，维度很小，则代表着会有大量的数据，甚至会超过屏幕的像素显示上限，从而失去意义，且网络的IO消耗，接口响应时间也会很高，所以需要将数据进行降准。Thanos会将原始的监控数据降准汇聚，将初始30s为周期的监控数据经过两次压缩后，汇聚成以1h为周期的数据。第一次从30s进行10倍压缩到5m，在进行12倍压缩到1h，数据的降准比较简单，需要汇聚Count（个数） 、Sum、Min和Max。

Compator对资源的要求比较高，尤其是内存 CPU：提供压缩组时要使用的Goroutine数的核数内存：内存使用情况取决于对象存储中的块大小和压缩并发。通常，最大内存利用率与用于压缩过程的Prometheus完全相同：

对于考虑进行压缩的每个源块：所有块符号的1/32所有块的过帐偏移量的1/32具有所有标签和所有块的单个系列。您需要将此乘以X，其中X是–compaction.concurrency（所需要的Goroutine数量，默认情况下为1）。通常，对于中型存储桶，限制为10GB的内存足以保持其正常工作。

网络：Compator是对对象存储使用网络最多的组件，因此最好将其放在存储桶的区域附近。他必须要下载压缩/降准采样所需要的每个块，并在每次执行上传压缩/降准采样完成的块。还会经常刷新存储桶的状态。

磁盘：Compator需要本地磁盘空间来存储中间数据以进行处理，以及对存储桶状态缓存。通常，对于中型存储桶，随着压缩时间范围随着时间的增长，大约100GB应该足以继续工作。但是，这在很大程度上取决于块的大小。在最坏的情况下，压实机必须有足够的空间来容纳2个星期（如果您的最大压实级别为2周）的2倍的较小块来进行压实。首先，下载所有这些源代码块，其次是基于由较小的源代码 组成的2周块的磁盘输出。

您需要将此乘以X，其中X是–compaction.concurrency（默认情况下为1）。

Thanos的服务发现

Thanos的Querier会通过StoreAPI获取每一个Sidecar的数据，那么首先需要发现Sidecar，Thanos引入了Gossip，现在已经不推荐使用，现在推荐使用的有三种：

1.静态配置：配置在组件的配置文件中；

2.文件发现：将Sidecar的信息写到文件中，JSON或者YAML格式，然后通过监视文件列表中的文件变化，在发生更改时，将动态加载新配置，所有文件重新读取的间隔为5分钟；

3.DNS服务发现（推荐）：DNS服务发现是用于查找可以与静态标志或文件SD结合使用的组件的另一种机制。使用DNS服务发现，可以指定一个域名，并将定期查询该域名以发现IP列表。

Thanos支持的对象存储列表

Thanos实现无限存储的主要资源对象，就是对象存储，最好单例对象存储。Thanos将所有的历史数据都存储在对象存储中，减少Prometheus使用的本地存储，使Prometheus仅保存最近时间的数据，这样既节省了资源的消耗，也提高了Prometheus的效率。目前Thanos支持的对象存储有：

-End-