巡检第一步是确认从节点在线并能响应命令，需用 timeout 和 --connect-timeout/--command-timeout 避免卡住，非零退出码即标记“失联”；再解析 INFO replication 提取 role、master_link_status 等字段，以 master_link_status:up 为硬指标，结合 slave_repl_offset 和 master_sync_in_progress 判断同步状态；跨节点比对主从 offset 差值超 10000 且持续 2 次才告警；日志须带时间戳、TAB 分隔、每日分文件并支持 CRIT 快速检索。
检查 redis-cli 是否能连上从节点并获取复制信息
巡检第一步不是直接查主从延迟，而是确认从节点本身是否在线、能否响应命令。很多脚本失败是因为 redis-cli -h $slave_ip -p $slave_port INFO replication 连不上就卡住或报错，没设超时。
实操建议：
- 必须加
--connect-timeout 2和--command-timeout 2，避免网络抖动导致脚本 hang 住 - 用
timeout 5包裹整个命令，双重保险 - 检查返回值：非零退出码（如连接拒绝、认证失败）要立即标记为“失联”，不继续解析输出
- 示例片段：
timeout 5 redis-cli -h $slave_ip -p $slave_port --connect-timeout 2 --command-timeout 2 INFO replication 2>/dev/null
从 INFO replication 输出中提取关键字段并判断同步状态
Redis 的 INFO replication 输出是纯文本，但字段名不固定（比如主节点可能显示 master_host:10.0.1.100，从节点则有 role:slave、master_link_status:up、slave_repl_offset 等），直接用 grep + awk 容易漏掉空格或大小写差异。
实操建议：
- 用
grep -E '^(role|master_link_status|slave_repl_offset|master_last_io_seconds_ago)' | sed 's/[^:]*://'提取值，比单靠awk -F: '{print $2}'更稳 -
master_link_status:up是硬指标，只要它是down，说明复制链路已断，无需再比偏移量 -
master_last_io_seconds_ago超过 60 秒需告警——不是延迟高，而是主节点可能卡住或网络不通 - 不要只比对
slave_repl_offset和主节点的master_repl_offset，因为从节点 offset 更新有延迟；应结合slave_repl_offset和master_sync_in_progress:1判断是否正在全量同步
跨节点比对主从 offset 差值并设置合理阈值
主从 offset 差值反映复制延迟，但直接取差值容易误报：比如主节点刚执行完一个大 LRANGE，offset 暴涨，而从节点还没来得及追上。这时差值可能到几万，但实际只是瞬时抖动。
实操建议：
- 在从节点上执行
redis-cli INFO replication得到slave_repl_offset，再用相同方式从主节点取master_repl_offset（注意主节点 role 是 master，字段名一样） - 差值超过 10000 并持续 2 次巡检（间隔 30 秒）才触发告警，避免毛刺干扰
- 如果从节点处于
slave_read_only:yes但slave_repl_offset长时间不更新（比如连续 3 次巡检差值不变），大概率是复制线程卡死，需单独告警 - 别忘了权限：脚本里调用
redis-cli连主节点时，若启用了requirepass，必须带-a $PASSWD，否则INFO返回空
把结果写入日志并支持简单聚合统计
单纯 echo 到终端没用，巡检要留痕。但很多人直接 > /var/log/redis-check.log，结果日志滚不动、查起来费劲。
实操建议：
- 每行日志以 ISO8601 时间戳开头，例如
$(date -Iseconds)，方便 grep 和按时间排序 - 字段用 TAB 分隔：时间、实例IP:端口、role、master_link_status、offset_diff、告警等级（OK/WARN/CRIT）
- 每天生成独立文件，如
/var/log/redis-check.$(date +%Y%m%d).log，用logrotate或脚本自己清理 7 天前的 - 加一句
tail -n 20 /var/log/redis-check.$(date +%Y%m%d).log | awk '$6=="CRIT"{print}'就能快速看到今日严重问题
真正难的不是取数据，而是区分“暂时性延迟”和“实质性故障”。比如 master_link_status:up 但 slave_repl_offset 停滞，这种静默异常最易被忽略。每次巡检至少要验证三个维度：连通性、链路状态、数据流动态。
