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

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的告警音讯后，进行分组/合并，发送告警告诉；