EKS环境下Prometheus特定时间段数据留存方案咨询

在EKS环境下，你可以通过以下几种方案实现「留存去年9-11月数据+最近3个月数据」的需求，兼顾成本控制和数据对比的需求：

方案1：Prometheus本地存储+自定义清理脚本（小规模场景） #

适合监控规模不大，不想引入额外组件的场景：

• 第一步：导出并备份目标历史数据
  先用promtool导出去年9-11月的TSDB数据，时间戳自行换算成对应时间段的起始/结束值（比如去年9月1日0点是1630454400，11月30日24点是1638316800）：

  promtool tsdb backup --start=1630454400 --end=1638316800 /tmp/prom-backup
  

  把备份文件上传到S3或者生成EBS快照做持久化存储。
• 第二步：配置Prometheus自动保留最近3个月数据
  修改Prometheus的配置文件，设置本地存储的 retention 为3个月：

  storage:
    tsdb:
      retention.time: 90d
  

  重启Prometheus后，会自动清理超过90天的旧数据。
• 第三步：恢复历史数据到Prometheus
  停掉Prometheus Pod，把备份的TSDB块（备份目录下的子文件夹）复制到Prometheus的PVC挂载目录（比如/prometheus/data），然后重启Pod，Prometheus会自动加载这些历史块。
• 第四步：定时清理冗余数据
  在EKS上创建一个CronJob，定期检查TSDB的块目录，删除既不在最近3个月、也不在去年9-11月的块。脚本示例逻辑：

  #!/bin/bash
  TSDB_DIR="/prometheus/data"
  CURRENT=$(date +%s)
  THREE_MONTH_AGO=$((CURRENT - 90*86400))
  # 去年9-11月的时间范围，替换成实际时间戳
  LAST_YEAR_START=1630454400
  LAST_YEAR_END=1638316800
  
  for block in "$TSDB_DIR"/*; do
    if [ -d "$block" ]; then
      BLOCK_START=$(basename "$block")
      # 判断块的起始时间是否在保留范围内
      if ! ([ $BLOCK_START -ge $THREE_MONTH_AGO ] || ([ $BLOCK_START -ge $LAST_YEAR_START ] && [ $BLOCK_START -le $LAST_YEAR_END ])); then
        rm -rf "$block"
        echo "Deleted block: $block"
      fi
    fi
  done
  

  把脚本打包成镜像，用CronJob每天执行一次，权限要配置成能访问Prometheus的PVC。

方案2：Thanos（生产级推荐） #

Thanos是EKS上常用的Prometheus联邦存储方案，结合对象存储（比如AWS S3）可以灵活管理数据生命周期：

• 部署Thanos组件
  在EKS上部署Thanos Sidecar（和Prometheus Pod做Sidecar）、Store Gateway和Querier：
  • Sidecar负责把Prometheus的TSDB块上传到S3，同时配置Prometheus本地retention为3个月（只存最近3个月，节省节点存储）。
  • Store Gateway负责从S3读取历史数据，供Querier查询。
• 配置对象存储生命周期规则
  在S3桶上设置两条生命周期规则：
  1. 规则1：保留最近90天的所有对象，不做删除。
  2. 规则2：给去年9-11月的对象打标签（比如keep-historical=true），然后设置规则：跳过带该标签的对象，其余超过90天的对象自动删除。
     你可以用AWS CLI给对应时间段的对象打标签：

  aws s3api put-object-tagging --bucket your-thanos-bucket --key "path/to/block" --tagging 'TagSet=[{Key=keep-historical,Value=true}]'
  

• 查询验证
  通过Thanos Querier可以同时查询Prometheus本地的最近3个月数据，以及S3上保留的去年9-11月数据，直接实现同比对比。

方案3：Grafana Mimir（大规模监控场景） #

如果你的监控规模较大，用Mimir（CNCF毕业项目）更适合：

• 在EKS上部署Mimir，配置后端存储为S3。
• 配置Mimir的全局retention为3个月：

  limits_config:
    retention_period: 90d
  

• 保留历史时间段数据
  结合S3的生命周期规则，给去年9-11月的Mimir存储对象打标签，设置规则跳过这些对象的删除；或者通过Mimir的retention_filter配置，自定义保留特定时间段的数据（需参考Mimir官方文档的过滤规则）。
• 所有查询通过Mimir的Query API统一访问，自动聚合最近3个月和历史留存的数据。

注意事项 #

• 操作前务必备份所有数据，避免误删关键数据。
• 用对象存储的生命周期规则时，先测试规则范围，确保不会误删需要保留的历史数据。
• CronJob或者Thanos/Mimir的配置，要匹配EKS的权限模型（比如IAM Role for Service Account），避免权限问题。

内容的提问来源于stack exchange，提问作者Siva Malla