必须为每个Redis节点单独部署redis_exporter实例并显式标注角色标签，Prometheus需按节点独立抓取，配合PromQL组合指标判断槽位分布与健康状态，cluster_state=ok仅表示心跳正常而非业务可用。
如何用 redis_exporter 抓取 Redis 集群节点指标
Redis 原生不暴露 Prometheus 可读的指标格式，必须通过 redis_exporter 作为中间代理来采集。它会连接每个 Redis 节点（包括 master 和 replica），调用 INFO 命令并转换为 Prometheus 格式。
关键点：集群模式下，redis_exporter **不能只连一个节点**——它不会自动发现其他节点。你得为每个节点单独启动一个 exporter 实例，或用服务发现动态配置。
- 推荐方式：每个 Redis 节点所在机器上部署一个
redis_exporter，监听本地6379（或对应端口），再统一由 Prometheus 抓取http://node-ip:9121/metrics - 避免用单实例 +
--redis.addr指向集群任意节点——它只会采集该节点数据，且在重定向（如 MOVED）时可能失败 - 若使用 TLS 或 requirepass，需显式传参：
--redis.password=xxx、--redis.tls-ca-cert-file=ca.pem - 集群节点名建议通过
--web.listen-address+static_configs中的labels手动标注，例如{job="redis-cluster", node="redis-01"}，否则所有指标都只有instance，无法区分角色
Prometheus 抓取配置要注意哪些坑
抓取配置写错，会导致指标缺失、重复或 label 冲突。最常见问题是把多个 Redis 节点配成同一个 job_name 却没加唯一标识。
正确做法是：每个节点独立 target，或用 relabel_configs 注入角色信息。Redis 集群中节点角色（master/replica）无法靠 exporter 自动识别，必须人工标记或从外部同步。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不要这样写（所有节点混在一个 job，无区分）：
job_name: redis<br> static_configs:<br> - targets: ["10.0.1.10:9121", "10.0.1.11:9121"]
- 应该这样（显式打标）：
job_name: redis-cluster<br> static_configs:<br> - targets: ["10.0.1.10:9121"]<br> labels:<br> node: "redis-01"<br> role: "master"<br> - targets: ["10.0.1.11:9121"]<br> labels:<br> node: "redis-02"<br> role: "replica"
- 如果用 DNS 或 Consul 发现，务必在
relabel_configs中用source_labels提取 hostname 或 tag，并映射到role，否则 Grafana 里无法按角色筛选 - Prometheus 抓取间隔建议设为
15s；太短（如5s）会增加 Redis 的INFO调用压力，尤其集群节点多时
Grafana 里怎么查集群健康与槽位分布
原生 redis_exporter 不直接暴露 CLUSTER NODES 或 CLUSTER SLOTS 解析结果，所以「槽是否均匀」「是否有 fail 节点」这类判断要靠组合指标 + PromQL 实现。
核心思路：用 redis_instance_info{role="master"} 看节点在线状态；用 redis_cluster_keyspace_hits_total / redis_cluster_keyspace_misses_total 推断流量是否倾斜；用 redis_connected_clients + redis_blocked_clients 辅助判断负载异常。
- 查是否有离线 master：
count by (node) (redis_up{job="redis-cluster"} == 0) - 查各 master 的槽数量（需提前在 exporter 启动时加
--redis.cluster.enabled=true，并确保能执行CLUSTER SLOTS）：redis_cluster_slots_assigned{role="master"} - 查 key 分布是否严重倾斜（对比各 master 的
redis_db_keys）：max by (node) (redis_db_keys{db="db0"}) / avg by () (redis_db_keys{db="db0"}) > 3 - Grafana Dashboard 推荐导入 ID
763（官方 Redis Exporter Dashboard），但注意它默认不显示集群槽位图——得手动加 panel，用redis_cluster_slots_assigned柱状图 +redis_cluster_state状态灯
为什么 cluster_state=ok 但仍有请求失败
redis_cluster_state{state="ok"} 只表示当前节点能连通集群总线并收到一致的配置纪元（config epoch），不代表整个集群对外可用。真实故障常发生在网络分区、主从切换未完成、或客户端缓存了过期 slot 映射时。
这时候 Prometheus 上看到的指标一切正常，但业务报 Moved 或 Ask 错误——监控链路在这里断了。
- 必须额外采集客户端侧指标：比如 Lettuce 的
lettuce_commands_failed_total{error="MOVED"}，或自定义埋点记录重定向次数 - Redis 本身不暴露 slot 映射变更事件，所以无法靠服务端指标预判
Moved尖峰；只能靠突增的redis_commands_total{cmd="cluster"}+redis_cluster_info_last_refresh_time_seconds偏差来间接推测 - 真正可靠的集群健康信号，其实是业务成功率 + P99 延迟，而不是
redis_cluster_state——后者只是个“心跳”，不是“脉搏”
