系统监控与告警最佳实践

一、前言

有效的监控和告警体系是保障系统稳定运行的关键。本文档介绍监控系统设计原则、常用指标、告警策略及最佳实践，帮助构建可靠的运维监控体系。

二、监控体系设计原则

2.1 黄金指标（Golden Signals）

Google SRE 提出的四个关键指标：

  1. 延迟（Latency） - 请求处理时间
  2. 流量（Traffic） - 系统负载情况
  3. 错误（Errors） - 失败请求比例
  4. 饱和度（Saturation） - 资源使用程度

2.2 监控层级

1
2
3
4
5
6
7
8
9
┌─────────────────────────┐
│      业务层监控         │  ← 业务指标、转化率
├─────────────────────────┤
│      应用层监控         │  ← 服务状态、API 响应
├─────────────────────────┤
│      系统层监控         │  ← CPU、内存、磁盘
├─────────────────────────┤
│      基础设施监控       │  ← 网络、电源、硬件
└─────────────────────────┘

三、核心监控指标

3.1 系统资源指标

指标 阈值建议 说明
CPU 使用率 >80% 告警 持续 5 分钟以上
内存使用率 >85% 告警 考虑 swap 使用
磁盘使用率 >80% 警告，>90% 严重 分区级别监控
磁盘 inode >80% 告警 小文件场景重要
系统负载 >CPU 核心数×2 1/5/15 分钟负载

3.2 网络指标

指标 阈值建议 说明
网络带宽 >80% 告警 入站/出站分别监控
TCP 连接数 异常增长告警 关注 TIME_WAIT
网络错误率 >0.1% 告警 丢包、重传
DNS 解析时间 >100ms 告警 解析延迟

3.3 应用指标

指标 阈值建议 说明
HTTP 错误率 >1% 告警 5xx 错误比例
响应时间 P99 >2s 告警 根据业务调整
请求 QPS 异常波动告警 同比/环比分析
服务可用性 <99.9% 告警 按分钟计算

四、告警策略设计

4.1 告警分级

P0 - 严重（Critical）

  • 核心服务不可用
  • 数据丢失风险
  • 安全事件
  • 响应时间：立即（5 分钟内）

P1 - 高（High）

  • 服务性能严重下降
  • 资源即将耗尽
  • 部分功能不可用
  • 响应时间：15 分钟内

P2 - 中（Medium）

  • 非核心服务异常
  • 资源使用偏高
  • 响应时间：1 小时内

P3 - 低（Low）

  • 信息性通知
  • 趋势预警
  • 响应时间：工作日处理

4.2 告警规则设计原则

  1. 避免告警疲劳

    • 只告警需要人工介入的问题
    • 设置合理的阈值和持续时间
    • 使用告警聚合和抑制

  2. 告警可操作

    • 每条告警应有明确的处理流程
    • 包含足够的上下文信息
    • 指向相关文档或 runbook

  3. 分级通知

    • P0: 电话 + 短信 + IM
    • P1: 短信 + IM
    • P2: IM 通知
    • P3: 邮件/工单

4.3 告警示例配置（Prometheus）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# CPU 使用率告警
- alert: HighCPUUsage
  expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "CPU 使用率过高"
    description: "{{ $labels.instance }} CPU 使用率超过 80%，当前值 {{ $value }}%"

# 磁盘空间告警
- alert: DiskSpaceLow
  expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 10
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "磁盘空间不足"
    description: "{{ $labels.instance }} 磁盘使用率超过 90%，剩余 {{ $value }}%"

# 服务宕机告警
- alert: ServiceDown
  expr: up == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "服务宕机"
    description: "{{ $labels.job }} 服务已宕机"

五、常用监控工具

5.1 开源方案

工具 用途 特点
Prometheus 指标采集 时序数据库，强大查询
Grafana 可视化 丰富图表，多数据源
Zabbix 综合监控 成熟稳定，功能全面
Nagios 服务监控 插件丰富，告警灵活
ELK Stack 日志监控 日志收集分析

5.2 云服务商方案

  • AWS CloudWatch
  • Azure Monitor
  • 阿里云云监控
  • 腾讯云监控

六、监控检查清单

6.1 日常检查

  • 确认所有监控探针正常运行
  • 检查告警通道是否畅通
  • review 昨日告警记录
  • 确认仪表盘数据正常更新

6.2 定期检查

  • 每月 review 告警规则有效性
  • 每季度进行告警演练
  • 更新监控覆盖范围
  • 优化告警阈值

七、故障响应流程

1
2
3
4
5
6
7
告警触发 → 值班人员接收 → 初步评估 → 分级处理
    ↓
P0/P1: 立即响应              P2/P3: 工单处理
    ↓                            ↓
启动应急流程                工作日处理
    ↓                            ↓
问题修复 → 验证 → 复盘          问题修复 → 关闭

八、总结

构建有效的监控告警体系需要：

  1. 明确监控目标 - 知道要监控什么
  2. 选择合适的工具 - 根据场景选型
  3. 设计合理的告警 - 避免告警疲劳
  4. 建立响应流程 - 确保问题及时处理
  5. 持续优化改进 - 定期 review 和调整

监控不是目的，而是手段。最终目标是保障系统稳定、提升用户体验。

文档版本：1.0
最后更新：2026-03-03