高可用性监控怎么搞

高可用性（HA）监控的核心目标是：在系统出现故障时能及时发现、快速定位、自动或人工介入恢复，保障业务“基本可用”。下面按“监控对象 → 监控方式 → 告警与处置 → 架构实践”给你一套可落地的思路。

一、先明确：要监控什么（监控对象）

1. 基础设施层

• 服务器：CPU、内存、磁盘、IO、负载
• 网络：丢包、延迟、带宽、端口连通性
• 中间件：
  • 数据库（主从延迟、连接数、慢查询）
  • 缓存（Redis 命中率、内存碎片）
  • 消息队列（堆积、消费延迟）

2. 应用服务层

• 进程是否存活
• 接口可用性（HTTP 状态码）
• 响应时延（P95 / P99）
• 错误率（5xx、业务异常）
• 健康检查接口（/health）

3. 业务层（最关键）

• 核心交易/请求量是否异常
• 关键链路是否中断
• 用户体验指标（如登录成功率）

4. 高可用机制本身

• 主备切换是否成功
• 集群节点状态
• 脑裂风险
• 容灾演练是否通过

二、监控方式怎么选

1. 主动探测（黑盒监控）

• 定时请求关键接口
• 模拟用户行为
• 工具：Prometheus + Blackbox Exporter、Zabbix、云监控

2. 指标采集（白盒监控）

• 暴露 metrics 接口
• 工具：
  • Prometheus + Grafana
  • VictoriaMetrics
  • Datadog / 云厂商 APM

3. 日志监控

• 错误日志、异常堆栈
• 工具：ELK / Loki / ClickHouse

4. 链路追踪（复杂系统必备）

• 定位跨服务故障
• 工具：SkyWalking、Jaeger、OTel

三、告警：不是“越多越好”，而是“有用”

告警原则

• 可行动：收到告警知道该干嘛
• 不重复：合并同类告警
• 分级：
  • P0：业务中断（电话）
  • P1：严重影响（IM + 电话）
  • P2：潜在风险（IM）

典型告警示例

• 主节点宕机
• 主从延迟 > 30s
• 接口错误率 > 1%
• P99 延迟突增 3 倍
• 健康接口连续失败

四、高可用监控的“进阶做法”

1. 多活 / 主备监控

• 定期检查备用节点是否“真能用”
• 自动探活 + 手动演练结合

2. 混沌工程

• 随机杀节点、断网络
• 验证监控和切换是否生效

3. 监控自身高可用

• 监控系统不能单点
• 告警通道至少两条（如企微 + 电话）

4. SLO + 错误预算

• 用 SLO 衡量“可用性”
• 错误预算用完 → 停止发版

五、一个典型 HA 监控架构

业务系统
   ↓ metrics / logs / trace
Prometheus / Loki / OTel
   ↓
Grafana（看板）
   ↓ 告警规则
Alertmanager
   ↓
企微 / 钉钉 / 电话

六、如果你现在要从 0 开始

建议顺序：

1. 先监控“进程 + 接口 + 错误率”
2. 再做主备和健康检查
3. 最后上链路追踪和 SLO

如果你愿意，我可以：

• 按你用的技术栈（K8s / 物理机 / 云）给具体方案
• 帮你写 Prometheus 告警规则
• 给你一个 HA 监控 checklist