基于Prometheus的动态降采样实现方案咨询

方案1（客户端侧滑动窗口计算）实操建议 #

• 窗口维护简化：直接利用collections.deque的maxlen参数实现固定长度FIFO，比如5秒窗口设maxlen=5、1分钟窗口设maxlen=60，无需手动清理旧数据，自动保证窗口内仅保留最近N个1秒指标值。
• 指标暴露规范：使用prometheus_client的Gauge类型分别暴露原始1秒指标、5秒平均、1分钟平均指标。注意窗口未满时（如服务启动前5秒），需判断队列非空再计算平均值，避免除以零错误。
• 代码示例：

  from prometheus_client import Gauge, start_http_server
  from collections import deque
  import time
  
  # 定义指标
  raw_metric = Gauge('server_cpu_usage_raw', 'Raw 1-second CPU usage')
  cpu_5s_avg = Gauge('server_cpu_usage_5s_avg', '5-second average CPU usage')
  cpu_1min_avg = Gauge('server_cpu_usage_1min_avg', '60-second average CPU usage')
  
  # 初始化滑动窗口
  window_5s = deque(maxlen=5)
  window_60s = deque(maxlen=60)
  
  def collect_and_export():
      start_http_server(8000)
      while True:
          # 替换为实际指标采集逻辑（比如读取/proc/stat）
          current_value = get_cpu_usage()
          raw_metric.set(current_value)
          
          # 更新窗口
          window_5s.append(current_value)
          window_60s.append(current_value)
          
          # 计算并设置平均值
          if window_5s:
              cpu_5s_avg.set(sum(window_5s) / len(window_5s))
          if window_60s:
              cpu_1min_avg.set(sum(window_60s) / len(window_60s))
          
          time.sleep(1)
  
  if __name__ == '__main__':
      collect_and_export()
  

• 优化点：若采集指标数量较多，可封装滑动窗口类复用逻辑；针对计数器类型指标（如QPS），需存储每秒增量值到窗口，再计算平均速率，而非直接对原始值取平均。

方案2（服务端查询计算）实操建议 #

• 端点实现简化：无需手动拉取所有1秒数据计算，直接调用Prometheus的/api/v1/query_range接口，用avg_over_time函数让Prometheus原生计算平均值，减少本地计算压力。
• 定时抓取配置：通过Prometheus的scrape_configs配置不同抓取间隔，对应不同降采样窗口：

  scrape_configs:
    # 每5秒抓取5秒平均指标
    - job_name: 'downsample_5s'
      scrape_interval: 5s
      static_configs:
        - targets: ['downsample-api:8000']
      params:
        window: ['5s']
    # 每1分钟抓取1分钟平均指标
    - job_name: 'downsample_1min'
      scrape_interval: 1m
      static_configs:
        - targets: ['downsample-api:8000']
      params:
        window: ['60s']
  

• 注意事项：给Prometheus API配置访问控制，避免未授权调用；查询时需通过标签过滤指定实例，避免跨服务器指标被错误聚合；开启Prometheus查询缓存，降低重复查询的性能损耗。

推荐替代方案：Prometheus原生记录规则（Recording Rules） #

这是最省心的降采样方案，无需额外开发，完全依赖Prometheus原生能力：

• 规则配置：创建降采样规则文件，定义不同窗口的平均值计算：

  groups:
  - name: downsample_5s_rules
    interval: 5s
    rules:
    - record: server_cpu_usage:avg_5s
      expr: avg_over_time(server_cpu_usage_raw[5s])
  - name: downsample_1min_rules
    interval: 1m
    rules:
    - record: server_cpu_usage:avg_1min
      expr: avg_over_time(server_cpu_usage_raw[1m])
  

  在Prometheus主配置文件中引入该规则文件：

  rule_files:
    - "downsample_rules.yml"
  

• 长期存储配置：通过remote_write将降采样后的指标发送到长期存储系统（如Thanos、Mimir或独立Prometheus实例），原始指标保留24小时即可。
• 优势：自动处理窗口对齐，避免手动计算的时间偏差；支持多种聚合函数（sum、percentile等）；无需维护额外服务，可靠性高。

内容的提问来源于stack exchange，提问作者Andrew Holway