Redis如何监控集群状态避免Slot覆盖不全_使用redis-cli --cluster check定期巡检健康度-Redis-PHP中文网

redis-cli --cluster check 更可靠，因其主动模拟槽位映射、逐节点握手并验证主从关系与槽覆盖完整性，而 cluster info 仅读取本地缓存易漏“幽灵槽”或跨节点不一致。

redis如何监控集群状态避免slot覆盖不全_使用redis-cli --cluster check定期巡检健康度

redis-cli --cluster check 为什么比 cluster info 更可靠

redis-cli --cluster check 不是简单查状态，而是主动模拟槽位映射、逐节点握手、验证主从关系和槽覆盖完整性。它会真正连接所有节点（包括从节点），检查每个 slot 是否有且仅有一个主节点负责，并确认从节点是否在正确复制对应主节点的数据。而 cluster info 只读取本地节点视角的元数据缓存，容易漏掉跨节点不一致或“幽灵槽”（slot 被标记为 assigned，但无节点实际服务）。

常见错误现象：集群 cluster_state: ok，但客户端频繁报 CLUSTERDOWN；cluster_slots_ok 显示 16384，但部分 key 写入失败——这往往是因为某个主节点宕机后，其从节点未成功 failover，但元数据还没来得及更新。

必须用集群中任意一个节点的地址 + 端口执行，不能加 -c（--cluster 模式自带集群发现逻辑）
若集群启用了密码，需显式传 -a ，否则部分节点握手会失败并静默跳过
输出末尾的 [OK] 行才是最终结论；中间出现 *** Notice: 或 *** Warning: 都代表潜在风险，不能忽略

如何识别 check 输出里的关键异常信号

运行 redis-cli --cluster check 127.0.0.1:7001 -a mypass 后，重点盯以下几类行：

Slots coverage: 16383/16384 → 槽覆盖不全，立刻查缺失 slot 归属（看下一行 “The following slots are not covered”）
M: xxxxxx ... 0-5460 后面跟着 -> 0 或 -> FAIL → 该主节点声称负责这些 slot，但实际没被任何节点承认，说明它已失联或配置错乱
S: yyyyyy ... 0-5460 出现在 slave 行但没有对应 M: 主节点 → 从节点悬空，无法接管
WARNING: The node has a non-zero ping_sent value → 节点长时间未响应心跳，可能网络分区或进程卡住

注意：cluster nodes 输出里 ping-sent 和 pong-recv 时间戳差值超过 5 秒，就值得警惕；--cluster check 会把这类延迟直接转成 warning。

定期巡检脚本里必须校验的退出码和关键词

redis-cli --cluster check 的退出码不是 0/1 二元判断：它成功完成全部检查且无 warning 是 0；有 warning 是 1；遇到致命错误（如无法连接任一节点）是 124。只靠 $? 判断不够，必须 grep 关键词：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

必须包含 "Slots coverage: 16384/16384" —— 这是健康底线
不能包含 "FAIL"（大写，排除正常日志里的单词）或 "Warning"（首字母大写）
建议同时检查 "M:" 行数是否等于 cluster_size 值，防止节点元数据残留

示例片段（Bash）：

output=$(/usr/local/bin/redis-cli --cluster check $HOST:$PORT -a "$PASS" 2>&1)<br>
if ! echo "$output" | grep -q "Slots coverage: 16384/16384"; then<br>
  echo "CRITICAL: slot coverage incomplete" >&2<br>
  exit 2<br>
fi<br>
if echo "$output" | grep -q -E "(FAIL|Warning)"; then<br>
  echo "WARNING: check reported anomalies" >&2<br>
  exit 1<br>
fi

什么时候不能只依赖 --cluster check

--cluster check 是强一致性快照，但它不反映实时负载或慢请求堆积。比如所有 slot 都 ok，但某个主节点 CPU 持续 100%、latency latest 超过 500ms，--cluster check 完全不会报警。

真正线上可用的监控必须组合使用：

每分钟跑一次 --cluster check（低频，避免压测式扫描）
每 10 秒采集一次各节点的 INFO replication 和 INFO stats，关注 master_last_io_seconds_ago 和 rejected_connections
对 client 端错误率做聚合（如 CLUSTERDOWN 出现频率突增），这是最真实的业务视角

最容易被忽略的一点：检查脚本本身运行在哪个网络环境。如果监控机和 Redis 集群不在同一内网，DNS 解析延迟或防火墙策略可能导致 --cluster check 连接部分节点超时，误报为节点不可达——务必先用 telnet 或 nc 验证所有 host:port 可达。