背景:
Prometheus 本身无法做集群方案,存在单点故障;但是Prometheus 官方给出以下几种方案
1、HA：部署两套Prometheus 同时采集相同的数据,前端通过LB进行负载均衡
2、HA+远程存储,通过Prometheus 存储插件把收集的数据通过Remote write 写入到远端存储中如influxdb,解决存储持久化
3、联邦集群: Federation,按照功能进行分区，不同的shared采集不同的数据，由Global节点统一存放
Thanos 架构
Thanos 有两种工作模式分别为Sidecar 模式与 Receiver 模式,当然最常用的是 sidecar，Thanos 组件如下:
query
1、封装prometheus Query Api，支持PromQL
2、暴露query服务，实现Store Api，可查询来自四类endpoint的数据：
包括：rule节点record数据，sidecar节点prometheus原生数据，store gateway代理的object storage数据，receiver收集到的数据。
3、无状态，可水平扩展（高可用）
sidecar
1、prometheus sidecar，实现Store API，提供grpc给query组件进行指标查询；
2、使用时与prometheus放在一个pod里，共享生命周期；
3、prometheus每两个小时把数据存到硬盘一次，此时sidecar shipper同时把数据上传到对象存储；
4、此方案，如果prometheus节点down，会丢失最近两个小时的数据；
receiver
1、在prometheus remote-write基础上实现；
2、prometheus服务会把数据实时写到receiver；
3、receiver可分布式部署，实现一致性hash，（疑问：多个prometheus同时pull数据并上传到receiver，配置了external_labels，receiver是否能够实现一致性hash进行去重；）
4、此方案，一个prometheus down掉以后，仍然保证数据完整，目前thanos还没有推出比较稳定的版本。
5、receiver也会把数据写入object storage。（疑问：什么时候，什么频率）
6、远程写的同时，prometheus本地磁盘依然会写入数据。
store gateway
1、query查询object storage数据的唯一入口；
2、实现Query Api；
3、缓存对象存储索引，优化查询。
Compactor
1、单例
2、object storage数据压缩
3、object storage数据降采样，个人理解就是把数据重新整理，生成采样间隔更长的数据block，并上传至对象存储，可优化查询。
4、官方推荐100G磁盘空间用作临时数据处理空间
5、上传deletion-mark.json来标记删除对象存储里的block，三个重要参数–retention.resolution-raw，–retention.resolution-5m，–retention.resolution-1h
rule
1、类似于prometheus的rule，可根据配置文件提前生成用户配置的metric，已经对altermanagement发去告警信息；
2、rule聚合生成的数据也会上传至object storage；
3、rule的数据源是通过thanos query至prometheus查询到的，可见于thanos query互相查询。
组件与配置
Prometheus
thanos 是无侵入的，只是上层套件，因此你还是需要部署你的 Prometheus，这里不再赘述，默认你已经有一个单机的 Prometheus 在运行，可以是 pod 也可以是主机部署，取决于你的运行环境，我们是在 k8s 集群外，因此是主机部署。Prometheus 采集的是地域A的监控数据
1、启动参数:
exec ./prometheus --config.file=/apps/conf/prometheus/prometheus.yml --storage.tsdb.path=/apps/dbdat/prometheus --storage.tsdb.max-block-duration=2h --storage.tsdb.min-block-duration=2h --storage.tsdb.wal-compression --storage.tsdb.retention.time=12h --web.enable-lifecycle &
--web.enable-lifecycle一定要开，用于热加载时 reload 你的配置，retention 保留 2 小时，Prometheus 默认 2 小时会生成一个 block，Thanos 会把这个 block 上传到对象存储
2、prometheus配置文件
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
external_labels:
region: 'IDC01'
replica: 0
必须要声明external_labels，标注地域,如果你是多副本运行，需要声明你的副本标识，如 0号，1，2 三个副本采集一模一样的数据，另外2个 Prometheus 就可以同时运行，只是 replica 值不同而已
部署sidecar 组件
1、Sidecar 组件与 Prometheus server 部署于同一个 pod 中。他有两个作用：
它使用 Prometheus 的 Remote Read API，实现了 Thanos 的 Store API。这使后面要介绍的Query 组件可以将 Prometheus 服务器视为时间序列数据的另一个来源，而无需直接与 Prometheus API交互（这就是 Sidecar 的拦截作用）
可选配置：在 Prometheus 每2小时生成一次 TSDB 块时，Sidecar 将 TSDB 块上载到对象存储桶中。这使得 Prometheus 服务器可以以较低的保留时间运行，同时使历史数据持久且可通过对象存储查询。
当然，这不意味着 Prometheus 可以是完全无状态的，因为如果它崩溃并重新启动，您将丢失2个小时的指标，不过如果你的 Prometheus 也是多副本，可以减少这 2h 数据的风险
2、启动参数:
exec bin/thanos sidecar --tsdb.path "/apps/dbdat/prometheus" --prometheus.url "http://localhost:9090" --http-address 0.0.0.0:19191 --grpc-address 0.0.0.0:19091 --objstore.config-file etc/config.yaml --shipper.upload-compacted &
3、配置对象存储
cat etc/conf.yaml
type: S3
config:
bucket: thanos
endpoint: 10.65.6.1:19000
access_key: thanos
insecure: true
signature_version2: false
secret_key: thanos2021
put_user_metadata: {}
http_config:
idle_conn_timeout: 1m30s
response_header_timeout: 2m
insecure_skip_verify: false
tls_handshake_timeout: 10s
expect_continue_timeout: 1s
max_idle_conns: 100
max_idle_conns_per_host: 100
max_conns_per_host: 0
压缩：官方文档有提到，使用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会启动失败
部署store gateway 组件
在sidecar 配置中，如果你配置了对象存储 objstore.config-file，你的数据就会定时上传到 bucket 中，本地只留 2 小时，那么要想查询 2 小时前的数据怎么办呢？数据不被 Prometheus 控制了，应该如何从 bucket 中拿回来，并提供一模一样的查询呢？
1、Store gateway 组件：store gateway 主要与对象存储交互，从对象存储获取已经持久化的数据。与sidecar一样，store gateway也实现了 store api，query 组可以从 store gateway 查询历史数据
2、启动命令
exec bin/thanos store --data-dir /apps/dbdat/thanos/store --objstore.config-file etc/config.yaml --http-address 0.0.0.0:39191 --grpc-address 0.0.0.0:39090 --index-cache-size=250MB --sync-block-duration=5m --min-time=-2w --max-time=-1h &
Store gateway需要从网络上拉取大量历史数据加载到内存，因此会大量消耗 cpu 和内存
部署query组件
1、Query 组件（也称为“查询”）实现了 Prometheus 的 HTTP v1 API，可以像 Prometheus 的 graph一样，通过 PromQL 查询 Thanos 集群中的数据。
简而言之，sidecar 暴露了 StoreAPI，Query 从多个 StoreAPI 中收集数据，查询并返回结果。Query 是完全无状态的，可以水平扩展
2、启动命令
exec bin/thanos query --http-address "0.0.0.0:29090" --grpc-address "0.0.0.0:29091" --query.replica-label "IDC01" --store "10.65.4.2:19091" --store "10.65.6.9:19091" --store "10.65.6.9:39090" --store "127.0.0.1:39090" &
部署Compact
启动命令
exec bin/thanos compact --data-dir /apps/dbdat/thanos/compact --http-address 0.0.0.0:19192 --objstore.config-file etc/config.yaml &
Thanos UI
访问THanosUI 验证查询数据 http://10.65.4.2:29090
