关于云原生:thanos部署一-整体框架

这张图提纲挈领，要联合流程重复观看。

1. 组件及其作用

• sidecar

  • StoreAPI 连贯 Prometheus(grpc)，做实时查问；
  • Shipper 连贯 object storeage(http)，存储长期指标；

• querier

  • 实现了 Prometheus API;
  • StoreAPI 连贯 sidecar，通过 grpc 进行短期数据查问；
  • StoreAPI 连贯 storage-gateway，通过 grpc 进行历史数据查问；
  • 提供了一个相似 prometheus 的 WEB UI;

• store-gateway

  • 裸露 StoreAPI，查问 object storage 中的历史数据；

• compactor

  • 对 object storage 中的 block 数据做压缩 (compactor)；
  • 对 object storage 中的指标数据做降采样 (downSampling);

• ruler

  • 监控数据进行 rule evaluation 和 push alert；

2. 指标写入流程

• Prometheus 拉取指标数据，存储在本地的 TSDB 中，2hour==>1 个 block;
• sidecar 嗅探到 Prometheus 的 Pod 在 /data 生成新的 block，将 block 数据上传到 object storage；

• ruler:

  • 依据 recording rule 定期向 querier 查问指标值，生成新的指标存储在本地的 TSDB 中；
  • 当本地产生新的 block 时，将 block 上传到 object storage;

• compactor:

  • 定期对 ojbect storage 中的 block 进行 compact 和 downsampling；
  • 压缩和降采样的后果，生成新的 block，写入到 object storage;

3. 指标查问流程

• 客户端通过 QueryAPI 向 Querier 发动查问；
• Querier 将申请通过 StoreAPI 发送给 sidecar、ruler 和 store;
• sidecar 收到 StoreAPI，发送给本地的 Prometheus，返回短期的本地采集数据；
• ruler 收到 StoreAPI，返回 rule evalation 的数据；
• store 收到 StoreAPI，返回长期的历史数据；

4. 发送报警的流程

• prometheus 实例：依据配置的 alert rule 进行评估，告警条件满足时发送到 alertmanager;
• ruler 实例：依据配置的 alert rule，定期向 querier 发送查问申请，做告警判断，若触发告警，则发送至 alertmanager;
• alertmanager 实例：接管到 prometheus 和 ruler 的告警音讯后，进行分组 / 合并，发送告警告诉；