怎么配置监控告警规则 日常维护方法与实用案例

监控告警不是摆设，得会配才管用

公司刚上线了一个新服务，头两天还挺稳，第三天凌晨两点突然打不开。运维小李被电话叫醒，连滚带爬查日志，发现数据库连接池早就满了，但没人知道。其实系统早有异常，只是没设置告警规则，等于守着个哑巴监控。

先搞清楚你要监控什么

别一上来就点“添加告警”，先想清楚业务关键点在哪。比如Web服务，核心是接口响应时间、错误率和服务器资源使用情况。数据库重点看连接数、慢查询、主从延迟。不同系统关注点不一样，就像你不会用体温计量血压。

选对监控工具是第一步

常见的像Prometheus + Grafana组合，开源又灵活；云厂商的云监控也够用，适合不想折腾的团队。以Prometheus为例，告警规则写在rules.yml里，通过Alertmanager发通知。

写一条简单的CPU告警规则

比如你想在某台服务器CPU使用率超过80%持续5分钟时收到通知，可以这样写：

groups:
- name: instance_rules
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usage high"
      description: "CPU usage is above 80% (current value: {{ $value }})"

告警级别要分清，别让通知炸了手机

所有告警都标“紧急”，等于没有紧急。建议分两级：warning和critical。比如磁盘用了80%发warning，90%再升为critical。Alertmanager可以按severity路由到不同群组，值班的人不至于半夜被无关消息吵醒。

测试你的告警规则

写完别直接上线，先用Prometheus的Expression Browser验证表达式能不能查出数据。也可以手动触发异常，比如在测试机上跑个死循环占满CPU，看看告警是不是准时推送到了钉钉或企业微信。

加上上下文信息，别光甩个数字

告警通知里只写“CPU高了”没用，得告诉接收人可能影响什么。比如加上“该实例承载订单服务，建议优先检查下单接口”。annotations里的description字段就是干这个的，让人一眼知道问题严重性和初步应对方向。

定期 review 告警规则

系统变，业务变，告警规则也不能一成不变。三个月前设的内存阈值，现在可能已经不适用了。建议每季度拉一次会，看看哪些告警从来没触发，哪些天天响——前者可能该删，后者得优化条件。