Thanos架构学习

最新推荐文章于 2023-06-01 10:15:29 发布

qq_道可道

最新推荐文章于 2023-06-01 10:15:29 发布

阅读量550

点赞数 1

分类专栏：监控 K8S与容器文章标签：架构

本文链接：https://blog.csdn.net/qq_16240085/article/details/125504283

版权

K8S与容器同时被 2 个专栏收录

28 篇文章 1 订阅

订阅专栏

监控

4 篇文章 2 订阅

订阅专栏

Thanos架构学习

简介
Thanos有两种架构模式

简介

官网参考
Thanos基于prometheus，在此基础上提供了全局指标查询，可将多个云/region的prometheus数据集中管理，并且将数据直接存储到廉价的对象存储，可以存放更久的数据（并对历史数据进行压缩与降采样），降低本地prometheus存储费用，同时可与现有的prometheus无缝集成。支持prometheus数据的HA，Querier组件并对其HA数据进行动态合并。

Thanos有两种架构模式

sidecar与receiver两种模式对比

sidecar部署

间隔2小时将prometheus数据存储到云存储桶，提供StoreAPI，用于Querier直接查询，官方建议保留6小时数据。

优点：较少使用本地存储；配置简单，只需要增加sidecar和相关参数；
缺点：query查询由于跨vpc等速度相对慢；当多个副本时，为了去重数据，查询需要等待多个副本都返回数据才向客户端响应，可能出现超时情况）

receiver部署

将数据推送到receiver，由receiver每两小时统一上传到云存储桶（

优点：对于只能访问外网的情况很适合，prometheus很轻量，query查询速度快；配置简单，增加一行prometheus配置remote_write（Prometheus v2.13+对remote_write进行了优化与改进，必须高于此版本），将生成的数据直接写入Receiver。
缺点：需要部署Receiver集群并维护高可用性）。

组件概念及说明

Store Gateway：在云存储桶内提供指标，几乎无状态，客户端通过负载均衡/K8S service请求store集群3节点，只需要1个节点成功即可返回给客户端（历史数据通过StoreAPI获取，为了提高性能，增加文件存储保存对象存储中的元数据信息，加快查询速度，通常几个G即可）。
Compactor：对存储在云存储桶中的数据进行压缩、降低采样和保留规定时长的数据（定期将云存储中的小块数据进行合并压缩，减少云存储的容量；降采样（超过40 小时的原始指标都以 5m 分辨率进行下采样，超过10 天的 5m 跨度指标都以 1h 分辨率进行下采样，降低采样并不会减少存储、反而会增加2个类似大小的数据块，提高了大范围查询效率；保留规定时长的数据），只能部署一个，为了提高压缩效率，最好挂一块100g磁盘处理中间数据和存储桶状态缓存（非必需），当存储桶中数据量持续增加，根据情况适当增加cpu、men等配置，另外它也是网络大户，与云存储桶打交道最多；只有它需要删除对象存储的权限，其他组件只需要读写。–deduplication.replica-label=“replica” 指定删除标签为replica的重复数据
Receiver：从 Prometheus 的远程写入 WAL 接收数据，将其公开和上传到云存储。支持多租户3节点（接收prometheus传来的数据并上传到云存储，使用stateful存储，prom若不挂数本地存储、会丢失几秒数据）。
Sidecar：连接到 Prometheus，读取其数据进行查询和/或将其上传到云存储。（2小时上传一次，因此prom必须挂载本地存储，否则最大丢失2h数据）
prom启动参数：–storage.tsdb.max-block-duration=2h --storage.tsdb.min-block-duration=2h --web.enable-admin-api支持 sidecar 从 Prometheus 获取元数据，如外部标签。–web.enable-lifecycle支持sidecar重新加载功能（–reload）。
- sidecar启动参数：–tsdb.path “/path/to/prometheus/data/dir” --prometheus.url “http://localhost:9090” --objstore.config-file “bucket.yml”
- Ruler/Rule：根据 Thanos 中的数据评估记录和警报规则，以进行展示和/或上传（多集群告警规则设置复杂，不同环境单独配置）。
Querier/Query：实现 Prometheus 的 v1 API 来聚合来自底层组件的数据（完全适配prometheus语法查询，无状态应用2节点，通过–query.replica-label “replica” 参数删除重复数据副本标签，–store.sd-files支持文件sd）。
Query Frontend:：实现 Prometheus 的 v1 API 代理它到查询，同时缓存和可选的查询按天分割，2节点（可将长查询分割为短查询，默认24h分割、主要可以减少大查询导致的oom、提高并发和负载均衡）目前只有范围查询（/api/v1/query_rangeAPI 调用）实际上是通过查询前端处理的，其他请求都是直接交给下游处理。

Sidecar配置及注意事项
 Receive配置及注意事项r