prometheus远程写之thanos receive模块

朱雀 2022-12-02 04:30 46阅读 0赞

## 背景 ##

起初（大概2020上半年之前）使用thanos作prometheus分布式监控方案的时候，thanos receive模块还在试验阶段，当时是使用的thanos sidecar方式。现在此功能模块已经被社区正式接受，功能会相对稳定了，因此，考虑部分场景使用receive模块替换sidecar。

## 目标 ##

通过使用receive模块，期望做到：

*  收拢分散的prometheus采集数据，减少sidecar数量（如果thanos query后面挂过多sidecar会影响性能）
 *  尽可能减少采集prometheus实例本地存储数据量，使重启、故障恢复时间更短

## 架构介绍 ##

架构图

+
    Tenant's Premise | Provider Premise
                     |
                     |            +------------------------+
                     |            |                        |
                     |  +-------->+     Object Storage     |
                     |  |         |                        |
                     |  |         +-----------+------------+
                     |  |                     ^
                     |  | S3 API              | S3 API
                     |  |                     |
                     |  |         +-----------+------------+
                     |  |         |                        |       Store API
                     |  |         |  Thanos Store Gateway  +<-----------------------+
                     |  |         |                        |                        |
                     |  |         +------------------------+                        |
                     |  |                                                           |
                     |  +---------------------+                                     |
                     |                        |                                     |
    +--------------+ |            +-----------+------------+              +---------+--------+
    |              | | Remote     |                        |  Store API   |                  |
    |  Prometheus  +------------->+     Thanos Receiver    +<-------------+  Thanos Querier  |
    |              | | Write      |                        |              |                  |
    +--------------+ |            +------------------------+              +---------+--------+
                     |                                                              ^
                     |                                                              |
    +--------------+ |                                                              |
    |              | |                PromQL                                        |
    |    User      +----------------------------------------------------------------+
    |              | |
    +--------------+ |
                     +

## 功能说明 ##

### 负载分发（Load Distribution） ###

为了支持多台机器的扩展，时间序列将被分发到不同的receiver上。receiver是通过hash的方式来实现时间序列的持续分发的。每个receiver在hashring中的位置决定了哪些时间序列被哪个receiver接收和存储。

remote write api过来的请求，经过receiver前面的负载均衡，然后请求随机落到receiver节点上。这时，会计算时间序列标签的哈希值。另外，考虑到对于量很大的时间序列，不希望全都分发大某一个receiver节点上，通过参数`--receive.tenant-header`指定的tenant ID（如果没有指定，默认为空字符串）也会用在hash值的计算中。大致的hash计算方式如下：

hash(string(tenant_id) + sort(timeseries.labelset).join())

如果receiver节点接收到的请求计算出来的hash值不是分发到当前节点，当前receiver会把他分发到该去的那个receiver节点。  
这个路由的功能本可以作成一个独立的模块，但是考虑到为了便于部署，这个功能是直接集成在receiver中了。

Soft tenant hashring
                                     +-----------------------+
                                     |                       |
    +-----------------+              |  +-----------------+  |
    |                 |              |  |                 |  |
    |  Load Balancer  +-------+      |  | Thanos receiver |  |
    |                 |       |      |  |                 |  |
    +-----------------+       |      |  +-----------------+  |
                              |      |                       |
                              |      |                       |
                              |      |  +-----------------+  |
                              |      |  |                 |  |
                              +-------->+ Thanos receiver +-----------+
                                     |  |                 |  |        |
                                     |  +-----------------+  |        |
                                     |                       |        |
                                     +-----------------------+        |
                                                                      |
                                       Hard Tenant A hashring         |
                                     +-----------------------+        |
                                     |                       |        |
                                     |  +-----------------+  |        |
                                     |  |                 |  |        |
                                     |  | Thanos receiver +<----------+
                                     |  |                 |  |        |
                                     |  +-----------------+  |        |
                                     |                       |        |
                                     |                       |        |
                                     |  +-----------------+  |        |
                                     |  |                 |  |        |
                                     |  | Thanos receiver +<----------+
                                     |  |                 |  |
                                     |  +-----------------+  |
                                     |                       |
                                     +-----------------------+

### 多副本（Replication） ###

thanos receiver支持复制接受到的时间序列到hashring中的其他receiver。副本数由参数`--receive.replication-factor`来指定。如果被接收的时间序列，没有写入到`(副本数+1)/2`节点数（即要达到副本数半数以上），receiver将返回错误。

例如，要存储3份时间序列的副本，则hashring中至少要有2个目标thanos receiver才行；并且，需要receiver配置此参数：`--receive.replication-factor=3`。

### receiver节点的缩容/扩容/失败场景 ###

当发生扩缩容的时候，由于hashring发生变化，所有的节点需要将write-ahead-log的数据flush到TSDB块并上传到OSS中（如果配置了的话），因为这些节点之后将有一个新的分配。之前已存在节点上的时间序列不需要作调整，只是后面过来的请求按新的分发来寻找该去的receiver节点。  
注意，这种情况发生的flush可能会产生较小的TSDB块，但thanos compactor模块可以将它们优化合并，因此不会有什么问题。

当有receiver节点发生故障时，prometheus的远程写会在后端目标无响应或503时进行重试，因此，receiver一定时间的服务挂掉是可以容忍的。如果这种挂机时间是不可接受的话，可以将副本数配置为3或以上，这样即使有一个receiver节点挂掉，还有其他receiver节点来接收写请求。