如何通过脚本监控Redis哨兵状态并发送报警？-Redis-PHP中文网

用redis-cli -p 26379 sentinel master mymaster可查主节点当前ip和端口；flags含master且num-slaves≥1为基本健康信号，需结合info replication比对偏移量确认数据一致性。

如何通过脚本监控redis哨兵状态并发送报警？

用 `redis-cli` 连接哨兵并检查主节点状态

哨兵本身不提供 HTTP 接口，必须通过 Redis 协议连接其监听端口（默认 26379），用 SENTINEL 命令获取拓扑信息。直接连错端口（比如连了主库的 6379）是常见失败原因。

确认哨兵进程在运行：ps aux | grep redis-sentinel，并核对配置中 port 和 bind 设置
用 redis-cli -p 26379 -h 127.0.0.1 SENTINEL master mymaster 查主节点当前 IP 和端口；若报错 (error) ERR Unknown sentinel command，说明连的是普通 Redis 实例而非哨兵
返回结果中 flags 字段含 master 且 num-slaves ≥ 1 是基本健康信号；若 num-down-sentinels 或 num-other-sentinels 异常偏低，说明哨兵集群通信有问题

判断是否发生主从切换的可靠依据

仅看 SENTINEL masters 输出不够——它总是返回当前主节点，但无法区分是“稳定运行”还是“刚切完还没同步完”。真正要盯的是切换事件本身和后续状态收敛。

监听哨兵日志比轮询更及时：tail -f /var/log/redis/sentinel.log | grep "switch-master"，该行出现即表示切换已触发
切换后需验证：新主节点的 role 必须为 master（用 redis-cli -p <new_port> ROLE</new_port> 确认），且所有从节点 master_link_status 为 up
避免误报：如果 SENTINEL slaves mymaster 返回的从节点里有 flags 含 s_down 或 o_down，即使主节点正常，也意味着故障未完全恢复

用 Shell 脚本触发企业微信/钉钉报警

报警逻辑必须带去重和冷却，否则一次网络抖动可能触发几十条消息。脚本不应每次检测都发告警，而应记录上次告警时间戳并比对。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

用 date -d "@$(cat /tmp/redis_sentinel_last_alert 2>/dev/null)" +%s 2>/dev/null || echo 0 读取上一次告警时间
冷却期设为 300 秒（5 分钟）：当前时间减去上次时间 > 300 才允许发送，并在成功后更新 /tmp/redis_sentinel_last_alert
调用钉钉机器人示例：curl -X POST https://oapi.dingtalk.com/robot/send?access_token=xxx -H 'Content-Type: application/json' -d '{"msgtype": "text", "text": {"content": "Redis 哨兵检测到主节点切换：old=10.0.1.100:6379, new=10.0.1.101:6379"}}'
注意：curl 超时必须设短（如 --connect-timeout 5 --max-time 10），否则脚本卡住影响下一轮检测

定时任务里漏掉的关键细节

cron 默认环境变量极简，PATH 不包含 /usr/local/bin，导致找不到 redis-cli 或 curl；同时脚本内路径写相对路径会失败。

在 crontab 中显式声明环境：PATH=/usr/local/bin:/usr/bin:/bin SHELL=/bin/bash */2 * * * * /opt/scripts/check_sentinel.sh >> /var/log/redis_sentinel_check.log 2>&1
脚本开头加 cd $(dirname "$0") 或直接用绝对路径引用配置文件，比如 /etc/redis/sentinel.conf
不要依赖 whoami 判断用户——cron 以指定用户身份运行，但脚本内执行命令时权限可能受限；测试时用 sudo -u redis /opt/scripts/check_sentinel.sh 模拟真实场景

哨兵状态检查最易被忽略的不是命令怎么写，而是“什么算真正恢复”——比如主节点 IP 变了，但从节点复制偏移量没追平，此时应用仍可能读到旧数据。得结合 INFO replication 里的 master_repl_offset 和各从节点的 slave_repl_offset 对比才稳妥。