Thanos Receive 模块介绍
共 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 进阶训练营