Redis集群性能监控必须按角色分层采集：主节点关注used_memory、QPS及命中率；从节点检查master_link_status和复制偏移差；哨兵节点通过INFO sentinel确认选举与主节点识别；CLUSTER INFO和CLUSTER NODES用于验证槽位分配与节点状态，配合Prometheus/Nightingale实现带角色标签的自动告警与聚合分析。
Redis集群性能监控不能只靠 INFO 命令凑合看，必须建立分层采集 + 关键指标告警 + 多角色区分的闭环机制。
怎么用 INFO 命令精准抓取集群各角色指标
直接执行 redis-cli -h 10.0.1.10 -p 6379 INFO 返回的是单节点快照，对集群无效。你需要按角色分别采集：
- 主节点：重点关注
used_memory、instantaneous_ops_per_sec、keyspace_hits/keyspace_misses，计算缓存命中率 - 从节点：必须检查
master_link_status（值为up才正常）、slave_repl_offset与主节点master_repl_offset的差值，延迟超过 10MB 就要告警 - 哨兵节点：运行
redis-cli -h 10.0.1.11 -p 26379 INFO sentinel，盯住sentinel_leader和sentinel_masters字段，确认选举是否稳定、主节点是否被正确识别
别漏掉 CLUSTER INFO 和 CLUSTER NODES ——前者告诉你槽位分配是否均匀（cluster_state:ok 且 cluster_slots_assigned:16384），后者能快速发现失联节点（状态为 fail 或 noaddr）。
为什么用 Nightingale/Prometheus 而不是 Redis-Stat
Redis-Stat 只能轮询单个节点、不支持标签打标、无法关联主从关系，对集群形同虚设。而 Nightingale 或 Prometheus 的 Redis Exporter 支持：
- 通过
labels区分角色：{instance="redis-master-01", role="master", cluster="prod"} - 自动推导主从延迟：用
redis_replication_offset_delay指标替代人工比对 offset - 聚合计算集群级指标：比如所有主节点的平均
instantaneous_ops_per_sec，或某集群内mem_fragmentation_ratio最大值
配置时注意：哨兵实例要单独配 address = "10.0.1.11:26379" 并启用 sentinel 模式，否则采集不到主节点切换事件。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
used_memory 和 used_memory_rss 差太多怎么办
当 mem_fragmentation_ratio = used_memory_rss / used_memory > 1.5，说明内存碎片严重，常见于频繁写入+删除小 key 的场景。这不是配置问题，而是进程内存管理行为：
- 先确认是否开启
activedefrag yes（Redis 4.0+），并调高active-defrag-threshold-lower（默认 10，建议设为 25） - 如果碎片率持续 > 2.0，且
latest_fork_usec明显升高（比如 > 500ms），说明 fork 开销变大，RDB/AOF 重写会更卡——这时要考虑重启节点或迁移数据 - 切忌直接 kill -9，要用
redis-cli SHUTDOWN SAVE确保落盘，再启新进程
注意：碎片率低 ≠ 内存安全，used_memory 接近 maxmemory 80% 就该触发淘汰策略检查或扩容了。
告警阈值不能统一套用，必须按角色和业务定
同一指标在不同角色上健康标准完全不同：
-
connected_clients：主节点可设 70%maxclients告警，但从节点若长期 > 100，大概率是客户端误连从库（应只读） -
rejected_connections：只要持续 > 0 就必须告警，说明连接池或maxclients配置不足，不是“稍等就好”的问题 -
keyspace_hits命中率：缓存型业务要求 > 98%，但 Session 存储类业务天然 miss 高，设 85% 更合理
最容易被忽略的是 rdb_last_bgsave_status 和 aof_last_write_status ——它们不是数值型指标，却是数据可靠性的第一道防线。只要不是 ok，就得立刻查日志，而不是等磁盘满才处理。
