持久化监控要看什么
监控持久化不能只看进程是否在运行：快照与 AOF 重写是否成功、fork 耗时是否稳定、磁盘余量是否充足、复制断开次数是否异常，都是需要在故障前就纳入告警的指标。这些信息几乎都能从 INFO 的不同分节里取到，配合磁盘检查就能覆盖绝大多数「悄悄坏掉」的情形。
基本信息
| 适用平台 | Redis 全版本（字段名随版本略有差异） |
|---|---|
| 主要数据源 | INFO persistence、INFO stats、INFO replication |
| 必看字段 | rdb_last_bgsave_status、aof_last_bgrewrite_status、latest_fork_usec |
| 配合参数 | save、appendonly、appendfsync、maxmemory |
| 磁盘检查 | df -h 数据目录所在分区 |
典型使用场景
- 日常巡检：确认快照与 AOF 状态均为 ok
- 重启前核查：避免带着失败的快照执行停机
- 容量规划：观察磁盘使用率趋势与 fork 耗时变化
- 复制健康度评估：查看主从链路状态与 offset 差值
- 故障复盘：用 sync_full 与断连次数判断问题发生的时间点
关键指标采集
关键指标采集
INFO persistence | grep -E 'rdb_last_bgsave_status|aof_last_bgrewrite_status|aof_last_write_status|rdb_last_save_time|latest_fork_usec'
INFO stats | grep -E 'total_forks|sync_full|sync_partial_err|expired_keys|evicted_keys'
INFO replication | grep -E 'role|connected_slaves|master_link_status|master_repl_offset|slave_repl_offset'
INFO memory | grep -E 'used_memory_human|used_memory_peak_human|maxmemory_human'
df -h /var/lib/redis # 数据目录所在分区余量告警项与建议阈值
| 指标 | 建议阈值 | 含义 |
|---|---|---|
| rdb_last_bgsave_status | 不等于 ok 立即告警 | 最近一次快照失败 |
| aof_last_write_status | 不等于 ok 立即告警 | AOF 刷写出现错误 |
| 磁盘使用率 | 超过 85% 预警 | 写满会导致持久化失败与实例只读 |
| master_link_status | down 超过 30 秒告警 | 复制链路断开 |
| offset 差值 | 持续增长超阈值告警 | 从库长时间跟不上 |
| latest_fork_usec | 明显高于历史基线告警 | 大内存或 THP 导致的 fork 变慢 |
复制断连次数（sync_full 的突增）常比瞬时延迟更有价值：它说明 backlog 配置偏小或网络存在结构性问题，是排查复制抖动的关键线索。
只采 used_memory 而不看持久化状态：快照长期失败无人知晓，直到磁盘写满或实例重启时才暴露数据回退。
基线的价值高于阈值本身：先在稳定运行期采集两三周的 fork 耗时、磁盘增长速率与复制延迟曲线，再把告警线设在合理偏离处。凭空拍一个数字，不是频繁误报就是长期不报，最后被值班人员忽略。