哨兵节点自身必须被监控，否则高可用体系存在单点盲区；需用sentinel sentinels命令检查各哨兵状态，核对flags、心跳时间、ip端口一致性，并验证进程、端口监听、网络连通性及日志异常。
哨兵节点自身必须被监控，否则整个高可用体系就存在单点盲区。 单靠 SENTINEL MASTER 查主节点状态，完全无法发现某个 redis-sentinel 进程是否卡死、崩溃或网络隔离——而只要 ≥1 个哨兵失联，就可能影响 quorum 投票，导致客观下线失败或延迟。
用 SENTINEL SENTINELS 命令直查哨兵集群视图
每个哨兵节点都维护着它所知的其它哨兵列表，这是最轻量、最实时的自检方式：
- 连接任一正常运行的哨兵（如
redis-cli -p 26379），执行SENTINEL SENTINELS mymaster（mymaster替换为你配置的 master name） - 返回结果中每个成员应包含
flags字段：正常哨兵是sentinel，若出现disconnected或odown，说明该哨兵已失联或被其它哨兵标记为客观下线 - 注意
last-ping-reply和last-ok-ping-reply：超过down-after-milliseconds（默认 30000ms）未更新，基本可判定该哨兵心跳异常 - 不要只看数量，要逐条核对 IP+端口是否与你部署的一致；常见错误是配置了错误的哨兵地址，导致部分哨兵“看不见彼此”
检查哨兵进程和 TCP 连接状态
命令行层面的验证不能跳过，尤其在容器或 systemd 环境下：
- 用
ps -ef | grep redis-sentinel确认进程确实在跑，且启动参数指向的是你修改过的sentinel.conf，不是默认模板 - 用
netstat -tlnp | grep :26379（或对应端口）确认监听地址是0.0.0.0:26379或具体内网 IP，而非127.0.0.1:26379（后者会导致其它哨兵连不上） - 从其它哨兵节点上执行
telnet 192.168.x.x 26379，验证基础网络连通性；防火墙/安全组常在此处静默拦截 - 如果使用 Docker，确认容器启用了
--network host或正确映射了 26379 端口，且sentinel announce-ip配置与宿主机实际可达 IP 一致
通过日志识别哨兵自身异常信号
哨兵日志比 Redis Server 日志更“安静”，但关键线索全在里面：
- 启动时若看到
+monitor行，说明成功加载了sentinel monitor配置；没这行大概率配置路径错或语法错误 - 定期出现
+sdown sentinel ...表示该哨兵被其它节点判定主观下线；连续出现则说明它响应延迟或丢包 - 反复报
Connection refused或Connection timeout到其它哨兵地址，优先排查 DNS 解析、IP 写错、端口不一致（比如一个配了 26379，另一个误写成 26380） - 日志里出现大量
Failed to resolve hostname，说明配置中用了 hostname 但未在所有节点的/etc/hosts中统一定义
最容易被忽略的一点：哨兵之间通信依赖的是彼此主动发起的连接，不是“中心化注册”。哪怕只有一个哨兵的 sentinel monitor 配置里漏写了其它哨兵的地址，它就永远看不到那个节点——这种不对称性不会报错，只会让 SENTINEL SENTINELS 返回结果变少，投票数凑不齐 quorum。
