1. 告警阈值概述
告警阈值这玩意儿，说白了就是一根线。日志里某个指标一旦超过这根线，系统就喊你“出事了”。我刚开始接触监控时，觉得阈值不就是设个数字吗？后来踩了不少坑才发现，这根线划在哪里，直接决定了你晚上能不能睡个安稳觉。
1.1 什么是告警阈值
告警阈值是一个预设的数值边界。它把监控指标分成两个区间：正常区和异常区。比如CPU使用率超过90%就告警，这个90%就是阈值。你想想看，没有阈值，日志就是一堆数字，你根本不知道哪些需要处理。
在我经历过的一个项目中，团队把磁盘使用率阈值设成了95%。结果某天凌晨日志量暴增，磁盘冲到94%时还没触发告警，等我们发现已经写不进日志了。嗯，那次事故之后，我养成了一个习惯——阈值一定要留余量。
- 指标：你要监控什么（CPU、内存、延迟、错误率等）
- 界限：超过多少算异常（固定值、百分比、速率等）
- 持续时间：异常要保持多久才触发（避免毛刺误报）
1.2 为什么需要认真设计阈值？
阈值设得太低，告警像放鞭炮一样响个不停，运维团队很快就麻木了——狼来了的故事听过吧？设得太高呢，等告警出来，业务可能已经挂了。我个人习惯把阈值分成三级：预警、告警、严重。预警用来提醒你“注意了”，严重才是真的出事了。
| 阈值级别 | 含义 | 典型响应方式 |
|---|---|---|
| 预警（Warning） | 指标偏离正常但尚可接受 | 记录日志、通知值班人 |
| 告警（Alert） | 指标明显异常，需人工介入 | 发送短信、弹出工单 |
| 严重（Critical） | 业务已受影响，需立即止损 | 电话 + 自动降级 |
曾经有个同事把所有阈值都设成了固定值，结果业务流量高峰时误报一堆，低谷时又漏报。那段时间他每天被报警电话吵醒，后来改用动态阈值才算解脱。所以啊，阈值的核心不是设一个数，而是让系统学会自适应。
1.3 告警阈值在日志巡检中的应用场景
日志巡检里，阈值无处不在。我来列几个典型场景：
- 错误率监控：5xx响应比例超过1%就告警，超过5%立即严重。
- 延迟异常：P99延迟超过500ms持续5分钟，说明服务可能雪崩。
- 日志总量暴增：每秒日志条数突然变成平时的10倍，大概率是程序死循环或者被攻击。
- 特定关键字命中：比如“OOM”“OutOfMemory”出现一次就报警，这不能忍。
你可能会问，这些场景的阈值怎么定？我一般先看历史数据，取过去两周的P95或P99作为基准线，再根据业务容忍度上下浮动。举个例子，正常P99延迟是200ms，那预警线设在300ms，告警线设在500ms。说白了，阈值要有数据依据，不能拍脑袋。
1.4 告警阈值知识体系
下面这张图把本章的核心概念串了起来。你一看就明白它们之间的关系。
从图上你能看到，阈值本身分三大类：固定、动态和基于统计。我早期用过固定阈值，简单粗暴，但业务波动时就完蛋。后来改用动态阈值，比如取最近1小时的指标均值加减三倍标准差，效果好很多。不过动态阈值也有坑——如果业务突然降为零，标准差会缩到极小，导致任何波动都报警。所以，实际落地时常常采用组合策略。
1.5 一个简单的阈值判断示例
下面这段Python代码演示了最基本的阈值逻辑。实际生产中当然复杂得多，但核心思想一样。
def check_threshold(metric_value, warning=80, critical=95):
"""
检查指标值是否触发告警
:param metric_value: 当前指标值（如CPU使用率）
:param warning: 预警阈值
:param critical: 严重阈值
:return: 'normal', 'warning' 或 'critical'
"""
if metric_value >= critical:
return 'critical'
elif metric_value >= warning:
return 'warning'
else:
return 'normal'
# 使用示例
cpu = 92
status = check_threshold(cpu)
print(f'当前CPU状态：{status}') # 输出 warning
这段代码很简单，但它暴露了一个问题：如果指标本身有毛刺（比如瞬间跳高又回落），正常业务就会被误报。所以我通常会加一个持续时间参数——连续3次采样都超阈值才告警。你想想看，加了这个之后，半夜被电话吵醒的概率是不是低多了？
好了，这一章我们先把告警阈值的概念、重要性和应用场景理清了。你看懂了吗？简单说就是：阈值不是冰冷的数字，它是你和系统之间的默契。设得好，运维轻松；设不好，灾难不停。