随着云计算集群规模的增长，对资源的监控数据也呈现指数级增长，给后期计算、存储资源扩容带来了极大的考验。如何稳定、永久存储监控数据、快速查询热数据与历史数据一直是大规模云计算集群存在的问题，本文将介绍Thanos 作为Prometheus的监控配套组件， 构造Thanos + Prometheus 的TP组合来完成大规模数据的监控，尤其对查看时间久远的监控数据（冷数据），Thanos帮我们简化分布式 Prometheus 的部署与管理，Thanos 方案本身对于Prometheus 没有任何强势侵入，它提供了一些的高级特性：全局视图、长期存储、高可用。其全局视图可管理多地域、300+ 集群的监控数据。Thanos是一个“开源的，高可用的Prometheus系统，具有长期存储能力”。甚至可以认为 Thanos 只是一个监控套件，只是可以通过跨集群联合、跨集群无限存储和全局查询为Prometheus增加高可用性，可与原生 Prometheus 结合，满足了长期存储 + 无限拓展 + 全局视图 + 无侵入性的需求。而默认的Prometheus设置在查询历史数据、通过单个API调用进行跨分布式Prometheus服务器查询以及合并多个Prometheus数据方面存在困难。
Prometheus 官方的高可用有常用方案回顾：
HA：即两套 Prometheus 采集完全一样的数据，在其前面再挂负载均衡
HA + 远程存储：除了基础的多副本 Prometheus，还通过 Remote Write 写入到远程存储，解决存储持久化问题；默认情况下，Prometheus存储15天的时间序列数据。为了无限期存储数据，Prometheus提供了一个远程端点，用于将数据写入另一个数据存储区。这种方法，数据去重是个问题。
联邦集群：即 Federation，按照功能进行分区，不同的 Shard 采集不同的数据，由 Global 节点来统一存放，解决监控数据规模的问题。
上图Prometheus架构中：
Server: 主要负责数据采集和存储，提供PromQL查询语言的支持
Push Gateway: 支持临时性Job主动推送指标的中间网关
DashBoard: 使用rails开发的dashboard，用于可视化指标数据
alertManager: 实验性组件、用来进行报警；
Exporter:支持其他数据源的指标导入到Prometheus，支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等；
Thanos 是英国游戏技术公司 Improbable 开源的Prometheus 高可用解决方案。主页上简单易懂一段英文介绍如下：Open source, highly available Prometheus setup with long term storage capabilities。开源，高可用性的Prometheus 设置，并提供长期存储能力。
Thanos 特点：
● 跨Prometheus 服务并提供le 统一的查询接口。
● 无限期的存储监控指标，它的一个主要特点就是允许“无限”存储空间。目前支持S3、微软Azure、腾讯COS、Google GCP、Openstack Swift 等对象存储系统。
● 兼容现有的Prometheus API 接口 ，例如 Grafana 或者支持 Pormetheus Query API 等工具。
● 提供数据压缩功能和降准采样，提升查询速度。
● 重复数据删除和合并，并从Pormetheus HA 集群中收集指标。
Thanos官网：单击查看；
官方文档；
二、架构● 官方架构如下：
上图中，列出了Thanos 的几个核心组件，组件之间通过gRPC进行通信。但并不包括所有组件，概要如下：
● Thanos Query：它是一个无状态的服务，实现了 Prometheus API，将来自下游组件提供的数据进行聚合最终返回给查询数据的 client （如 grafana），类似数据库中间件。Querier与所有Sidecar直连，同时Querier实现了一套Prometheus官方的HTTP API，从而保证对外提供与Prometheus一致的数据源接口，Grafana可以通过同一个查询接口请求不同集群的数据，Querier负责找到对应的集群并通过Sidecar获取数据，接收到HTTP的PromSQL 查询请求后负责将数据查询和汇集。Querier本身也是水平可扩展的，因而可以实现高可部署，而且Querier可以实现对高可部署的Prometheus的数据进行合并从而保证多次查询结果的一致性，从而解决全局视图和高可用的问题。Query 组件启动时，默认会根据 query.replica-label 字段做重复数据的去重，你也可以在页面上勾选 deduplication 来决定。
● Thanos Sidecar：连接 Prometheus，将其数据提供给 Thanos Query 查询，并且/或者将其上传到对象存储，以供长期存储。Thanos通过使用后端的对象存储来解决数据保留问题。Prometheus在将数据写入磁盘时，Sidecar的StoreAPI组件会检测到，并将数据上传到对象存储器中。Store组件还可以作为一个基于gossip协议的检索代理，让Querier组件与它进行通信以获取数据。他可以作为一个单独的进程和已有的Prometheus实例运行在一个server上，互不影响。Sidecar可视为一个Proxy，所有对Prometheus的访问都通过Sidecar来代理进行。通过Sidecar还可以将采集到的数据直接备份到云端对象存储服务器。此组件需要和Pormetheus 实例一起部署，主要两个作用，第一代理Querier 组件对本地Prometheus数据读取；第二是将Prometheus 本地监控数据通过对象存储接口上传到对象存储中。最后sidecar 会监视Prometheus的本地存储，若发现有新的监控数据保存到磁盘，会将这些监控数据上传至对象存储。
● Thanos Store Gateway：将对象存储的数据暴露给 Thanos Query 去查询。Store实现了一套和Sidecar完全一致的API提供给Querier用于查询Sidecar备份到云端对象存储的数据。因为Sidecar在完成数据备份后，Prometheus会清理掉本地数据保证本地空间可用。所以当监控人员需要调取历史数据时就只能去对象存储空间获取，而Store就提供了这样一个接口。Store Gateway只会缓存对象存储的基本信息，例如存储块的索引，从而保证实现快速查询的同时占用较少本地空间。Bucket用于检查对象存储中的数据命令，通常作为独立命令运行并帮助我们进行故障排查，支持通过Web UI 查看目前Buket的数量；由于Thanos Store 启动时会加载可以访问的数据，他会在本地磁盘或者内存中加载少量的对象存储的块信息，随着时间的推移会造成本地磁盘和内存的爆满，导致集群异常，并可能会因大量查询缓慢导致内存暴增并出现Store OOM；store组件是非常占用内存的，资源分配时需注意；
● Thanos Ruler：对监控数据进行评估和告警，还可以计算出新的监控数据，将这些新数据提供给 Thanos Query 查询并且/或者上传到对象存储，以供长期存储。通过Thanos check 可以检查和验证Pormetheus Rules 是否正确；
● Thanos Compact：将对象存储中的数据进行压缩和降低采样率，加速大时间区间监控数据查询的速度。Thanos提供了时间序列数据的压缩和降采样（downsample）存储。类似Prometheus提供的一个内置的压缩模型，现有较小的数据块会被重写为较大的数据块，并进行结构重组以提高查询性能。Thanos在Compactor组件（作为批次作业运行）中也使用了相同的机制，并压缩对象存储数据。官方曾说Compactor也对数据进行降采样，目前降采样时间间隔不可配置，不过他们选择了一些合理的时间间隔——5分钟和1小时。压缩也是其他时间序列数据库（如InfluxDB和OpenTSDB）的常见功能。需要注意的是 Compactor 并不会减少磁盘占用，反而会增加磁盘占用（做了更高维度的聚合）。
● 简化后(流程):
● Thanos Sidecar+Prometheus：Thanos 的默认模式就是sidecar 方式，另外还有一种不太常用的 receive 模式。
● Receive 模式
使用场景：
1、Sidecar 模式有一个缺点：就是 2 小时内的数据仍然需要通过 Sidecar->Prometheus 来获取，也就是仍然依赖 Prometheus，并不是完全的数据在外部存储。如果你的网络只允许你查询特定的存储数据，无法访问到集群内的 Prometheus，那这 2 小时的数据就丢失了，而 Receive 模式采用了remote write 就没有所谓的 2 小时 block 的问题了。
2、Sidecar 模式对网络连通性是有要求的，如果你是多租户环境或者是云厂商，对象存储（历史数据）Query 组件一般在控制面，方便做权限校验和接口服务封装，而 Sidecar 和 Prometheus 却在集群内，也就是用户侧。控制面和用户侧的网络有时候会有限制，是不通的，这个时候会有一些限制导致你无法使用 Sidecar。
3、租户和控制面隔离，虽然希望数据完全存在控制面，Receive 更适合匹配云厂商服务使用。
● 其他解决方案参考：
1、前期准备
案例参考：线上约40+套 Openstack，70+ 套的Ceph集群，约10000 +的OSD 节点数量，每天约产生约50G 监控数据。
不同的业务存储在不同 bucket 里（需要改造或者多部署几个 Sidecar）。例如有 5 个 bucket ，再准备 5 个 store gateway 进行代理查询。减少单个 store 数据过大的问题。
关于数据切片/时间切片，也就是 store gateway 可以选择查询多长时间的数据。支持两种表达，一种是基于相对时间的，例如 --max-time 3d 前到 5d 前的。一种是基于绝对时间的，19 年 3 月 1 号到 19 年 5 月 1 号。例如想查询 3 个月的数据，一个 store 代理一个月的数据，那么就需要 3 个 store 来合作。
2、部署
软件下载：https://github.com/thanos-io/thanos/releases wget -C https://github.com/thanos-io/thanos/releases/download/v0.23.1/thanos-0.23.1.linux-amd64.tar.gz
3、一键部署脚本
#!/bin/bash
# 拷贝systemd服务
cp -rf prometheus.service /etc/systemd/system/
cp -rf thanos-sidecar.service /etc/systemd/system/
# 拷贝脚本
mkdir -p /usr/local/{prometheus/data,thanos} || true
chmod 755 {prometheus,thanos,*.sh}
cp -rf {thanos,start-sidecar.sh,minio-storage.yml} /usr/local/thanos/
cp -rf {prometheus,start-prometheus.sh,prometheus.yml} /usr/local/prometheus/
# 启动服务
systemctl daemon-reload
systemctl enable prometheus && systemctl start prometheus
systemctl enable thanos-sidecar && systemctl start thanos-sidecar
4、验证
5、问题：
1）Prometheus 压缩
压缩：官方文档有提到，使用 Sidecar 时，需要将 Prometheus 的 –storage.tsdb.min-block-duration 和 –storage.tsdb.max-block-duration 这两个值设置为 2h，两个参数相等才能保证 Prometheus 关闭了本地压缩，其实这两个参数在 Prometheus -help 中并没有体现，Prometheus 作者也说明这只是为了开发测试才用的参数，不建议用户修改。而 Thanos 要求关闭压缩是因为 Prometheus 默认会以 2，25，25*5 的周期进行压缩，如果不关闭，可能会导致 Thanos 刚要上传一个 block，这个 block 却被压缩中，导致上传失败。
另外，在 Sidecar 启动时，也会检查这两个参数，如果不合适，Sidecar 会启动失败。
2）store-gateway：store 组件资源消耗是最大的，毕竟他要拉取远程数据，并加载到本地供查询，如果你想控制历史数据和缓存周期，可以修改相应的配置，如：
--index-cache-size=250MB --sync-block-duration=5m --min-time=-2w 最大查询 1 周 --max-time=-1h
store-gateway 默认支持索引缓存，来加快 TSDB 块的查找速度，但有时候启动会占用了大量的内存，在 0.11.0 之后的版本做了修复，可以查看这个issue。Prometheus 2.0 已经对存储层进行了优化。例如按照时间和指标名字，连续的尽量放在一起。而 store gateway 可以获取存储文件的结构，因此可以很好的将指标存储的请求翻译为最少的 object storage 请求。对于那种大查询，一次可以拿成百上千个 Chunks 数据。而在 store 的本地，只有 Index 数据是放入 cache 的，Chunk 数据虽然也可以，但是就要大几个数量级了。目前，从对象存储获取 Chunk 数据只有很小的延时，因此也没什么动力去将 Chunk 数据给 cache 起来，毕竟这个对资源的需求很大。
附录：文献及相关资料1、Thanos 架构详解；
2、Thanos 组件介绍；
3、thanos的简介和几个月使用心得；
4、thanos云原生部署；
5、prometheus thanos搭建
6、Prometheus高可用Thanos；
7、Thanos的部署；
