thanos实现prometheus高可用

thanos组件：
通用api:Store Api提供服务给查询接口，通过grpc查询prometheus的remote-read接口，rule的storeapi，store gateway的storeapi。
一、thanos query：
1、封装prometheus Query Api，支持PromQL
2、暴露query服务，实现Store Api，可查询来自四类endpoint的数据：
包括：rule节点record数据，sidecar节点prometheus原生数据，store gateway代理的object storage数据，receiver收集到的数据。
3、无状态，可水平扩展（高可用）

二、thanos sidecar
1、prometheus sidecar，实现Store API，提供grpc给query组件进行指标查询；
2、使用时与prometheus放在一个pod里，共享生命周期；
3、prometheus每两个小时把数据存到硬盘一次，此时sidecar shipper同时把数据上传到对象存储；
4、此方案，如果prometheus节点down，会丢失最近两个小时的数据；

三、thanos 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本地磁盘依然会写入数据。

四、thanos 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

六、thanos rule
1、类似于prometheus的rule，可根据配置文件提前生成用户配置的metric，已经对altermanagement发去告警信息；
2、rule聚合生成的数据也会上传至object storage；
3、rule的数据源是通过thanos query至prometheus查询到的，可见于thanos query互相查询。

thanos高可用多Prometheus是如何部署的?
1、prometheus多副本。
个人理解：多副本可以达到高可用，也可以多副本采集不同分区的数据，可以减少储存。

thanos本身高可用是如何部署的?
1、thanos query水平扩展，thanos receiver分布式部署，一致性hash，thanos gateway可以水平扩展

指标是水平分片还是主备冗余还是多副本同时提供服务?
1、sidecar：指标会冗余存储，查询的时候去重
2、receiver一致性hash，去重（有疑问，由于标签不同，应该不会去重）
3、多副本同时提供服务

对象存储如何部署? minio是什么？
1、minio是对象存储，兼容aws s3模式

可以保存多久的历史数据?
1、理论上无上限

可以快速查询多久的历史数据?
1、采用降采样，可以保证查询性能。

热数据保存在哪里？保存多久？开销如何？
1、prometheus保存两个小时的数据在内存里；
2、prometheus根据配置保存数据在本地磁盘，receiver 接收数据在本地磁盘并定时上传数据到对象存储

thanos架构和原生prometheus架构共存，通过配置文件切换
1、query语法相同，可通过配置文件切换

故障/高可用测试(节点故障, 部分服务故障)
查询性能测试(响应时间，当前数据和历史数据)
写入性能测试(高并发下写延迟)
稳定性测试(连续运行一段时间)

prometheus:
1、四种数据类型，Counter、Gauge、Histogram、Summary，对于client无差别，因为prometheus server暂时未启用数据类型；
2、exporter负责收集endpoint数据，例如：node_exporter，负责收集k8s集群node数据，项目采用DaemonSet资源类型，保证每个Node只有一个exporter副本；
3、exporter收集数据，server进行retrieval，整理成metric{labelName=labelValue}形式。可以对原生metric进行封装生成自定义metric，至于metric是exporter生成还是server生成，不太清楚；
4、prometheus单节点运行，单副本，如果多副本，每个server会同时运行；
5、server具有自动的服务发现，个人理解，如果node上有两个exporter，都会被发现并收集。
6、prometheus server数据储存在pod本地存储下，不做挂载持久化处理，会导致数据丢失。

thanos:
数据源节点：Prometheus sidecar Prometheus rule node

metric data bachup:
顶级目录：ULID，可按照字典顺序检索，编码创建时间
chunk: metric name对齐
index：标签查找、所在chunk位置
meta.json: 统计范围、时间范围、压缩级别

store: 索引缓存，同步对象存储块，减少对象存储访问

query layer: store node、 sidecar、 rule查询

compactor: 仅指向对象存储，数据压缩，降采样，应用保留策略

扩展： 1、压缩器
2、Store Gateway 时间分片 --min-time --max-time

Compactor: 降采样：生成额外的block，以便于统计更广范围的历史数据

thanos query: PromQL发起，通过StoreAPI支撑，所以配置文件需要制定store api的地址（grpc）
查询目标可包括： prometheus sidecar，object storage（store gateway），rule里面的数据，receiver里面的数据
不同租户可以使用不同prometheus实例
dedup：不是group by，类似于删除label，应replica=a和replica=b被认为是一类数据
Partial Response: 某个store api错误不影响整体查询，增加warnings字段

sidecar: prometheus每两小时存储数据到TSDB时，sidecar shipper把数据写入对象存储

高可用： 1、业务拆分，多个sidecar对应多个bucket，多个store gateway代理查询
2、时间分片：多个store gateway分别查询不同时间段的数据。

sidecar与receiver对比：sidecar利用remote read api，依赖于底层prometheus，如果prometheus挂了，丢失两小时的数据，receiver利用remote write api，数据实时同步