1. 报警阈值概述：什么是报警阈值、为什么需要阈值、阈值设定面临的挑战

大家好，我是老张。做运维监控这些年，我踩过最大的坑，就是报警阈值设得乱七八糟。

今天咱们聊聊这个最基础、但也最容易被忽视的话题——报警阈值到底是什么？为什么非设不可？以及，为什么设个阈值能让人头秃。

1.1 什么是报警阈值

说白了，报警阈值就是一条线。一条告诉你「系统出问题了」的线。

举个例子：你监控一台 Web 服务器的 CPU 使用率。平时它跑在 30% 左右，突然飙到 95%。你肯定想知道发生了什么。那 95% 这个点，就是阈值。

更严谨一点说：报警阈值是衡量指标是否异常的边界值。当指标超过（或低于）这个边界，系统就触发报警。

阈值可以是一维的，比如「内存使用率 > 90%」。也可以是多维组合的，比如「CPU > 80% 且持续 5 分钟且 QPS > 1000」。后者更精准，但也更复杂。

1.2 为什么需要阈值

你可能会想：我不设阈值行不行？把所有数据都记下来，出问题再查？

嗯，理论上可以。但现实是——

• 数据量太大：一个中型系统每天产生几亿条监控数据。人眼根本看不过来。
• 响应太慢：等你去查日志，用户已经骂了三轮了。
• 成本太高：全量存储、全量分析，服务器和人力都扛不住。

阈值的作用，就是帮你从海量数据里「捞」出真正需要关注的那一小撮。

我个人习惯把阈值的作用总结成三点：

作用	说明	我见过的反面案例
信号降噪	过滤掉正常波动，只保留异常信号	某电商把 CPU 阈值设到 50%，结果每天报警 2000 次，运维直接静音了
时效保障	在故障影响扩大前通知到人	某支付系统磁盘阈值设到 99%，等报警时已经写不进去了
资源聚焦	让有限的运维人力盯住最关键的问题	全量报警 = 没有报警，人会被疲劳轰炸到麻木

1.3 阈值设定面临的挑战：误报与漏报

好，现在问题来了。阈值设在哪？

设高了，漏报。系统都崩了，报警没响。设低了，误报。系统好好的，报警响个不停。

这就是阈值设定里最核心的矛盾——误报与漏报的博弈。

1.3.1 误报（False Positive）

误报就是「假警报」。系统正常，但报警了。

我曾经接手过一个项目，每天凌晨 2 点有个定时任务跑批，CPU 会短暂冲到 85%。结果报警系统每天半夜把值班同事叫起来。一周后，值班同事直接把报警静音了。

你看，误报最大的危害不是吵，而是让人「不信」了。狼来了的故事，在运维圈天天上演。

误报的常见原因：

• 阈值设得太死板，没考虑业务周期性
• 单点指标判断，没结合上下文
• 没有加持续时间或连续次数条件

1.3.2 漏报（False Negative）

漏报就是「真故障没发现」。系统已经出问题了，报警没触发。

这个更可怕。误报最多让人烦，漏报直接导致故障时长拉长。

我记得有一次，某核心数据库的连接数缓慢增长，从 100 涨到 800，花了 6 个小时。阈值设的是「连接数 > 1000」。结果在涨到 950 的时候，应用层已经大面积超时了。报警没响，因为没到 1000。

漏报的常见原因：

• 阈值设得过于宽松
• 只关注值，没关注变化率
• 指标覆盖不全，漏掉了关键维度

1.3.3 误报与漏报的权衡

你没法同时消除误报和漏报。这是监控领域的基本定律。

阈值设得越紧，漏报越少，但误报越多。阈值设得越松，误报越少，但漏报越多。你只能根据业务场景，找一个平衡点。

1.4 知识体系总览

下面这张图，是我自己梳理的报警阈值知识框架。你可以先扫一眼，后面每一章都会对应到其中的一个模块。

这张图把报警阈值分成了三大块：阈值定义（怎么设）、阈值调优（怎么调）、误报与漏报（怎么权衡）。后面每一章都会围绕这些展开。

好，这一章就到这里。记住一句话：阈值不是设出来的，是调出来的。后面我们会一步步拆解，怎么调、调成什么样才算好。