一、告警基础概念

1.1 什么是告警

告警是什么？简单说，就是系统发出的求救信号。

每次系统出问题，不可能靠人盯着屏幕。我就吃过这个亏。早期我管理一个电商平台，凌晨两点数据库连接池爆了，用户下单全失败。没人知道。直到早上客服电话被打爆，我才发现系统已经挂了四个小时。

那次之后我明白了一个道理：告警是运维的眼睛。它替我们盯着成千上万的指标，一旦异常就喊一声。

从技术层面看，告警就是一条有上下文的消息。它说清楚了三件事：

• 什么事发生了：比如CPU使用率超过90%
• 在哪发生的：哪个服务器、哪个服务、哪个接口
• 严重到什么程度：是警告、还是需要立即处理的致命问题

我常跟团队说，告警不是噪声，是信号。关键是怎么定义规则，把信号从噪声里捞出来。

1.2 告警与日志的区别

很多新人分不清告警和日志。其实差别很大。

日志是流水账。它记录了系统里发生的每一件事。比如用户A在10:05分登录、数据库查询耗时200ms、内存使用量增长了5MB。这些都是日志。它像机场的黑匣子，出事之后用来查原因。

告警是判官。它不看所有事，只看哪些事不对劲。比如数据库查询耗时突然从200ms涨到5秒，这就是不对劲。告警系统会立刻通知你。

我在项目中遇到过这样的情况：某次线上事故，日志文件每秒写入上万条，但告警一条都没触发。为什么？因为规则写错了。日志在拼命说“我出事了”，但告警规则没有识别出来。最后花了三个小时从海量日志里手动定位问题。

我用一个表来说明它们的关系：

对比项	日志	告警
核心用途	记录、审计、排查	发现问题、触发响应
数据量	巨大，全量记录	精简，仅异常事件
时效性	事后查看	实时或准实时
关注点	发生了什么	哪些需要处理
格式	原始文本或结构化	规则匹配后的结构化消息
消费对象	工程师手动分析	自动通知、自动响应

说白了，日志是原料，告警是成品。没有日志，告警很难准。但只有日志没有告警，你就得在数据海洋里捞针。两者缺一不可。

1.3 告警的重要性

我见过太多公司，开发阶段不重视告警，上线后全靠人工巡检。结果呢？系统崩了没人知道，用户投诉了才去查。这不是运维，是救火。

告警的重要性体现在几个层面：

• 缩短故障发现时间：理想情况是1分钟内发现异常，而不是等用户来骂。
• 精准定位根因：好的告警会告诉你问题出在哪个服务、哪段代码，而不是笼统地报“系统异常”。
• 减少人工干预：自动化告警+自愈脚本，很多问题不用人动手。

举个例子。以前我维护的一个支付系统，磁盘写满告警设在了95%。有一次凌晨磁盘涨到94%，按规则没触发。结果到了凌晨三点，磁盘满了，支付服务全挂。你说亏不亏？后来我把阈值改到80%警告、90%严重，提前两个小时预警。从那以后再也没有因为磁盘挂过服务。

这个经验告诉我：告警阈值不是拍脑袋定的，是跟业务跑出来的。

1.4 告警的现实意义

告警不只是技术问题。它直接影响业务。

一个电商网站，支付接口挂了10分钟，损失可能在几十万。一个在线教育平台，直播推流中断30秒，影响几千人在线听课。一个医疗系统，病历查询超时，医生和患者都在等。

告警系统就像是这些业务的守护者。它没钱没权，但它能从根源上减少损失。

我总结告警的现实意义有几点：

1. 保障SLA：99.9%的可用性不是靠运气，是告警和自动恢复撑起来的。
2. 降低运维成本：一个告警系统可以替代好几个夜班运维。
3. 提升团队效率：不用每个人盯着监控屏，有异常自动推送到群里。
4. 业务连续性：关键业务异常时，告警能触发熔断、降级、切换，保证核心链路不断。

你可能会问：那告警是不是越多越好？恰恰相反。我经历过一个项目，告警规则设了上千条，每天推送几千条消息。结果呢？没人看。全是垃圾告警。真正有价值的信息被淹没了。这就是著名的“告警疲劳”。

1.5 告警的完整流程

看一张图，帮助你理解告警从哪里来，到哪里去。

你看，告警不是一步到位。数据先要采集，再算指标，然后拿规则去碰。碰上了，还要判断严重程度，决定发给谁，最后才发出去。收到告警的人，要么自己修，要么脚本自动修。

这个流程里，规则设计是最关键的一环。阈值设高了漏报，设低了误报。我在后面的课程会专门教你怎样平衡这两个问题。

1.6 本章要点