Thanos架构学习
- 简介
- Thanos有两种架构模式
- sidecar部署
- receiver部署
- 组件概念及说明
简介
官网参考 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