接口特征工程：从原始日志到量化行为指纹
说实话，刚接触接口监控那会儿，我踩过一个大坑。
当时负责一个电商平台的API安全监控，每天几亿条请求日志，我直接扔进模型里跑。结果呢？告警刷屏，全是误报。后来一位前辈点醒我：原始日志不是特征，你得先学会提炼。
这一章，咱们就聊聊怎么把那些干巴巴的请求日志，转换成能描述接口行为、能喂给模型的特征向量。我习惯把这步叫做「接口行为的指纹提取」。
1. 请求频率特征：节奏感是最好的基线
你想想看，一个正常的支付接口，白天QPS在5000到8000之间波动，凌晨降到500。这本身就是一种节奏。我习惯把请求频率拆成两个维度来观察。
频率（窗口计数）
- 时间窗口：个人习惯用1秒、5秒、1分钟三级窗口。为什么是三级？短窗口抓毛刺，中窗口看趋势，长窗口稳基线。
- 聚合方式：求和（总请求数）、去重计数（独立IP数/独立用户数），两个都得算。我在项目里见过一次DDoS，总请求量没怎么变，但独立IP暴涨了20倍，一下就暴露了。
相对频率（比值特征）
- IP聚合度：总请求数 ÷ 独立IP数。值突然变高，说明有人在刷。
- 接口占比：某个接口的请求量 ÷ 全站总请求量。接口上线后比例突然从5%跳到20%，可能是逻辑出了问题，也可能被黑了。
关于时间窗口的一点补充：我个人不推荐只用固定窗口。滑动窗口虽然计算代价高一点，但能避免「边界突变」问题——你想想，如果攻击恰好卡在整秒边界上发请求，固定窗口大概率会漏掉。我在生产环境一直用滑动窗口+秒级粒度，效果稳定很多。
频率特征的常见「坑」
- 窗口太小：毫秒级窗口全是噪声，基线根本建不起来。
- 窗口太大：攻击被稀释到正常流量里，看不出异常。
- 只看总量：我曾经遇到过一个爬虫，总QPS只增加了3%，但每个IP只发2个请求，轮换了上千个IP。只拉总量指标根本看不出异常。
我的经验值：上线初期先用1秒窗口+5分钟聚合两层看。1秒窗口能帮你快速发现毛刺，5分钟聚合能帮你做日间对比。稳定运行两周后，再慢慢收窄窗口。
2. 响应时间特征：慢不一定是坏事，突然变慢才是
响应时间的特征提取，我踩过的坑最多。刚开始做的时候，我只取了平均响应时间，结果基线模型天天误报。后来才明白，均值的抗干扰能力太差了。
核心指标
| 指标 | 含义 | 我为什么选它 |
|---|---|---|
| P50（中位数） | 50%请求在多少毫秒内完成 | 反映大部分用户的实际体验 |
| P90 | 90%请求的响应时间上限 | 能暴露出慢速请求的毛刺 |
| P99 | 极端情况下的延迟表现 | 我习惯用这个指标来做告警基线 |
| 标准差 | 响应时间的离散程度 | 反映系统稳定性，波动越大越可疑 |
为什么要看这么多分位数？举个例子：一次数据库连接池耗尽，导致5%的请求响应时间飙到10秒。平均响应时间只从50ms涨到550ms，可能触发不了告警。但P99直接从200ms跳到10秒，一眼就能看出问题。
响应时间分布曲线
我建议把每个时间窗口内的响应时间，按区间做直方图。比如分成[0-10ms, 10-50ms, 50-200ms, 200ms-1s, 1s+]这5个桶。正常状态下分布是稳定的，一旦某个桶的占比突然变了，大概率有问题。
曾经有个线上事故，第三方支付接口间歇性超时。光看平均响应时间，只是从50ms涨到80ms，完全没到阈值。但看分布曲线，200ms-1s这个桶的占比从1%飙到了12%，我顺着这个线索找到了那个拖慢全站的「慢SQL」。
注意：如果你接的是外网API，响应时间的基线最好按运营商/地理区域分开统计。我见过因为某个地区的光缆故障，导致全站P99飙升，但其他区域完全正常。如果不拆分地区特征，这种误报能让你排查到怀疑人生。
3. 参数分布特征：语法正确不等于语义正常
这部分是特征工程里技术含量最高的。接口的参数里藏着的，往往是攻击者留下的痕迹。
数值型参数
- 范围：最小值、最大值、常见值集合。
- 分布形状：正态分布、均匀分布、还是幂律分布？
- 离散度：方差或变异系数，反映参数的波动程度。
比如一个商品ID参数，正常用户的请求里，ID落在1到100万之间，分布相对均匀。但扫描器会按顺序发请求，ID连续的，方差会变得异常小。我记得有一次检测到某个客户端连续请求了ID 100001、100002、100003……，一看就是爬虫在遍历商品库。
字符串型参数
- 长度分布：正常用户名长度一般在3到20个字符，突然来了个5000字节的字符串，大概率是注入攻击。
- 字符集：正常参数里不应该出现SQL关键字或特殊控制字符。我把这个做成一个简单的布尔特征：是否包含
[\bUNION\b, \bOR 1=1\b, \b - 枚举值比例：如果一个参数取值只有固定的几种，比如城市ID始终是
[1, 2, 3, 4]，突然出现了101，这个特征就可以打标记。
参数频率（同一参数的重复度）
这个特征我经常用于检测撞库和暴力破解。在登录接口里，同一个userName在5秒内出现的次数超过正常阈值，就要警惕了。
# 一段我常用的参数分布特征提取伪代码
def extract_param_features(log_batch):
features = {}
for param_name, values in log_batch.items():
# 数值型
if is_numeric(values):
features[param_name + '_mean'] = np.mean(values)
features[param_name + '_std'] = np.std(values)
features[param_name + '_range'] = max(values) - min(values)
# 字符串型
else:
lengths = [len(v) for v in values]
features[param_name + '_len_mean'] = np.mean(lengths)
features[param_name + '_len_std'] = np.std(lengths)
# 检查是否包含恶意载荷
features[param_name + '_has_sqli'] = any(re.search(r'(\bUNION\b|\bOR\d+=\d+\b)', v) for v in values)
return features
避坑指南：参数分布特征非常依赖参数名对齐。如果日志里同一个参数在不同请求里用了不同的key（比如user_id vs userId），你的特征提取会全部错乱。我曾经在这个问题上浪费了整整两天时间，最后才发现是接口版本不一致导致的字段名不规范。
4. 状态码特征：错误的模式里藏着真相
状态码的特性和其他几个维度不太一样：
- 它是离散的、枚举的。没有「平均状态码」这种说法。
- 它的信息量很大。几个状态码的组合模式，往往能直接定位问题类型。
核心特征维度
- 各状态码占比：正常接口的2xx占比大概率在99%以上。4xx占比突然从0.5%涨到5%，不是客户端参数错了，就是有人在扫接口。
- 状态码转移矩阵：同一个客户端，连续请求的状态码变化模式。正常用户是2xx → 2xx → 2xx，扫描器则是4xx → 4xx → 4xx，这个特征在异常检测里非常好用。
- 5xx与4xx的比例：5xx是服务端错误，4xx是客户端错误。如果5xx突然增多，排查服务器问题；如果4xx增多，排查客户端或者攻击行为。
状态码的时间序列特征
单一时间点的状态码分布意义有限。我习惯把状态码随时间的变化做趋势分析：某个状态码是在逐渐增多，还是突然爆发？前者可能是系统退化，后者则可能是攻击。
| 状态码模式 | 常见场景 | 建议动作 |
|---|---|---|
| 大量 403 / 401 | 权限遍历、撞库、令牌猜测 | 触发频率限流+临时封禁 |
| 大量 404 / 405 | 目录扫描、接口发现 | 加入黑名单+蜜罐诱饵 |
| 500 与 200 交替出现 | 攻击者尝试不同参数触发异常 | 升级告警为严重级别 |
| 502 / 503 集中爆发 | 后端过载、服务雪崩 | 优先检查服务器资源 |
特别注意：状态码特征在单机版日志里效果很好。但一旦上了负载均衡或者网关，状态码会被改变。比如Nginx后端返回了500，但网关层可能因为设置了proxy_intercept_errors on而返回一个200 + 自定义错误页面。这种情况下，你一定要在最上游的入口处采集原始状态码，否则基线模型会学到错误的行为模式。
5. 特征工程的核心逻辑：组合比单一更重要
讲到这里，你应该能感受到每个维度都有自己的「视角」。但真正让异常无处遁形的，是把四个维度的特征拼成一个大向量。
- 纯频率异常：正常流量里的突发脉冲，可能是活动推广，也可能是DDoS。
- 频率+响应时间：流量没变但响应时间突变，说明后端出了问题。
- 频率+参数分布：流量正常但参数长度突变，注入攻击的概率很大。
- 频率+状态码：流量增加的同时4xx比例上升，大概率是扫描行为。
我习惯在特征工程完成后，再顺手做一次特征重要性排序。把每个维度的特征和已知的攻击标签做相关性分析，保留Top 20的特征进入模型。这样做有两个好处：一是减少计算量，二是剔除掉那些「看起来很美但实际没用」的特征。