3. 监控指标体系设计

Redis 集群监控最容易犯的错误，不是“没有指标”，而是“指标太多却没有分层”。一个中等规模的 Redis Cluster 往往有几十个节点、上千个 key 空间、数百个客户端连接，如果所有指标都用同一个采集频率、同一个告警阈值，结果就是：真正重要的故障信号被淹没在噪声里，而慢查询、内存碎片、主从延迟这些慢性问题又迟迟发现不了。因此，指标体系设计要解决两个问题：采什么和多久采一次。

一、按“回答什么问题”划分五类指标

与其按 Redis 命令分类，不如按运维要回答的问题分类。这样每一类指标都对应一个明确的判断动作。

性能指标回答“Redis 现在快不快”。核心包括：instantaneous_ops_per_sec（当前 QPS）、redis_cli_latency 的 P50/P95/P99 分位、慢查询数量 slowlog_len、命令执行耗时分布。注意平均延迟会掩盖长尾，P99 才是用户体验的真实边界。例如某节点 P99 从 1.2ms 升到 8ms，即使平均延迟仍是 0.9ms，也说明存在阻塞或大 key。

资源指标回答“机器和进程还撑得住吗”。包括 CPU 使用率、内存 used_memory 与 used_memory_rss、内存碎片率 mem_fragmentation_ratio、网络带宽、磁盘 IO（AOF/RDB 落盘时）、连接数 connected_clients 与 blocked_clients。其中内存碎片率持续高于 1.5 或低于 1 都值得关注：前者说明分配器碎片多，后者说明发生了 swap，性能会断崖式下跌。

可用性指标回答“服务还在不在”。包括节点存活状态、集群状态 cluster_state:ok、主从复制链路 master_link_status:up、复制偏移量差值 master_repl_offset - slave_repl_offset、哨兵或集群选主是否完成。可用性指标通常用布尔值或状态码表达，采集频率要高，因为故障切换窗口往往只有几秒。

容量指标回答“还能装多少、还能撑多久”。包括各节点 used_memory 占 maxmemory 的比例、key 总数 db0:keys、集群槽位分布是否均衡、单 key 最大长度、过期 key 比例。容量指标不需要秒级采集，但需要趋势预测：按当前日增内存推算，还有多少天触发 maxmemory-policy 淘汰。

错误率指标回答“有多少请求失败了”。包括 rejected_connections、keyspace_misses 与命中率、errorstats 中的命令错误计数、集群 cluster_stats_messages_* 异常、客户端超时次数。错误率要和 QPS 一起看：QPS 不变而错误率上升，通常是资源瓶颈；QPS 下降且错误率上升，可能是网络分区或主从切换。

二、采集频率不是“越密越好”

采集频率由三个因素共同决定：指标变化速度、故障容忍窗口、采集开销。Redis 的 INFO 命令本身很轻，但每秒对上百个节点执行一次 INFO all，再加上 Prometheus 拉取、存储、告警计算，开销会累积。更关键的是，高频采集会让告警抖动，比如主从复制偏移量在正常网络抖动下也会短暂波动，如果 1 秒采一次并立即告警，运维会被误报淹没。

一个可落地的频率规划如下：

注意“告警延迟容忍”不是采集间隔，而是从异常发生到告警触发的最大可接受时间。可用性指标容忍度最低，所以采集要密；容量指标容忍度高，可以用 5 分钟甚至 15 分钟采集一次，再配合趋势预测。

三、从指标到判断：三个联动示例

单看一个指标很难定位问题，指标之间要形成判断链。

示例一：延迟升高但 CPU 不高。如果 P99 从 1ms 升到 10ms，而 CPU 使用率只有 30%，QPS 也没有明显变化，优先怀疑大 key 或慢命令。此时应查看 SLOWLOG GET 10，观察是否有 KEYS *、HGETALL 大 hash、ZRANGE 大集合等命令。这类问题不会推高 CPU，但会阻塞单线程。

示例二：内存使用率接近 maxmemory。当 used_memory / maxmemory 超过 80%，且 evicted_keys 开始增长，说明淘汰已经发生。此时要区分是“正常淘汰”还是“异常增长”：如果 key 总数稳定而内存持续上升，可能是大 key 或碎片；如果 key 总数同步上升，则是业务写入量增长，需要扩容或调整过期策略。

示例三：主从延迟持续增大。监控 master_repl_offset - slave_repl_offset，正常应在几百字节内波动。如果差值持续超过 1MB 且不回落，说明从节点同步跟不上，可能是网络带宽不足、从节点磁盘慢（AOF 落盘）、或主节点写入量突增。此时读从节点会读到旧数据，需要评估是否将读流量切回主节点。

四、指标命名与标签设计

在 Prometheus 体系中，指标命名和标签决定了后续查询和告警的灵活性。建议统一采用 redis_<类别>_<指标名> 的命名方式，例如 redis_perf_latency_p99、redis_res_mem_used_ratio、redis_avail_master_link_status。标签至少包含 cluster、node、role（master/slave）、instance。这样在告警规则里可以按集群聚合，也可以下钻到单节点。

需要特别注意的是，role 标签会随主从切换变化。如果告警规则写死 role="master"，切换后可能漏报或误报。更稳妥的做法是同时监控主从两个角色，并在告警表达式中用 max by(cluster) 聚合，避免因角色变化导致指标断档。

五、采集频率与存储成本的平衡

假设一个 30 节点的 Redis 集群，每节点暴露 200 个指标，采集间隔 15 秒，则每天产生约 30 × 200 × 5760 = 3456 万 个样本点。如果全部保留 90 天，存储和查询成本都会很高。实际做法是分层：高频指标（可用性、错误率）保留 15 天；性能指标降采样到 1 分钟保留 90 天；容量趋势降采样到 5 分钟保留 1 年。这样既保证故障排查有足够精度，又控制长期成本。

最后，指标体系不是一次设计完就固定不变的。建议每季度回顾一次：哪些指标从未触发过告警、哪些告警长期误报、哪些故障当时缺少指标支撑。把“没用的指标”降频或删除，把“漏报的指标”补上，才能让监控体系持续贴近真实运维需求。