把持久化纳入监控
持久化是典型的「平时不出声、出事才发现坏」：如果没有把它纳入监控，很可能出现连续几个月没有成功快照、或者写入持续失败却无人察觉的情况。需要盯的指标有：最近一次快照的时间与结果、AOF 的写入与重写状态、数据目录所在磁盘的剩余空间、fork 耗时以及内存余量。最基础的两条告警是「超过 N 小时没有成功快照」和「磁盘剩余低于阈值」。
基本信息
| 快照状态 | rdb_last_bgsave_status、rdb_last_save_time |
|---|---|
| AOF 状态 | aof_last_write_status、aof_last_bgrewrite_status |
| 资源指标 | 磁盘余量、fork 耗时、内存余量 |
| 采集方式 | INFO persistence、INFO stats、df 等命令 |
| 基础告警 | 长期无成功快照、磁盘余量过低 |
典型使用场景
- 建立持久化专项监控面板，脱离只有节点级存活监控的状态
- 快照失败告警：磁盘写满或权限异常时的第一信号
- 统计 fork 耗时趋势，提前发现实例规模带来的隐患
- 配置变更后的验证：确认新的持久化参数真的在生效
- 值班交接：固化一份持久化状态检查清单
采集示例
采集示例
redis-cli INFO persistence
redis-cli INFO stats | grep -E 'latest_fork_usec'
df -h /data/redis
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli CONFIG GET save # 对照规则确认节奏是否符合预期
redis-cli CONFIG GET appendfsync # 确认刷盘策略与预期一致指标与阈值建议
| 指标 | 含义 | 建议阈值 |
|---|---|---|
| rdb_last_bgsave_status | 最近一次快照结果 | 非 ok 立即告警 |
| rdb_last_save_time | 上次成功快照时间 | 超过规则最大间隔即告警 |
| aof_last_write_status | AOF 写入状态 | 非 ok 说明刷盘受阻 |
| 磁盘余量 | 数据目录所在分区 | 低于预估增量与重写峰值即告警 |
阈值必须结合业务写入速率来定。照抄通用模板会产出大量无意义告警，最终把真正重要的信号淹没，值班人员反而开始忽略告警。
监控目标要覆盖全部节点，包括从节点。从库长期快照失败时，它并不能在主库故障后承担新的写入压力，整体恢复能力被严重削弱，但这个问题在平时几乎看不出来。