Thanos

官方架构图
Thanos - 图1

sidecar模式
Thanos - 图2
Thanos - 图3
增加query-frontend组件
Thanos - 图4
receiver模式
Thanos - 图5


https://github.com/thanos-io/kube-thanos/tree/master/examples/all/manifests

Thanos Query: 实现了Prometheus API，将来自下游组件提供的数据进行聚合最终返回给查询数据的 client (如 grafana)
Thanos Sidecar: 连接 Prometheus，将其数据提供给 Thanos Query 查询，或者将其上传到对象存储，以供长期存储Thanos Store Gateway: 将对象存储的数据暴露给 Thanos Query 去查询Thanos Ruler: 对监控数据进行评估和告警，还可以计算出新的监控数据，将这些新数据提供给 Thanos Query 查询并且/或者上传到对象存储，以供长期存储Thanos Compact: 将对象存储中的数据进行压缩和降低采样率，加速大时间区间监控数据查询的速度Thanos Bucket:检查对象存储中数据的命令，通常作为独立命令运行并帮助我们进行故障排查，支持通过Web UI 查看目前Buket的数量Thanos Check:通过Thanos check 可以检查和验证Pormetheus Rules 是否正确

  • Sidecar: 每个 Prometheus 实例都包含一个 Sidecar，它与 Prometheus 实例运行在同一个 Pod 中。它有两个作用：1) 将本地超过 2 小时的监控数据上传到对象存储，如 Amazon S3 或 Google 云存储。2) 将本地监控数据（小于 2 小时）提供给 Thanos Query 查询。
  • Store Gateway : 将对象存储的数据提供给 Thanos Query 查询。
  • Query : 实现了 Prometheus 的查询 API[8]，将 Sidecar 和对象存储提供的数据进行聚合最终返回给查询数据的客户端（如 Grafana）。
  • Compact : 默认情况下，Sidecar 以 2 小时为单位将监控数据上传到对象存储中。Compactor 会逐渐将这些数据块合并成更大的数据块，以提高查询效率，减少所需的存储大小。
  • Ruler : 通过查询 Query 获取全局数据，然后对监控数据评估记录规则[11]和告警规则，决定是否发起告警。还可以根据规则配置计算新指标并存储，同时也通过 Store API 将数据暴露给 Query，同样还可以将数据上传到对象存储以供长期保存。由于 Query 和底层组件的可靠性较低，Ruler 组件通常故障率较高[12]： Ruler 组件在架构上做了一些权衡取舍，强依赖查询的可靠性，这可能对大多数场景都不利。对于 Prometheus 来说，都是直接从本地读取告警规则和记录规则，所以不太可能出现失败的情况。而对于 Ruler 来说，规则的读取来源是分布式的，最有可能直接查询 Thanos Query，而 Thanos Query 是从远程 Store APIs 获取数据的，所以就有可能遇到查询失败的情况。

  • Receiver : 这是一个实验性组件，适配了 Prometheus 的 remote write API，也就是所有 Prometheus 实例可以实时将数据 push 到 Receiver



    metrics
    thanos sidecar
    http://0.0.0.0:10902/metrics
    prometheus
    http://0.0.0.0:9090/metrics

    thanos compact
    http://0.0.0.0:10902/metrics

    thanos query
    http://0.0.0.0:9090/metrics

    thanos rule
    http://0.0.0.0:10902/metrics

    thano store
    http://0.0.0.0:10902/metrics

    S3
    thanos sidecar
    thanos compact
    thanos rule
    thanos store

    Thanos multi cluster
    Thanos - 图6

    Thanos - 图7