rdb_last_bgsave_status和aof_last_write_status为err时直接暴露持久化失败风险；rdb_last_bgsave_time_sec突增预示fork或i/o压力，是慢查询前置预警信号。
redis-cli INFO persistence 里哪些字段直接暴露持久化风险
看 rdb_last_bgsave_status 和 aof_last_write_status 是最直接的。如果值是 err，说明上一次 RDB 或 AOF 写入失败了，但 Redis 仍继续服务——这种“带病运行”往往在后续某个时间点突然卡住，比如下一次 fork 触发时资源不足，导致命令阻塞超 100ms。更隐蔽的是 rdb_last_bgsave_time_sec 突然变长（比如从 0.2s 涨到 8s），这通常意味着内存页拷贝压力大，可能正和慢查询同时发生。
别只盯着成功/失败状态，还要对比 used_memory_rss 和 used_memory：如果 mem_fragmentation_ratio > 1.5 且 rdb_last_bgsave_time_sec 同步飙升，大概率是内存碎片+fork 耗时叠加，slowlog 里会集中出现 set、hmset 这类写命令延迟突增。
Grafana 面板里必须盯住的 3 条时间曲线
不是所有指标都值得加进告警，但以下三条曲线一旦异步偏移，基本能锁定持久化干扰：
-
redis_persistence_rdb_last_bgsave_time_seconds（来自 redis_exporter）——跳变即危险信号 -
redis_commands_duration_seconds_count{cmd=~"set|hmset|del"}——写命令调用量激增但响应时间没涨？先别高兴，可能是被 fork 卡在队列里还没执行完 -
process_cpu_seconds_total{job="redis-exporter"}——注意不是 Redis 进程的 CPU，而是 exporter 自身的；如果它突然抖动，常因 Redis 正在执行耗时INFO或阻塞式BGSAVE，导致 exporter 抓不到完整指标，面板出现断点或数据延迟
为什么 slowlog 里看不到“被持久化拖慢”的命令
slowlog 只记录命令**执行阶段**耗时，不包含排队等待时间。而持久化引发的慢查询，本质是命令在主线程队列里“等 fork 结束”，这部分等待不会计入 usec_per_call。你看到的可能是：set 命令平均耗时仍是 0.3ms，但 P99 延迟突然跳到 400ms——这就是排队效应。
验证方法很简单：redis-cli --latency -h your-redis-host -p 6379 持续跑 60 秒，如果输出里出现大量 >100ms 的抖动，且和 rdb_last_bgsave_time_sec 曲线峰值对齐，基本可判定是持久化干扰。这时候翻 INFO stats 里的 instantaneous_ops_per_sec，大概率会发现它在 bgsave 期间掉到个位数。
配置 redis_exporter 时漏掉 --redis.set-client-name 就容易误判
默认情况下，redis_exporter 用匿名 client 连 Redis，每次采集都新建连接。如果 Redis 开启了 maxclients 限制，exporter 自身就可能占掉几十个连接，再碰上 BGSAVE fork，系统负载一高，rejected_connections 就开始上涨——你以为是业务连不上，其实是 exporter 把连接池打满了。
解决办法是在启动参数里加上：--redis.set-client-name="redis-exporter"，然后在 Redis 侧用 CLIENT LIST 确认它始终复用同一个连接。否则 Grafana 上看到的 connected_clients 曲线毛刺，八成是 exporter 自身行为，不是业务真实连接波动。
rdb_last_bgsave_time_sec 当成纯运维指标——它其实是一条“延迟前置预警线”。只要它连续两次超过平时均值的 3 倍，后面 30 秒内大概率出现慢查询抖动，无论 slowlog 是否已记录。
