必须为每个Redis节点部署独立redis_exporter实例，因其仅采集所连节点本地数据，无法自动发现集群其他节点，单点采集会漏掉宕机节点、槽位迁移异常及只读副本的负载失真等问题。
Redis集群的健康状态不能只看cluster_state=ok，QBS（每秒查询数）波动也不等于业务异常——必须拆解到节点级指标、槽位分布和命令响应延迟三个维度交叉验证。
为什么单个redis_exporter连集群任意节点会漏数据
很多人误以为用redis_exporter -redis.addr redis://172.29.2.10:7000就能采集整个集群，实际它只会执行一次INFO和CLUSTER NODES，不主动遍历其他节点。当某个master宕机或槽位迁移未完成时，该 exporter 仍可能返回cluster_state=ok，但部分槽已不可写。
- 集群模式下，
redis_exporter不会自动发现并连接其他节点；它只采集所连节点本地视角的数据 - 若该节点是 replica，
connected_clients、instantaneous_ops_per_sec等指标反映的是只读负载，掩盖了 master 的真实压力 - MOVED/ASK 重定向失败时，exporter 可能静默跳过部分槽的统计，导致
redis_cluster_keys_count总和偏低
必须为每个Redis节点部署独立redis_exporter实例
这是唯一能保证指标完整性的做法。Prometheus 抓取目标不是“集群”，而是“每个运行中的 Redis 进程”。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每个节点上启动一个
redis_exporter，监听本地端口（如9121），参数指定本机 Redis 地址：-redis.addr redis://127.0.0.1:7000 - 在 Prometheus 中配置静态 targets 或使用服务发现（如 Kubernetes 的
ServiceMonitor），确保每个target对应一个redis_exporter实例 - 给每个 target 打上明确标签：
redis_role="master"、redis_shard="shard-1"、redis_addr="172.29.2.10:7000"，避免聚合时混淆
用PromQL识别真实健康问题而非心跳假象
redis_up == 1 和 redis_cluster_state == 1 只说明 exporter 能连上且集群协议层没报错。真正影响业务的是：
- 检查各 master 节点的
redis_connected_clients是否持续高于阈值（如 > 500），结合redis_blocked_clients判断是否存在客户端阻塞 - 用
sum by (redis_addr) (redis_cluster_slots_assigned)确认所有 16384 个槽是否全部分配；再用count by (redis_addr) (redis_cluster_slots_fail)查是否有失败槽 - 观测 QBS 波动：用
rate(redis_commands_total[5m])按cmd标签分组，重点看set、get、del的突增/归零——不是总量波动，而是某类命令异常才值得告警 - 排除慢命令干扰：云环境或高安全策略下需设
REDIS_EXPORTER_EXCLUDE_SLOWLOG_METRICS=true，否则redis_slowlog_length指标可能因权限拒绝而置空，导致面板显示断点
Grafana里QBS波动要关联延迟与错误率看
单独看 rate(redis_commands_total[1m]) 曲线容易误判。一次批量 MSET 可能拉高 QBS 却不增加延迟；而 GET 命令 P99 耗时从 0.3ms 涨到 8ms，即使 QBS 平稳也说明内存碎片或磁盘 AOF 刷写卡顿。
- 在同一个 Grafana 面板中并列展示：
rate(redis_commands_total{cmd=~"get|set"}[1m])、histogram_quantile(0.99, sum(rate(redis_cmd_duration_seconds_bucket[5m])) by (le, cmd))、rate(redis_rejected_connections_total[5m]) - 注意
redis_cmd_duration_seconds是直方图指标，必须用histogram_quantile计算分位数，直接查原始值无意义 - 如果 QBS 下跌伴随
redis_master_link_status == 0出现，优先排查主从复制中断，而不是应用层连接池配置
最容易被忽略的是：集群中某个节点的 redis_exporter 进程存活，但其采集的 redis_connected_clients 长期为 0，这往往意味着该节点已被踢出集群但进程未退出——此时它仍在被 Prometheus 抓取，却提供无效指标。需要在 alert rule 中加入 absent(redis_connected_clients > 0) 类检测逻辑，而不是依赖 up 状态。
