Prometheus --storage.tsdb.retention.time作用范围及远程存储保留配置

直接给明确结论：该启动参数仅对Prometheus本地内置TSDB存储生效，对所有配置的远程存储完全不产生作用。

Prometheus的本地存储和远程存储逻辑是完全解耦的：采集到的时序样本写入本地TSDB的同时，会按照remote_write配置将样本转发到指定远端存储，Prometheus本身不具备远程存储的数据生命周期管理权限，也不会主动向远程存储下发任何删除过期数据的指令。--storage.tsdb.retention.time 控制的仅仅是本地磁盘上存储的TSDB数据块的自动清理阈值，和远程存储的数据保留逻辑没有任何关联。
额外提醒：Prometheus处理远程读请求时，也不会拿本地配置的保留时间去过滤远端返回的查询结果，不要尝试通过调整本地保留参数间接限制远程存储的数据留存。

远程存储的数据生命周期完全由存储服务自身管控，Prometheus侧没有全局统一参数可以跨存储类型限制数据保留时长，必须在对应远程存储的服务端配置清理规则。

针对你当前使用InfluxDB作为远程存储的场景：

• 你已经在InfluxDB对应数据库上创建retention policy的做法就是标准可行方案，不需要在Prometheus侧做任何额外配置。
• 配置完成后可做简单校验：写入一条时间戳远超你设置的保留时长的测试数据，等待InfluxDB的默认清理周期（每30分钟扫描一次过期数据）触发后，查询该时间点的数据，确认过期数据被自动删除即可。
• 注意避坑：如果对应InfluxDB数据库配置了多个retention policy，需要确认Prometheus的remote_write配置写入时绑定的是你设置了目标保留时长的RP，避免数据写入默认RP导致保留规则不符合预期。

内容的提问来源于stack exchange，提问作者Bryan Chen