2022-07-05 23:05:46

thanos问题列表

给prometheus做HA、数据持久化、做分片扩展查询的分布式软件

组件

  • thanos-sidecar *
  • thanos-rule *
  • thanos-query *
  • thanos-query-frontend *
  • thanos-store *
  • thanos-tools
  • thanos-receiver
  • thanos-compactor *

关于thanos架构

  • ruler会轮询多个query,能够实现压力分担;但是query不会。
  • 假如你现在自作聪明,query1 --> query2 --> stores;对于query1来说,他的store就是query2,所以所有的查询都会fanout到所有的query2中进行查询,等待所有结果返回后再合并返回。假如你现在有10个query2,那么一个查询就是10次重复查询,多么恐怖的放大;要是在query前面再加一个frontend,进行查询拆分,比如12h拆分,那么一个3天的查询,最终到后面store的查询就有 6 * 10 = 60个查询,原本应该是6个查询,现在被放大的60个查询!!!并发越高,后面的压力越大。
  • compact组件看似不起眼,确在提升历史数据查询上提供不可或缺的作用;默认sidecar上传的chunk是2h的,compact会进行合并,合并分多个等级,此时还不存在降采样,只有等合并任务完成后,才会进行降采样的操作。降采样分两个粒度,2d前的300s和2d前的1h粒度。compact依赖于磁盘IO、CPU,提升磁盘IO和CPU能显著提升compact速度;在v0.24.0之后的版本,支持min-time来选择compact作用时间!!!
  • compact组件,如果时间范围过大,做compact/downsampling的时候,磁盘不好预估,当规模太大,会导致:
    1. 磁盘空间占用太大,根本不知道要多少空间
    2. 并发不好调整
    3. 合并后,index文件过大,而cos的普通上传文件接口有单文件大小限制,最大5G,所以如果index对应的chunk时间一长,就直接GG
    4. 目前只能将compact的时间参数调整为--min-time=-8d来完成有限时间的compact和降采样

本文链接:https://troy.wang/post/thanos-issues.html

-- EOF --