Thanos 是什么，是打了响指灭了一半人类的灭霸吗？不是，在监控领域，Thanos 是 Prometheus 的高可用解决方案，由英国游戏技术公司 Improbable 开源，在 2018 年的 9 月 14 日发布了第一个版本，v0.1.0，到现在已经发布了 v0.23.1。
Thanos 官网主页上简单易懂一段英文介绍如下：Open source, highly available Prometheus setup with long term storage capabilities。开源，高可用性的 Prometheus 设置，并提供长期存储能力。这是对 Thanos 最准确的描述。
Thanos 以简单且高成本效益的方式，为 Prometheus 提供一个集群，目的是要实现大规模的监控。Thanos目前的核心维护者来自 Polar Signals、红帽和 字节跳动，已经被字节跳动、腾讯、华为、VIVO、eBay 等公司用于生产环境。
Thanos 很早就进入了 CNCF 的沙盒阶段，在 2020.08.19 通过 TOC 的审核进入 CNCF 的孵化阶段，目前已经稳定发布一年多了，在不久的将来也许就毕业了。
Thanos 维护者 Frederic Branczyk 提到，Thanos 是一种易于安装的解决方案，可以将用户的 Prometheus 执行个体过渡到具有长期储存功能的监控系统。大多数的 Thanos 都部署在 Kubernetes 上，可用来监控跨多集群与多云的微服务或是基础设施。
Thanos 的特点
Thanos 在首页就大方的放出了自己的 4 个优点，分别是：
- 全局查询
- 无限制的存储
- 兼容 Prometheus
- 数据降准和压缩 其实 Thanos 还有第 5 个优点，那就是高可用集群。
全局查询
Thanos 可以跨多个 Prometheus 实例来查询存储的监控指标，这样就实现了 Prometheus 的水平扩展，当单机 Prometheus 性能不足时，通过水平拆分就可以完成扩展 Prometheus 的承载能力。
无限制存储
Thanos 本身不提供存储，但是它支持多种对象存储系统，使用对象存储来扩容数据存储，以此来无限的存储监控数据，它支持 Google 的 GCP、AWS 的 S3、Azure、Swift、Tencent 的 COS、AliYun 的 OSS。
兼容 Prometheus
Thanos 完全兼容 Prometheus 的 API 接口，无论你使用 Grafana 或者其他支持 Prometheus API 的工具，使用过程非常丝滑，一点都感觉不到在使用 Thanos ，就像在直接操作 Prometheus 一样。
数据降准和压缩
Thanos 会对 Prometheus 的数据进行降准，当查询大时间范围的监控数据或者配置复杂的保留策略时可以加快查询速度，另外也会对实时数据进行压缩，这样可以节省一定的存储空间。
高可用集群
Thanos 可以针对 Prometheus 提供高可用集群，并且对重复数据进行删除和合并。
Thanos 架构
Thanos 的架构看起来非常复杂，但是分析以后非常简单。
Thanos 提供了 Sidecar、Query、Store、Receive、Rule、Compact、Query Frontend、tools 8 个组件，但是构建一个 Thanos 集群最少使用 4 个就可以完成一个简单的集群，最多也只要 6 个组件就可以构建非常复杂的集群。
这些组件的功能分别是：
- Sidecar： Thanos 的数据上传组件，用来和 Prometheus 通信，并且将 Prometheus 的监控数据上传到对象存储
- Query：Thanos 的查询组件，用来查询监控数据
- Store：Thanos 的数据存储组件，用来和对象存储通信，为对象存储提供数据代理服务。
- Receive：Thanos 的数据收取组件，支持 Prometheus 的远程写功能，对于同一个 Prometheus 实例，只能在 Sidecar 和 Receiver 中间二选一。
- Rule：Thanos 的集中的告警管理组件
- Compactor：Thanos 的数据处理组件，用来将监控数据降准和压缩
- Query Frontend：Thanos 的查询前端
- tools：Thanos 的运维工具，用途很多。
Thanos 看上去有这么多组件，其实部署的时候只有一个二进制包，搭配不同的参数实现不同的功能，非常方便，比如 Query 组件就是 ./thanos query ，Sidecar 组件就是 ./thanos sidecar ，所有组件在同一个包里，而且包的体积很小。
Thanos 集群有两种模式，分别是使用 Sidecar 来进行监控数据上传的边车模式和使用 Receive 来接受数据的收取模式，两种模式只有数据从 Prometheus 到对象存储的方式有区别，其他结构是一样的。
我们首先来看边车模式： 从数据发生的 Prometheus 看起，Prometheus 在获取数据以后，通过 Sidecar 将数据上传到 对象存储，Store 从对象存储读取数据供其他组件查询，Query 从 Sidecar 获取实时数据、从 Store 获取历史数据对外提供查询功能，Rule 从 Sidecar 和 Store 获取数据进行规则计算，如果触发告警就推送给 AlertManager ，Compactor 对对象存储进行读写，下载数据进行数据降准和压缩，将处理好的数据上传到对象存储，并且删除已经降准过和压缩过的数据。Query Frontend 在 Query 前边提供查询缓存和查询分解的功能。
接着我们来看收取模式： 对于收取模式，大致的结构和边车模式是一样的，只是没有了 Sidecar 组件，Prometheus 通过远程写功能将数据直接写给 Receive ，Receiver 将数据写给对象存储，Query 查询数据从 Receive 和 Store 获取，Rule 从 Receive 和 Store 获取数据进行规则计算，Store 和 Compacter 的功能不变。
如果要在一台机器上部署 Thanos 的所有组件，那么可以按照下边的表格来规划端口。
| 组件 | 接口协议 | 端口 |
|---|---|---|
| Sidecar | gRPC | 10901 |
| Sidecar | HTTP | 10902 |
| Query | gRPC | 10903 |
| Query | HTTP | 10904 |
| Store | gRPC | 10905 |
| Store | HTTP | 10906 |
| Receive | gRPC (store API) | 10907 |
| Receive | HTTP (remote write API) | 10908 |
| Receive | HTTP | 10909 |
| Rule | gRPC | 10910 |
| Rule | HTTP | 10911 |
| Compact | HTTP | 10912 |
| Query Frontend | HTTP | 10913 |
Component Interface Port Sidecar gRPC 10901 Sidecar HTTP 10902 Query gRPC 10903 Query HTTP 10904 Store gRPC 10905 Store HTTP 10906 Receive gRPC (store API) 10907 Receive HTTP (remote write API) 10908 Receive HTTP 10909 Rule gRPC 10910 Rule HTTP 10911 Compact HTTP 10912 Query Frontend HTTP 10913
发布周期
Thanos 的目标是每 6 周发布一个版本，这个是要严格执行的，如果没有紧急的 BUG 修复，那么等待一个多月就会有新的版本发布。不过最近好像有点延期。
在 2021.09.02 发布了 v0.23.0 ，按照计划，应该在 2021.10.28 发布 v0.24.0 ，在 2021.12.09 发布 v0.25.0 ，不过显然他们迟到了，现在只发布到了 v0.24.0-rc.1 ，距离 v0.24.0 快了，不过 v0.25.0 要再等一个多月了。
对于版本发布，Thanos 会在主分支上进行发布，每次都会有一个成员来负责这个版本的发布，包括从第一个 RC 版本到最终的正式版本，以及在所有的渠道上进行发布。
这次我们先有一个大概的了解，接下来，我们继续深入 Thanos 集群。
标签：HTTP,架构,Prometheus,Query,组件,Thanos,总览,Sidecar From： https://blog.51cto.com/erdong/5786207