rdb_last_bgsave_status仅记录上一次bgsave完成结果（ok/err），不能判断当前卡住，需结合rdb_bgsave_in_progress=1且rdb_current_bgsave_time_sec>300秒做早期预警，并联动日志、磁盘、selinux和内核日志交叉验证根因。
如何用 rdb_last_bgsave_status 做失败预警
rdb_last_bgsave_status 是 INFO persistence 中唯一能直接告诉你“上一次 BGSAVE 成没成”的字段，值只有 ok 或 err。它不反映当前过程，只记录终点结果——所以不能靠它判断“正在卡住”，但非常适合做失败后的告警触发点。
真正有效的监控策略是：持续采集该字段，一旦从 ok 变为 err，立刻触发告警，并联动查日志和磁盘。别等它长期为 err 才反应，第一次变 err 就是信号。
- 它不会自动恢复：即使后续某次成功了，这个字段也会更新为
ok，但告警系统必须能捕获“状态翻转”而非“静态值” - 它不带上下文：
err不说明原因，必须立刻读/var/log/redis/redis-server.log，搜bgsave或No space left on device - 它和
stop-writes-on-bgsave-error强绑定：一旦出现err且该配置为yes（默认），写命令会立即返回(error) MISCONF ...
为什么单看 rdb_last_bgsave_status 会漏掉关键问题
这个字段只在子进程退出后才更新，而子进程可能卡在 sys_write、do_sync_read 等系统调用里不动，此时 rdb_last_bgsave_status 还是上一次的 ok，但 rdb_bgsave_in_progress 已经卡在 1 超 5 分钟——你完全收不到失败通知，只看到“一直没更新”。
也就是说：rdb_last_bgsave_status: err 是失败的确认，但不是失败的最早信号；rdb_bgsave_in_progress: 1 长时间不归零，才是更早、更危险的征兆。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 监控必须同时抓
rdb_bgsave_in_progress和rdb_current_bgsave_time_sec：后者 > 300 秒且前者 = 1，就该发“BGSAVE疑似卡死”告警 -
rdb_last_bgsave_status单独设阈值无意义，比如连续 5 分钟为err才告警？太晚了——写入早就被禁了 - 它无法区分“失败一次”和“持续失败”，而业务关心的是“是否还能写”，不是“失败几次”
告警时必须交叉验证的三个外部线索
收到 rdb_last_bgsave_status: err 后，不要只盯 Redis 内部指标。90% 的真实根因藏在系统层，必须秒级拉取三类信息：
- 查磁盘真实路径：
redis-cli CONFIG GET dir返回的路径，再跑df -h <path></path>和df -i <path></path>——很多故障发生在挂载子目录，/满不等于 Redis 目录满 - 查 SELinux 是否拦截：
ausearch -m avc -ts recent | grep redis，若出现avc: denied { write }，就是权限策略拦住了落盘 - 查内核 OOM 或 fork 失败：
dmesg -T | tail -20看有没有Out of memory: Kill process或fork: Cannot allocate memory
最容易被忽略的复杂点：rdb_last_bgsave_status 不代表“最近一次尝试”
它只记录“最近一次完成的 BGSAVE 结果”。如果 BGSAVE 子进程 fork 失败（比如 vm.overcommit_memory=0 且内存紧张），Redis 根本不会启动写盘流程，rdb_last_bgsave_status 就不会更新，仍保持旧值。此时你看到的是“还是 ok”，但实际已经无法持久化。
这种情况下，rdb_bgsave_in_progress 一直是 0，rdb_changes_since_last_save 却在涨——这才是更隐蔽的失效信号。监控逻辑里必须包含这个组合判断，否则预警永远滞后。
