1. 课程导论：什么是遥测数据？为什么需要异常检测？基线模型的核心思想
大家好，欢迎来到这门课。我是你们这趟旅程的向导，一个在运维和AI坑里摸爬滚打了好些年的老兵。
咱们这门课叫《基于遥测基线的异常检测模型》。名字挺长，但别被吓到。说白了，就是教你怎么用一套系统的方法，自动发现服务器、应用或者网络设备上那些「不对劲」的时刻。
在开始动手之前，我觉得有必要先把几个最基础的概念掰扯清楚。嗯，这就好比盖房子，地基得打牢。今天这一讲，我们就聊聊三个核心问题：遥测数据到底是什么？我们为什么非得搞异常检测？以及，那个听起来很厉害的「基线模型」，它的核心思想究竟是什么？
1.1 什么是遥测数据？
先说说遥测数据。这个词儿听起来有点高大上，其实你每天都在跟它打交道。
遥测（Telemetry），原意是「远程测量」。在IT领域，它就是从系统、应用或设备中自动采集并上报的各种指标、日志和事件。
我个人习惯把遥测数据分成三大类，这样比较好记：
| 类别 | 典型例子 | 特点 |
|---|---|---|
| 指标（Metrics） | CPU使用率、内存占用、请求延迟、QPS | 数值型，可聚合，通常按时间序列存储 |
| 日志（Logs） | 应用报错信息、访问日志、系统事件 | 文本型，非结构化或半结构化，信息最丰富 |
| 链路追踪（Traces） | 一次请求经过的完整服务调用链 | 关联型，用于定位分布式系统中的性能瓶颈 |
你想想看，一个大型电商网站，背后可能有成千上万台服务器。每一台都在不停地往外吐数据：CPU又涨了、内存又满了、某个接口又慢了……这些数据就是遥测数据。它们就像系统的「脉搏」和「体温」，是我们感知系统健康状况的唯一窗口。
1.2 为什么需要异常检测？
好，数据有了。那下一个问题：我们为什么需要异常检测？直接设个固定阈值不就行了？比如CPU超过90%就报警。
嗯，这确实是最朴素的方法。但现实世界远比这个复杂。我给大家举几个例子：
- 场景一：业务大促。双十一零点，流量暴增，CPU冲到95%是正常的。如果你设了90%的阈值，那报警电话会把你打爆。但这时候系统其实没出问题，它在正常扛压。
- 场景二：慢速退化。内存泄漏。今天内存占用是60%，明天是62%，后天是64%……它不会突然跳变，但一个月后，系统挂了。固定阈值根本抓不住这种「温水煮青蛙」式的异常。
- 场景三：周期性波动。一个新闻网站，白天流量高，晚上流量低。白天正常的QPS，放到晚上就是异常。阈值怎么设？设高了，白天漏报；设低了，晚上误报。
看到了吧？固定阈值在动态、复杂的系统面前，显得非常笨拙。
我们需要的是一种更智能的方法——它能理解系统的「正常」是什么样子，然后自动识别出那些「偏离正常」的行为。这就是异常检测的核心价值。
核心观点： 异常检测不是为了发现「数值高」，而是为了发现「行为反常」。它关注的是数据在时间维度上的上下文和模式。
1.3 基线模型的核心思想
终于聊到重点了。什么是基线模型？
我个人理解，基线模型就是系统「正常行为」的数学画像。它通过学习历史遥测数据，总结出一套规律，然后用这套规律去判断新的数据点是否「出格」。
它的核心思想可以概括为三步：
- 学习（Learn）：收集一段时间的「正常」数据，训练出一个模型。这个模型能描述数据在时间上的分布、趋势和周期性。
- 预测（Predict）：对于当前时刻，模型会给出一个「预期值」和一个「合理波动范围」。这个范围，就是我们常说的「动态阈值」。
- 判断（Judge）：将实际观测值与预期值进行比较。如果偏差超出了合理范围，就判定为异常。
为了让你更直观地理解，我画了一张图：
这张图把流程说得很清楚了。但这里有一个关键点，也是很多初学者容易误解的地方：基线模型不是一成不变的。
它需要持续学习。比如，系统升级了、业务模式变了、用户习惯改了……这些都会导致「正常行为」发生变化。一个好的基线模型，应该能自适应这些变化，不断更新自己对「正常」的理解。
1.4 本章小结
好了，我们来快速回顾一下今天的内容：
- 遥测数据是系统的「脉搏」，包括指标、日志和链路追踪三大类。
- 固定阈值在动态系统中力不从心，我们需要更智能的异常检测来发现「行为反常」。
- 基线模型的核心思想是：学习历史数据 → 生成动态基线 → 实时比对判断。它是一个持续学习和自适应的过程。