Thanos Receive 模块介绍

k8s技术圈

共 20945字,需浏览 42分钟

 ·

2021-03-21 15:37

起初(大概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      +----------------------------------------------------------------+
|              | |
+--------------+ |
                 +

功能说明

负载分发

为了支持多台机器的扩展,时间序列将被分发到不同的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 +<----------+
                                 |  |                 |  |
                                 |  +-----------------+  |
                                 |                       |
                                 +-----------------------+

多副本

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节点来接收写请求。

原文链接:https://blog.csdn.net/felix_yujing/article/details/108302167


K8S 进阶训练营


 点击屏末  | 即刻学习
浏览 127
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报