高可用性监控怎么做

高可用性（High Availability，HA）监控的目标是：在系统出现异常前或出现异常时，能及时发现、告警并自动/人工恢复，保障业务连续性。下面从整体思路、监控层次、关键指标、告警与自愈、常见架构几方面说明。

一、整体思路

高可用监控不是“装个 Prometheus 就完事”，而是一个闭环：

采集 → 存储 → 分析 → 告警 → 处置 → 复盘

核心原则：

• 监控对象要覆盖业务 + 应用 + 中间件 + 基础设施
• 不只监控“是否存活”，还要监控“是否可用”
• 告警要可行动，避免狼来了
• 关键链路要有自动恢复能力

二、监控层次（自顶向下）

1. 业务层监控（最重要）

关注“用户感知”：

• 核心接口成功率（如支付成功率）
• 业务订单量、转化率波动
• 关键链路 RT（响应时间）
• 业务自定义埋点（如登录失败率）

工具：

• 埋点 + Kafka + 实时计算
• Grafana / 业务大盘

2. 应用层监控

• 进程是否存活
• HTTP / RPC 接口健康
• 线程池、连接池使用率
• GC、OOM、异常日志
• 依赖服务调用失败率

工具：

• Prometheus + Exporter
• SkyWalking / Arthas
• ELK / Loki

3. 中间件监控

常见高可用风险点：

• MySQL：主从延迟、连接数、慢 SQL
• Redis：内存、命中率、主从同步
• Kafka：消费滞后、分区均衡
• Nginx：5xx、连接数

4. 基础设施监控

• 节点存活（ping / node-exporter）
• CPU / 内存 / 磁盘 IO
• 网络丢包、延迟
• 机房 / 可用区级别故障

工具：

• Zabbix / Prometheus Node Exporter
• 云厂商监控

三、高可用关键监控指标（示例）

四、告警与值班机制

1. 告警分级

• P0：业务中断，立即电话
• P1：核心功能受损，15 分钟内响应
• P2：潜在风险，工作时间处理

2. 告警降噪

• 同类告警合并
• 抑制（维护期不告警）
• 根因关联（DB 挂了别只报应用）

3. 值班与 SOP

• 7×24 值班
• 每类故障有 Runbook
• 定期演练（混沌工程）

五、自动恢复（提升 HA 的关键）

常见手段：

• 进程挂了 → 自动拉起（systemd / K8s）
• 节点故障 → 流量摘除（LB / 健康检查）
• 主库挂了 → 自动切换（MHA / Orchestrator）
• 区域故障 → 多活切换

六、典型高可用监控架构

业务埋点
   ↓
Prometheus / VictoriaMetrics
   ↓
Alertmanager
   ↓
电话 / 钉钉 / 企业微信
   ↓
值班 + 自动恢复

K8s 场景：

• Liveness / Readiness Probe
• HPA
• 多副本 + 反亲和

七、常见误区

• 只监控 CPU、内存（不看业务）
• 告警太多没人看
• 没有故障演练
• 单点监控自身挂了

如果你愿意，我可以：

• 给你一套 Prometheus + Grafana 高可用监控模板
• 或针对 微服务 / K8s / 数据库 单独展开
• 或帮你设计 多活容灾监控方案

你现在是哪类系统？