prometheus远程写之thanos receive模块

背景

起初（大概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节点来接收写请求。