墨与星辰

主题

告警机制 ​

告警机制是运维工作的核心功能，通过及时通知系统异常，帮助运维人员快速响应和处理问题，保障系统稳定运行。

📋 告警体系架构 ​

🎯 告警规则设计 ​

1. 告警规则分类 ​

系统级告警：

  • CPU使用率：CPU使用率过高
  • 内存使用率：内存使用率过高
  • 磁盘使用率：磁盘空间不足
  • 网络异常：网络流量异常

应用级告警：

  • 服务可用性：服务不可用
  • 响应时间：接口响应时间过长
  • 错误率：接口错误率过高
  • 请求量：请求量异常

业务级告警：

  • 业务指标：业务指标异常
  • 订单量：订单量异常
  • 支付成功率：支付成功率下降
  • 用户活跃度：用户活跃度异常

2. Prometheus 告警规则 ​

告警规则配置示例：

yaml
# alert_rules.yml
groups:
  - name: system_alerts
    interval: 30s
    rules:
      # CPU使用率告警
      - alert: HighCPUUsage
        expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        labels:
          severity: warning
          team: infrastructure
        annotations:
          summary: "CPU使用率过高"
          description: "CPU使用率持续5分钟超过85%，当前值：{{ $value }}%"
          runbook_url: "https://wiki.example.com/runbook/high-cpu"
      
      # 内存使用率告警
      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
        for: 5m
        labels:
          severity: critical
          team: infrastructure
        annotations:
          summary: "内存使用率过高"
          description: "内存使用率持续5分钟超过90%，当前值：{{ $value }}%"
          runbook_url: "https://wiki.example.com/runbook/high-memory"
      
      # 磁盘使用率告警
      - alert: HighDiskUsage
        expr: (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 > 85
        for: 10m
        labels:
          severity: warning
          team: infrastructure
        annotations:
          summary: "磁盘使用率过高"
          description: "磁盘使用率持续10分钟超过85%，当前值：{{ $value }}%"
          runbook_url: "https://wiki.example.com/runbook/high-disk"
  
  - name: application_alerts
    interval: 30s
    rules:
      # 服务不可用告警
      - alert: ServiceDown
        expr: up{job="app-service"} == 0
        for: 1m
        labels:
          severity: critical
          team: backend
        annotations:
          summary: "服务不可用"
          description: "服务 {{ $labels.instance }} 不可用超过1分钟"
          runbook_url: "https://wiki.example.com/runbook/service-down"
      
      # 接口错误率告警
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100 > 5
        for: 2m
        labels:
          severity: warning
          team: backend
        annotations:
          summary: "接口错误率过高"
          description: "接口错误率持续2分钟超过5%，当前值：{{ $value }}%"
          runbook_url: "https://wiki.example.com/runbook/high-error-rate"
      
      # 接口响应时间告警
      - alert: SlowAPI
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
        for: 5m
        labels:
          severity: warning
          team: backend
        annotations:
          summary: "接口响应时间过长"
          description: "95%接口响应时间持续5分钟超过1秒，当前值：{{ $value }}秒"
          runbook_url: "https://wiki.example.com/runbook/slow-api"

3. 告警规则最佳实践 ​

规则设计原则：

  • 明确阈值：设置明确的告警阈值
  • 合理持续时长：避免短时间波动触发告警
  • 分级告警：根据严重程度分级（warning、critical）
  • 告警收敛：避免告警风暴

告警级别：

级别严重程度响应时间通知方式
Critical严重立即电话+短信+钉钉
Warning警告15分钟内钉钉+邮件
Info信息1小时内邮件

🎯 AlertManager 配置 ​

1. AlertManager 架构 ​

架构图：

2. AlertManager 配置 ​

alertmanager.yml 配置示例：

yaml
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alerts@example.com'
  smtp_auth_username: 'alerts@example.com'
  smtp_auth_password: 'password'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 12h
  receiver: 'default'
  routes:
    # 严重告警路由
    - match:
        severity: critical
      receiver: 'critical-alerts'
      continue: true
    
    # 基础设施告警路由
    - match:
        team: infrastructure
      receiver: 'infrastructure-team'
    
    # 后端服务告警路由
    - match:
        team: backend
      receiver: 'backend-team'

receivers:
  - name: 'default'
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true
  
  - name: 'critical-alerts'
    email_configs:
      - to: 'ops-oncall@example.com'
        send_resolved: true
    webhook_configs:
      - url: 'http://dingtalk-webhook/api/alert'
        send_resolved: true
    # 短信通知（需要集成短信服务）
    # sms_configs:
    #   - to: '+8613800138000'
    #     send_resolved: true
  
  - name: 'infrastructure-team'
    email_configs:
      - to: 'infra-team@example.com'
        send_resolved: true
    webhook_configs:
      - url: 'http://dingtalk-webhook/api/alert?team=infrastructure'
        send_resolved: true
  
  - name: 'backend-team'
    email_configs:
      - to: 'backend-team@example.com'
        send_resolved: true
    webhook_configs:
      - url: 'http://dingtalk-webhook/api/alert?team=backend'
        send_resolved: true

🎯 告警降噪 ​

1. 告警聚合 ​

聚合策略：

  • 按告警名称聚合：相同告警合并
  • 按服务聚合：同一服务的告警合并
  • 按时间窗口聚合：时间窗口内的告警合并

聚合示例：

yaml
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 10s        # 等待10秒聚合告警
  group_interval: 10s    # 同一分组内的告警间隔10秒
  repeat_interval: 12h   # 重复告警间隔12小时

2. 告警抑制 ​

抑制规则：

yaml
inhibit_rules:
  # 如果服务不可用，抑制其他告警
  - source_match:
      alertname: 'ServiceDown'
    target_match:
      alertname: 'HighErrorRate'
    equal: ['instance', 'service']
  
  # 如果系统宕机，抑制所有告警
  - source_match:
      alertname: 'SystemDown'
    target_match_re:
      alertname: '.*'

3. 告警静默 ​

静默规则：

  • 维护窗口：维护期间静默告警
  • 已知问题：已知问题的告警静默
  • 测试环境：测试环境告警静默

🎯 通知渠道 ​

1. 邮件通知 ​

邮件配置：

yaml
email_configs:
  - to: 'ops@example.com'
    headers:
      Subject: '{{ .GroupLabels.alertname }}'
    html: |
      <h2>告警信息</h2>
      <p><strong>告警名称：</strong>{{ .GroupLabels.alertname }}</p>
      <p><strong>严重程度：</strong>{{ .CommonLabels.severity }}</p>
      <p><strong>告警时间：</strong>{{ .StartsAt }}</p>
      <p><strong>告警详情：</strong>{{ .CommonAnnotations.description }}</p>

2. 钉钉/企业微信通知 ​

Webhook配置：

yaml
webhook_configs:
  - url: 'http://dingtalk-webhook/api/alert'
    http_config:
      bearer_token: 'your-token'
    send_resolved: true

钉钉消息格式：

json
{
  "msgtype": "markdown",
  "markdown": {
    "title": "告警通知",
    "text": "## 告警信息\n\n**告警名称**：{{ .GroupLabels.alertname }}\n\n**严重程度**：{{ .CommonLabels.severity }}\n\n**告警时间**：{{ .StartsAt }}\n\n**告警详情**：{{ .CommonAnnotations.description }}"
  }
}

3. 短信/电话通知 ​

紧急告警通知：

  • 电话通知：Critical级别告警电话通知
  • 短信通知：Critical级别告警短信通知
  • 轮询机制：无人接听时轮询下一个联系人

🎯 告警升级 ​

1. 升级规则 ​

升级策略：

升级配置：

yaml
route:
  routes:
    - receiver: 'oncall-primary'
      group_wait: 10s
      group_interval: 10s
      repeat_interval: 15m
      continue: true
    - receiver: 'oncall-secondary'
      match:
        repeat_interval: '>15m'
      group_wait: 0s
      repeat_interval: 30m
      continue: true
    - receiver: 'escalation'
      match:
        repeat_interval: '>30m'

2. 值班轮换 ​

值班配置：

  • On-Call轮换：按周或按月轮换
  • 告警分发：按值班表分发告警
  • 值班日历：值班日历管理

📋 告警最佳实践 ​

1. 告警规则设计 ​

设计原则：

  • 避免告警疲劳：合理设置告警阈值
  • 明确告警含义：告警消息清晰明确
  • 提供处理建议：告警包含处理建议
  • 告警收敛：避免重复告警

2. 告警分级 ​

分级标准：

  • Critical：影响业务，需要立即处理
  • Warning：可能影响业务，需要关注
  • Info：信息类告警，记录即可

3. 告警处理流程 ​

处理流程：

  1. 告警接收：接收告警通知
  2. 问题确认：确认问题是否真实
  3. 问题处理：处理问题
  4. 告警恢复：问题解决后恢复告警
  5. 复盘总结：复盘告警处理过程

📖 学习资源 ​

视频教程 ​

书籍推荐 ​

  • 《Prometheus监控实战》 - Prometheus和AlertManager使用指南
  • 《SRE：Google运维解密》 - Google告警机制实践
  • 《监控的艺术》 - 监控和告警设计最佳实践
  • 《告警系统设计》 - 告警系统设计方法论

网站资源 ​

工具推荐 ​

  • 告警管理：AlertManager、PagerDuty、OpsGenie
  • 通知渠道：邮件、短信、钉钉、企业微信、Slack
  • 告警分析：Grafana、Kibana

✅ 告警机制检查清单 ​

  • [ ] 告警规则已设计
  • [ ] 告警阈值已设置
  • [ ] 告警级别已定义
  • [ ] 通知渠道已配置
  • [ ] 告警降噪已实施
  • [ ] 告警升级已配置
  • [ ] 值班轮换已建立
  • [ ] 告警处理流程已制定

上一章节：日志监控
返回目录：运维与监控概览 | 工程架构能力