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 +----------------------------------------------------------------+
| | |
+--------------+ |
+
功能说明
负载分发
为了支持多台机器的扩展，时间序列将被分发到不同的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 进阶训练营
点击屏末 | 阅读原文 | 即刻学习