记一次 remote write 故障（thanos)

架构

若干边缘prom向thanos 集群通过remote write 接口同步数据。

事故起因

凌晨5点时分，网络大面积瘫痪，持续约1小时。期间同步受阻，机器流量骤减。

故障描述

网络逐渐恢后，上grafana查看监控时，发现图表中展示的图形是滞后的，即看不到最近时段的监控。

即使不断刷新，也只能看到半小时以前的监控。

由于prom在remote write 时，为防止同步失败，有自动重传机制。正常来说一段时间后，缺失的数据就能补齐了，然而在观察了2小时后，情况仍未改善。遂介入排查。

过程

prometheus rw 配置

通过prometheus_remote_storage_pending_samples 查询，可以看到各个prom的值接近其配置上限

max = min_shards * max_samples_per_send

期初认为，同步滞后是因为prom这边同步太慢所致。于是乎想到修改 max_shards 来增加同步并发数。

由于修改配置，需要reload prom。reload 时, 会清空remote write queue。此时在队列中尚未发送的数据再也无法同步到thanos。

将max_shards 由100 上调至200 后，在观察监控，发现当前时间节点的监控数据能够同步过去了。

但是在观察一段时间后，发现prometheus_remote_storage_pending_samples 指标不降反升。正常情况，该指标都维持在一个较低水平。同时又开始出现数据同步滞后情况。

thanos 日志排查

此类情况之前在网络丢包时，也常常出现。都是等网络正常后，自己慢慢恢复。于是转换下思路，会不会是服务端的问题。

遂查看thanos-receive 日志。首先看到的是：

component=receive-writer msg="Error on ingesting samples that are too old or are too far into the future"

意思是说，插入了太久之前的或者未来时间点的序列。

首先检查了各机器上的时间，发现时间一致，不可能出现插入未来时间的时间序列。

这么一来就是插入了过期的时间序列。这里过期分两种：

1. 插入了早于当前已有的时间序列
2. 插入的时间序列非当前wal对应的时间范围

看过prom remote