4. Redis监控指标体系与异常检测

Redis 的故障很少以“进程崩溃”这种直白方式出现，更多时候表现为延迟升高、内存膨胀、主从延迟扩大、持久化阻塞或集群槽位失衡。要在这类“半故障”状态下快速定位，必须建立一套分层的指标体系，并让告警之间形成关联，而不是孤立地看某一个数字。本节把 Redis 监控拆成五类指标——性能、内存、持久化、复制、集群，并给出阈值设定思路与告警关联分析方法。

一、性能指标：先看延迟，再看吞吐

性能指标的核心是延迟与吞吐。延迟方面，redis-cli --latency 给出的是客户端视角的往返延迟，而 INFO latencystats（Redis 7.0+）提供命令级延迟直方图，能区分是整体慢还是某类命令慢。吞吐方面，instantaneous_ops_per_sec 反映当前 QPS，total_commands_processed 的增量则用于计算趋势。

阈值设定不能只看绝对值。经验上，P99 延迟超过 1ms 就应关注，超过 5ms 需告警；但若业务本身是批量写入，基线可能本就偏高。更稳妥的做法是“基线 + 偏离”：以近 7 天同时段 P99 为基线，偏离 3 倍触发告警。此外，rejected_connections 持续增长说明连接数触顶，blocked_clients 大于 0 说明有客户端在阻塞命令（如 BLPOP）上等待，这两项应设为“非零即告警”。

二、内存指标：used_memory 与碎片率要一起看

内存是 Redis 最敏感的维度。used_memory 是分配器实际分配量，used_memory_rss 是操作系统看到的常驻内存，两者差值反映碎片。mem_fragmentation_ratio = used_memory_rss / used_memory，正常在 1.0～1.5 之间；大于 1.5 说明碎片严重，小于 1 说明发生了 swap，后者更危险。

阈值建议：used_memory 达到 maxmemory 的 80% 预警、90% 严重告警；碎片率大于 1.5 预警，大于 2.0 建议执行 activedefrag yes 或安排重启。evicted_keys 一旦非零，说明已触发淘汰策略，必须结合业务判断是否可接受——若 key 不应被淘汰，则说明容量规划失败。mem_fragmentation_ratio < 1 时，应立刻检查 /proc/<pid>/smaps 或系统 swap 使用量。

三、持久化指标：RDB 与 AOF 的阻塞信号

持久化指标关注“是否阻塞主线程”。RDB 方面，rdb_last_bgsave_status 必须为 ok，rdb_last_bgsave_time_sec 突然增大说明数据量或磁盘变慢，rdb_changes_since_last_save 过大则意味着故障时丢失窗口大。AOF 方面，aof_last_bgrewrite_status 与 aof_last_write_status 必须为 ok；aof_rewrite_in_progress 长期为 1 说明重写卡住；aof_delayed_fsync 大于 0 表示 fsync 被延迟，通常由磁盘 IO 饱和引起。

阈值上，rdb_last_bgsave_time_sec 超过 60 秒应告警；aof_delayed_fsync 非零即告警；latest_fork_usec 超过 100ms 说明 fork 阻塞明显，需关注内存页表大小。这些指标往往与内存指标联动：内存越大，fork 越慢，持久化阻塞越严重。

四、复制指标：offset 差值是核心

复制健康度看三个量：master_repl_offset、slave_repl_offset（从库视角为 master_repl_offset）以及 master_link_status。master_link_status 必须为 up；master_link_down_since_seconds 大于 0 即告警。延迟用 master_repl_offset - slave_repl_offset 衡量，通常应小于 1MB，超过 10MB 需告警。

另一个关键指标是 repl_backlog_active 与 repl_backlog_size。若从库断连时间超过 backlog 覆盖范围，会触发全量同步，表现为 sync_full 增长。因此 sync_full 与 sync_partial_ok 的比值应长期稳定，全量同步频繁说明 backlog 过小或网络抖动。

五、集群指标：槽位、节点与迁移状态

集群模式额外关注：cluster_state 必须为 ok；cluster_slots_assigned 应为 16384；cluster_known_nodes 与预期节点数一致；cluster_slots_pfail、cluster_slots_fail 非零说明有槽位不可用。迁移过程中 migrating、importing 状态应短暂出现，长期存在说明迁移卡住。

六、告警关联分析：从单点告警到故障链

孤立告警容易误判。例如“内存使用率 90%”本身可能只是正常增长，但如果同时出现 evicted_keys 上升、latency P99 升高、blocked_clients 增加，就构成一条清晰的故障链：内存压力 → 淘汰 → 延迟升高 → 客户端阻塞。下图给出五类指标之间的关联路径与典型告警组合。

关联分析的价值在于把“多个孤立告警”压缩成“一条可解释的故障链”。例如当 used_memory 超过 80%、evicted_keys 持续增长、P99 延迟同步上升时，应优先怀疑内存不足导致的淘汰与延迟，而不是先去查网络。反之，若 master_link_status 为 down、sync_full 激增、repl_backlog_size 偏小，则应先调整 backlog 与网络，而非扩容内存。

最后，指标采集频率要与故障恢复目标匹配：核心指标（延迟、内存、复制状态）建议 10～15 秒一次，持久化与集群状态可 30 秒一次。所有指标应带实例标签与时间戳，便于在告警触发时回溯同一时间窗口内的其他指标，从而完成从“单点告警”到“故障链定位”的闭环。