4. 数据采集与预处理：日志采集规范、指标打点、数据清洗、缺失值处理、时间戳对齐

在API发布阶段，特征异常值的有效排查依赖于高质量的数据基础。若数据采集不规范、预处理不严谨，后续的异常检测模型将面临“垃圾进，垃圾出”的困境。本章聚焦于从原始日志到可用特征矩阵的标准化流程，确保数据在时间、格式、完整性三个维度上满足分析要求。

4.1 日志采集规范

日志是特征数据的原始来源。缺乏规范的日志会导致字段缺失、格式混乱、解析失败。生产环境必须遵循以下核心规范：

• 结构化输出：强制使用JSON或Protobuf格式，禁止自由文本拼接。每条日志必须包含timestamp、service_name、api_version、request_id、latency_ms、status_code、error_type等预定义字段。
• 固定Schema：每个微服务在发布前需注册日志Schema到配置中心，变更Schema必须走兼容性评审（向后兼容或字段弃用策略）。
• 采样与限流：对于高QPS接口（如>10000/s），采用自适应采样策略，确保关键错误日志100%采集，正常日志按比例采样（如1:1000），避免存储爆炸。
• 上下文关联：通过全局Trace ID串联上下游调用链，便于在异常排查时回溯完整请求路径。

4.2 指标打点

指标（Metrics）是数值型特征的核心来源，用于量化API的健康状态与性能。打点规范直接影响特征分布的稳定性。

打点原则：

• 标签（Label）维度控制：每个指标附加的标签（如method、endpoint、version）基数应小于1000，避免高基数标签导致存储与查询性能劣化。
• 时间窗口对齐：所有指标采集周期统一为10秒或60秒，避免因采集周期不一致导致后续时间戳对齐困难。
• 单位标准化：延迟统一使用毫秒（ms），包大小统一使用字节（Byte），错误码统一使用HTTP标准状态码。

4.3 数据清洗

原始数据中常混入脏数据，必须在特征计算前进行清洗。常见脏数据类型及处理策略如下：

• 格式错误：JSON解析失败、字段类型不匹配（如字符串混入数字字段）。处理：丢弃该条记录并记录错误计数到监控看板。
• 业务无效数据：健康检查请求（/health）、预发环境流量、压测流量。处理：通过标签过滤或白名单机制剔除。
• 异常值（Outliers）：延迟为负数、状态码为999（未定义）、请求体大小为0但实际有内容。处理：基于IQR或3σ规则标记为缺失值，进入后续缺失值处理流程。
• 重复数据：因重试或消息队列重复投递导致。处理：基于request_id + timestamp去重，保留第一条记录。

4.4 缺失值处理

特征缺失在发布阶段极为常见，原因包括：采集延迟、服务重启导致指标断点、新版本新增字段但旧版本未上报。缺失值处理不当会直接导致异常检测模型误判。

4.5 时间戳对齐

多数据源（日志、指标、调用链）的时间戳往往存在偏差，直接拼接会导致特征错位。时间戳对齐是特征工程中极易出错但至关重要的步骤。

对齐流程：

1. 统一时区：所有数据源强制转换为UTC时间，避免因夏令时或跨时区部署导致的时间漂移。
2. 规整到标准时间窗口：将毫秒级时间戳向下取整到最近的10秒或60秒边界。例如，timestamp=1712345678123ms 规整到 1712345670000ms（10秒窗口）。
3. 处理延迟到达数据：允许数据在窗口结束后延迟到达（如最多延迟2个窗口），超时数据直接丢弃或存入死信队列。
4. 对齐验证：对齐后，检查每个时间窗口内各数据源的数据点数量是否在合理范围内（如每个窗口应恰好有1个指标点）。

4.6 预处理质量校验

完成上述步骤后，必须对预处理结果进行质量校验，确保特征矩阵可用：

• 完整性检查：每个时间窗口内，所有特征字段均无缺失值（或已按策略填充）。
• 范围检查：数值型特征在合理范围内（如延迟0~60000ms，错误率0~1.0）。
• 时序连续性检查：时间戳序列严格递增且无跳点（允许窗口规整后的等间隔）。
• 分布稳定性检查：对比预处理前后特征分布的均值、方差变化，确保填充/插值未引入系统性偏差。