关键不是看单个服务“有没有在跑”，而是判断它是否真正参与集群协作、资源是否健康、角色是否稳定；不同集群类型监控重点不同，但底层逻辑一致：节点存活≠集群健康。
监控高可用集群节点的运行状态，关键不是看单个服务“有没有在跑”，而是判断它是否真正参与集群协作、资源是否健康、角色是否稳定。不同集群类型（如 MySQL MGR、RabbitMQ、ZooKeeper、Redis、Oracle RAC）监控重点不同，但底层逻辑一致：节点存活 ≠ 集群健康。
确认节点在线与集群角色归属
节点进程存在，不代表它已被集群接纳或承担正确角色。必须通过集群自身协议层验证其逻辑身份：
- MySQL Group Replication：执行
SELECT * FROM performance_schema.replication_group_members;，检查 MEMBER_STATE=ONLINE 且 MEMBER_ROLE 符合预期（PRIMARY/SECONDARY）；出现 RECOVERING、OFFLINE 或 ERROR 状态需立即查错日志 - RabbitMQ：运行
rabbitmqctl cluster_status，确认节点出现在 nodes 列表中，且 running_nodes 包含该节点；若缺失或状态异常，说明未成功加入或已失联 - ZooKeeper：用
echo stat | nc localhost 2181，查看输出中 Mode: leader/follower/standalone 是否明确，以及 Connections 数值是否合理 - Redis Cluster：执行
redis-cli -c -p 6379 cluster nodes，确认每个节点 flag 字段含master或slave，且无fail?或noaddr标记
验证数据同步与服务可达性
节点在线只是起点，能否提供一致、低延迟的服务才是核心：
- MySQL：检查
SHOW REPLICA STATUS\G中 Replica_IO_Running 和 Replica_SQL_Running 均为 Yes，Seconds_Behind_Master ≈ 0；同时查performance_schema.replication_connection_status确保 group_replication_applier 通道 SERVICE_STATE=ON - RabbitMQ：用客户端连接测试（如 NestJS 的
amqp.connect()），仅连通不足够，还需尝试声明一个临时 exchange 或 queue 并确认成功，避免“端口开着但服务卡死”假象 - Redis：除
cluster nodes外，对主节点执行redis-cli -p 6379 info replication，关注 connected_slaves 数量及 master_repl_offset 与从节点 offset 是否接近 - ZooKeeper：发送
ruok四字命令，返回 imok 才代表服务就绪；srvr可进一步查看处理延迟和请求队列长度
跟踪资源使用与关键指标阈值
CPU、内存、磁盘、连接数等资源瓶颈会悄无声息拖垮集群，需设定明确阈值并持续采集：
- 通用项：监控 内存使用率（尤其 JVM 进程堆内存）、磁盘剩余空间（ZK 日志、MySQL binlog、RabbitMQ 消息存储目录）、文件描述符使用量
- MySQL：关注 Threads_connected（接近 max_connections 警告）、Buffer pool hit rate（低于 99% 提示缓存压力）、Aborted_connects 突增（认证或网络问题）
- RabbitMQ：紧盯 memory_used 和 disk_free，一旦触发
alarm（如内存超 0.8 或磁盘剩 - Oracle RAC：检查 ora_pmon 进程是否存在、lsnrctl status 监听是否就绪、pcs status 显示所有资源 online
建立自动化监控与分级告警
人工巡检无法应对现代集群规模，必须依赖工具链实现闭环：
- 轻量级：用 shell 脚本 + cron 定时执行关键命令（如
cluster_status、stat），失败时调用mailx或钉钉机器人推送 - 标准化：部署 Zabbix 或 Prometheus + mysqld_exporter / rabbitmq-exporter / redis_exporter，采集集群原生指标（如
mysql_group_replication_member_state、rabbitmq_queue_messages_ready） - 可视化：用 Grafana 构建统一仪表盘，区分集群层（节点数、主节点数）、节点层（CPU、内存）、服务层（同步延迟、消息积压）三类视图
- 告警分级：设置不同级别阈值——例如 节点离线 为 P0 立即电话告警；同步延迟 > 60s 为 P1 邮件+企业微信；磁盘使用率 > 90% 为 P2 钉钉提醒
