Prometheus 2.13.1重启后出现2-3小时数据丢失问题求助

• 先做时间窗口对齐：拉取Prometheus重启全量日志，定位两个关键日志行的时间戳：
  • 最后一条WAL segment loaded打印时间、后续WAL replay completed打印时间
  • Server is ready to receive web requests打印时间
    两个时间点和服务进程实际拉起时间的差值，如果正好落在2-3小时区间，就能直接定位启动卡顿的具体阶段。
• 若耗时集中在WAL回放阶段：这是2.13.x版本的已知性能缺陷，当活跃时间序列规模突破百万级后，WAL回放过程中的series索引重建效率极低，回放全程TSDB持有文件锁，既不接收新写入数据、也不对外提供查询服务。如果采集链路没有配置3小时以上的写入重试缓存（比如remote write客户端本地持久化队列、pushgateway落盘配置），这个窗口期内产生的采样数据会直接丢弃，不会自动补录。
• 若耗时集中在WAL回放完成到服务就绪的阶段，直接排查两类配置：
  • 服务发现配置：新增的大量采集任务如果用了k8s_sd、consul_sd、dns_sd这类依赖第三方接口的服务发现模式，2.13版本默认单线程同步全量target列表，接口响应慢、target规模过万时会直接阻塞整个scrape调度器启动，直到所有target校验完成才会开始拉取数据
  • 规则配置：如果同步新增了大量recording rule、alerting rule，2.13版本启动时会预加载所有规则的计算索引，规则组规模过百时也会拉长启动空窗期
• 资源层卡点排查：监控重启过程中的进程内存、CPU、磁盘IO占用：
  • 若进程在重启过程中因为内存打满被系统OOM反复杀掉，会导致每次重启都要从头回放WAL、重复做head块压缩，循环拉长空窗时间
  • 若数据盘IO使用率持续打满，WAL回放和块压缩的速度会被磁盘IO拖慢，2.13版本没有做WAL回放的IO优先级调度，机械盘场景下百万级series的WAL回放耗时达到2-3小时属于已知现象
• 可落地的修复方案：
  • 重启前将日志级别调整为debug，定位具体卡点后针对性调优：服务发现阻塞就给SD对接的服务端提配资源、拆分单任务下过大的target列表；IO瓶颈直接更换SSD作为数据盘
  • 采集链路侧配置至少3.5小时的写入重试缓存，避免启动空窗期的数据永久丢失
  • 2.13.1是2019年发布的早期版本，后续2.13.x补丁分支、2.14+版本专门修复了大规模采集场景下WAL回放慢、服务发现阻塞启动的问题，确认卡点后可以优先升级同大版本的最新补丁包修复，不需要跨大版本调整现有配置

内容的提问来源于stack exchange，提问作者Abhishek Anvekar