服务异常如何监控告警

本文目录导读：

1. 监控什么：四大核心维度
2. 架构工具选型：流行的技术栈
3. 告警规则设计：如何定义“异常”？
4. 告警通知体系：如何有效通知？
5. 实战：搭建Prometheus + Alertmanager + Grafana告警（示例）
6. 最佳实践与避坑指南
7. 总结流程图

服务异常监控告警是保障系统稳定性的核心环节，一个成熟的监控告警体系通常遵循“数据采集 -> 指标聚合 -> 阈值判定 -> 告警通知 -> 处理与复盘”的闭环。

以下是构建服务异常监控告警体系的完整指南，涵盖了从“监控什么”到“如何告警”的各个方面。

监控什么：四大核心维度

不能只盯着CPU,需要覆盖以下全部维度：

1. 基础设施层

   • 硬件资源： CPU使用率、内存使用率、磁盘I/O（输入输出）、网络带宽/延迟/丢包率。
   • 服务器状态： 是否宕机、进程是否存活。
   • 关键指标： 磁盘空间（磁盘写满是最常见的故障之一）。

2. 应用与中间件层

   • 数据库： MySQL慢查询数、连接数、主从延迟、死锁数；Redis 命中率、内存使用、OOM（Out of Memory，内存溢出）风险。
   • 消息队列： Kafka/RabbitMQ 积压量、消费延迟、连接数。
   • Web服务器： Nginx 5xx/4xx错误率、并发连接数。

3. 业务指标层 （最重要但最容易被忽略）

   • 核心业务量： 每分钟/小时的下单量、支付成功率、用户登录数、API调用量，业务量突然降为零或暴跌,比CPU爆满更可怕。
   • 业务响应： 核心接口的P99/P95/P50延迟,延迟飙升往往意味着服务有问题。
   • 业务异常： 下单失败率、支付回调超时率。

4. 日志与链路层 （用于定位问题根因）

   • 错误日志： Error/Exception 的数量、关键堆栈信息。
   • 链路追踪： 跨服务调用链的请求延迟、依赖服务错误。

架构工具选型：流行的技术栈

推荐黄金组合（开源）： Prometheus + Grafana + Alertmanager 推荐云原生组合： CNCF Certified（如K8s） + Prometheus Operator + Grafana

告警规则设计：如何定义“异常”？

阈值类规则（最基础）

• 静态阈值： CPU > 90%,持续5分钟。
• 动态阈值： 基于历史数据的基线检测（请求量突然低于过去7天同时间的50%，触发告警）。
• 无数据告警： 当系统完全不报送数据时，直接报警（服务可能挂了）。

多条件智能聚合

• 多指标交叉： 错误率上升 且 延迟上升 且 CPU下降（可能是死锁导致）。
• 持续时间： 抖动1秒不告警,持续5分钟才告警。

事件/日志模式匹配

• 关键词告警： 日志中出现 OutOfMemoryError、Connection refused、Login Failed Count > 10/min。

告警通知体系：如何有效通知？

分级告警（避免告警风暴）

• P0（致命）： 服务大面积不可用、核心业务中断、数据丢失。
  • 方式： 短信 + 电话 → 立即唤醒值班人员。
• P1（严重）： 单节点宕机、主要功能可用但性能下降、错误率 > 5%。
  • 方式： 电话或关键IM群 @所有人。
• P2（警告）： 磁盘使用率 > 80%、延迟轻微上升、非核心服务异常。
  • 方式： 工作群通知,工作时间处理。
• P3（提示）： CPU偶尔抖动、部分不关键日志报错。
  • 方式： 邮件或看板记录,归档。

通知渠道

• 即时消息： 钉钉/飞书/企业微信机器人（最常用）。
• 短信/电话： 用于P0/P1,24小时待命。
• 与值班系统联动： 自动匹配排班表，如 PagerDuty、Opsgenie 或自研轮值系统，告警自动通知当班者,未确认则升级。

实战：搭建Prometheus + Alertmanager + Grafana告警（示例）

假设你已部署了Prometheus和Grafana。

Step 1: 配置告警规则（rules.yml） 在Prometheus配置文件中定义：

groups:
  - name: example-service-alerts
    rules:
      # 告警1: 服务宕机
      - alert: ServiceDown
        expr: up{job="my-web-app"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} 服务已停止运行"
      # 告警2: 高错误率
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.job }} 错误率超过5%"
      # 告警3: 磁盘空间不足
      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 15
        for: 5m
        labels:
          severity: warning
        annotations:
          description: "服务器 {{ $labels.instance }} 磁盘可用空间剩余 {{ $value | humanizePercent }}"

Step 2: 配置 Alertmanager（alertmanager.yml）

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h  # 重要：避免重复轰炸，4小时重复一次同一告警
  # 根据严重程度分配不同通道
  routes:
  - match:
      severity: critical
    receiver: p0-p1-team  # 紧急通道
    repeat_interval: 10m   # 紧急告警频繁一点
  - match:
      severity: warning
    receiver: team-chat  # 普通群聊
receivers:
- name: p0-p1-team
  webhook_configs:
  - url: 'http://your-internal-pager-system/webhook'
  # 也可以配置短信、电话网关
- name: team-chat
  webhook_configs:
  - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'

Step 3: 在Grafana中可视化 将Prometheus作为数据源，创建仪表盘,将告警配置为面板报警。

最佳实践与避坑指南

1. 避免告警风暴：
   • 实施聚合：避免多个单节点同时报一样的错。
   • 实施静默/抑制：如果核心服务挂了，所有依赖它的微服务都会报错,此时只保留根因告警。
2. 一切告警都要可追溯： 告警信息必须包含告警时间、IP、实例、当前值、对比值、触发规则、相关日志链接（Grafana Explore或Kibana链接）。
3. 告警必须可执行： 告警描述应该告诉接收者 出了什么问题 以及 去哪里看，最好包含一份简单的处理文档链接。
4. 持续调整阈值： 告警规则不是一次性的，随着业务增长、系统重构，需要不断调整阈值，如果某个P2告警从来没人关注,就降级或删除它。
5. 自动化处理： 对于已知的、可预测的故障（如磁盘满、进程挂），考虑写脚本实现自愈（自动清理日志、自动重启进程）,仅在自动修复失败时告警。

总结流程图

[用户请求] --> [负载均衡] --> [服务A]  --> [数据库]
                              |
                          [日志采集]            [指标采集]
                              |                     |
                          [Elasticsearch]      [Prometheus]
                              |                     |
                          [Kibana/日志告警]    [Alertmanager]
                              \                   /
                               \                 /
                              [Grafana告警规则]
                                    |
                              [分级路由引擎]
                                    |
                        /-------------------\
                       |    P0: 电话报警    |
                       |    P1: 钉钉@全员   |
                       |    P2: 工作群       |
                       |    P3: 归档邮件    |
                        \-------------------/
                                    |
                              [值班人员确认/解决]
                                    |
                              [告警关闭 + 复盘]

通过以上体系，你可以从 “被动救火” 转变为 “主动发现、快速定位、智能处理” 的高效运维模式。