数据采集与预处理：数据源类型、清洗、异常值处理与标准化
数据采集与预处理，是整个报警阈值体系的基石。你想想看，如果源头数据就是脏的、乱的，那后面再花哨的算法也白搭。我个人习惯把这一步叫做“数据入场安检”，做得好，后面省心十倍。
2.1 数据源类型：指标、日志、事件
我们日常打交道的监控数据，说白了就三大类。我刚开始做运维那会儿，经常把日志和事件搞混，后来踩了坑才分清楚。
| 数据源类型 | 典型特征 | 常见例子 | 采集方式 |
|---|---|---|---|
| 指标（Metrics） | 数值型、可聚合、有时间戳 | CPU使用率、QPS、内存占用 | Agent拉取、Push推送 |
| 日志（Logs） | 文本型、非结构化或半结构化 | 应用错误日志、访问日志 | Filebeat、Fluentd采集 |
| 事件（Events） | 离散型、状态变化、有上下文 | 服务重启、部署完成、告警触发 | API回调、消息队列 |
我的经验：指标适合做趋势分析和阈值告警，日志适合做根因定位，事件适合做状态机判断。三者结合，才能构建完整的监控视图。
2.2 数据清洗：别让脏数据骗了你的阈值
数据清洗，听着简单，做起来全是细节。我曾经遇到过一个案例：某服务的P99延迟突然飙升到10秒，报警阈值被触发，值班同学半夜爬起来排查。结果发现是采集Agent在凌晨3点做了一次全量日志压缩，导致CPU争抢。这就是典型的“脏数据”引发的误报。
我建议至少做以下几步清洗：
- 去重：网络抖动可能导致同一数据点被重复推送，保留最新一条即可。
- 补全：时间戳缺失、标签缺失的数据，直接丢弃或标记为无效。
- 格式统一：比如时间戳统一为Unix毫秒级，单位统一为秒或毫秒。
- 范围过滤：CPU使用率不可能超过100%，内存使用率不可能为负数，超出物理范围的数据直接剔除。
避坑指南：我曾经因为没做“时间戳对齐”，导致两个数据源的时间差了几分钟，阈值计算出来的结果完全不对。记住，时间戳必须统一到同一个时钟源。
2.3 异常值处理：别把“真异常”当“脏数据”
异常值和脏数据，有时候长得像，但本质完全不同。脏数据是采集错误，异常值是真实发生的极端情况。比如某台机器的CPU突然冲到99%，这可能是攻击、死循环或者硬件故障，你不能把它当脏数据扔掉。
我常用的异常值处理方法：
- 3σ原则：适用于正态分布的数据，超出均值±3倍标准差的值视为异常。
- IQR（四分位距）法：适用于偏态分布，Q1 - 1.5*IQR 以下或 Q3 + 1.5*IQR 以上视为异常。
- 移动平均法：用滑动窗口的平均值替换突刺，适合平滑处理。
# 一个简单的IQR异常值检测示例
import numpy as np
def detect_outliers_iqr(data):
Q1 = np.percentile(data, 25)
Q3 = np.percentile(data, 75)
IQR = Q3 - Q1
lower_bound = Q1 - 1.5 * IQR
upper_bound = Q3 + 1.5 * IQR
outliers = [x for x in data if x < lower_bound or x > upper_bound]
return outliers, lower_bound, upper_bound
关键认知：异常值处理不是“一刀切”地删除。对于报警阈值设定，异常值恰恰是我们需要关注的对象。我的做法是：先标记异常值，再判断它是“需要报警的异常”还是“需要剔除的噪声”。
2.4 数据标准化：让不同量纲的数据“对齐”
为什么需要标准化？你想想看，CPU使用率是0~100的百分比，内存是GB级别，QPS是万级别。如果直接拿这些原始数据去算阈值，量纲大的数据会主导结果，量纲小的数据直接被淹没。
我常用的标准化方法：
| 方法 | 公式 | 适用场景 |
|---|---|---|
| Min-Max标准化 | (x - min) / (max - min) | 数据有明确上下界，如CPU、内存 |
| Z-score标准化 | (x - mean) / std | 数据近似正态分布，无明确边界 |
| Robust标准化 | (x - median) / IQR | 数据存在较多异常值，对异常不敏感 |
我个人习惯在报警阈值设定前，先做一次Z-score标准化。这样不同指标的数据就可以放在同一个尺度下比较，方便设定统一的告警等级。
2.5 本章知识体系总览
下面这张图，是我梳理的数据采集与预处理核心流程。你可以把它当作一个检查清单，每次搭建监控系统时对照着走一遍。
嗯，到这里，数据采集与预处理的核心内容就讲完了。记住一句话：数据质量决定了阈值设定的上限。源头干净，后面的工作才有意义。