第1章监控告警概述

一、监控告警概述：从“设备坏了才知道”到“还没坏就预警”

大家好，我是老赵。做运维这行十几年了，今天咱们聊聊监控告警。

说实话，我刚入行那会儿，监控基本靠“吼”。设备宕机了，用户打电话过来骂，我们才知道出事了。那时候的运维，说白了就是“救火队员”。

但现在不一样了。设备监控，就是给我们的服务器、网络设备、数据库这些“哑巴”装上传感器，让它们能主动“说话”。

设备监控的核心价值：从被动响应，变成主动预防。

1.1 什么是设备监控？

设备监控，就是用软件手段，持续采集设备的运行状态数据。比如CPU用了多少、内存还剩多少、磁盘是不是快满了、网络延迟高不高。

我习惯把监控系统比作“医院的体检中心”。设备就是病人，监控指标就是各种体检数据。没有监控，你就像闭着眼睛开车——危险得很。

常见的监控对象包括：

服务器：CPU、内存、磁盘、进程、端口
网络设备：交换机、路由器、防火墙的流量、丢包率
数据库：连接数、慢查询、主从延迟
中间件：Redis命中率、Kafka积压量、Nginx连接数
业务应用：API响应时间、错误率、用户登录成功率

你想想看，如果一台数据库服务器的磁盘使用率已经达到95%，而你完全不知道——那离“写入失败、服务崩溃”就不远了。

1.2 为什么需要告警规则？

光有监控数据还不够。数据是死的，你得告诉系统：什么情况算“异常”？

告警规则，就是给监控数据设定“红线”。

举个例子：

CPU使用率超过90%，算不算异常？
如果只持续了10秒呢？
如果持续了30分钟呢？

没有规则，监控系统只会傻傻地记录数据。有了规则，它才能在你睡觉的时候帮你盯着，出事了立刻喊你。

我的经验：告警规则不是越多越好。我曾经接手过一个项目，告警规则配了800多条，结果每天告警上万条，运维团队直接“告警疲劳”，最后连真正的故障都忽略了。

1.3 告警规则的核心三要素

不管多复杂的告警规则，拆开来看，核心就三个东西：指标、阈值、持续时间。

要素	说明	举例
指标	你要监控什么？	CPU使用率、磁盘IO、HTTP 5xx错误数
阈值	超过多少算异常？	大于90%、小于10GB、大于100次/分钟
持续时间	异常持续多久才触发告警？	持续5分钟、连续3次采样

1.3.1 指标：选对“体检项目”

指标选错了，后面全白搭。

我记得有一次，一个团队监控MySQL，只看了CPU和内存，结果数据库挂了。为什么？因为真正的瓶颈是磁盘IO，他们根本没监控。

选指标有个原则：从业务往下倒推。

业务卡了？→ 看API响应时间
API慢了？→ 看数据库查询时间
数据库慢了？→ 看慢查询、锁等待、磁盘IO

一层层剥下去，才能找到根因。

1.3.2 阈值：红线划在哪？

阈值设得太低，天天告警，狼来了；设得太高，真出事了没反应。

我个人的习惯是：先宽松，再收紧。

比如一个新业务上线，我先设一个比较宽的阈值（比如CPU 95%持续30分钟才告警）。跑两周，看看正常波动范围是多少，然后再把阈值调到合理位置。

避坑指南：我曾经直接把阈值设为“CPU > 80%”就告警，结果业务高峰期每天告警2000多次，运维团队直接屏蔽了告警。后来真的宕机了，没人知道。阈值一定要结合业务周期来调。

1.3.3 持续时间：别被“毛刺”骗了

这是新手最容易忽略的点。

系统指标经常会有瞬间的“毛刺”。比如CPU突然飙到100%，但1秒后就掉下来了。这种瞬间波动，通常不需要告警。

为什么？因为可能是GC（垃圾回收）、定时任务、或者网络抖动。你为这个发告警，就是浪费精力。

所以，持续时间这个参数，就是用来过滤“假警报”的。

CPU > 90% 持续 5 分钟 → 告警
磁盘使用率 > 85% 持续 30 分钟 → 告警
HTTP 5xx > 1% 持续 3 分钟 → 告警

嗯，这里要注意：持续时间不是越长越好。如果是一个关键业务，比如支付接口，错误率持续30秒可能就已经损失惨重了。所以，持续时间要根据业务重要性来定。

1.4 三要素如何配合？一张图看懂

下面这张图，是我自己总结的告警规则决策流程。每次配置新规则，我都会走一遍这个逻辑。

1.5 一个完整的告警规则示例

光说不练假把式。咱们看一个真实场景：

场景：监控一台Web服务器的CPU使用率。

# Prometheus告警规则示例
groups:
  - name: server_alerts
    rules:
      - alert: HighCpuUsage
        expr: cpu_usage_percent > 90
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "服务器CPU使用率过高"
          description: "{{ $labels.instance }} CPU使用率已超过90%，持续5分钟"

这段规则什么意思？

expr：指标是 cpu_usage_percent，阈值是 > 90
for：持续时间是 5 分钟
severity：严重级别是 warning（警告）

你看，三要素全在里面了。

我的建议：刚开始配规则，别追求“一步到位”。先配3-5条核心规则跑起来，观察一周，再逐步补充。我见过太多人第一天就配了50条规则，结果第二天全删了——因为全是噪音。

1.6 小结

这一章咱们聊了：

设备监控是什么——给设备装“传感器”
为什么需要告警规则——把数据变成 actionable 的信息
核心三要素：指标、阈值、持续时间——缺一不可

说白了，告警规则就是你和系统之间的“契约”。你告诉系统：什么情况该喊我，什么情况别烦我。这个契约定得好，你就能睡个安稳觉；定得不好，要么被吵死，要么被坑死。

下一章，咱们聊聊告警规则的具体配置方法，包括怎么选指标、怎么定阈值、怎么设持续时间。到时候我会拿几个真实案例出来拆解。

公众号：蓝海资料掘金营，微信 deep3321

📚 课程目录

一、监控告警概述：从“设备坏了才知道”到“还没坏就预警”

1.1 什么是设备监控？

1.2 为什么需要告警规则？

1.3 告警规则的核心三要素

1.3.1 指标：选对“体检项目”

1.3.2 阈值：红线划在哪？

1.3.3 持续时间：别被“毛刺”骗了

1.4 三要素如何配合？一张图看懂

1.5 一个完整的告警规则示例

1.6 小结