3. 压力测试数据采集：系统性能指标、应用层指标与日志采集方法

压力测试的数据采集是特征工程的“原材料”环节。采集数据的质量、粒度和完整性直接决定后续特征构造与模型训练的上限。本章从系统层、应用层和日志层三个维度，系统讲解核心指标的定义、采集工具与工程化方法。

3.1 系统性能指标采集

系统层指标反映被测服务所在物理机或容器的资源饱和度，是定位性能瓶颈的底层依据。主要采集维度包括：

3.2 应用层指标采集

应用层指标直接衡量被测系统对外提供服务的能力，是压力测试结果的核心判据。三大黄金指标：

• TPS（Transactions Per Second）：每秒完成的事务数，反映系统吞吐能力。采集时需区分“成功 TPS”与“总 TPS”。
• 响应时间（Response Time）：通常关注平均响应时间、P50、P90、P99 及最大响应时间。P99 对长尾延迟敏感，是特征工程中常用的“压力敏感特征”。
• 错误率（Error Rate）：包括 HTTP 5xx、超时、业务逻辑错误。错误率突增往往是系统进入过载区的先兆信号。

3.3 日志数据采集方法

日志是特征工程中“非结构化数据”的主要来源。压力测试期间的日志采集需兼顾完整性与低侵入性。常用方法如下：

1. 标准输出重定向：通过 shell 将应用 stdout/stderr 写入文件，配合 logrotate 轮转。
2. 日志框架异步采集：使用 Log4j2 / Logback 的 AsyncAppender，或 Python logging 的 QueueHandler，避免日志 I/O 阻塞业务线程。
3. Filebeat / Fluentd 轻量采集：以 agent 方式读取日志文件，压缩后发送到 Kafka 或 Elasticsearch，适合大规模压测集群。
4. 结构化日志：强制使用 JSON 格式输出，包含 timestamp、level、traceId、duration、errorCode 等字段，便于后续特征提取。

# 结构化日志示例（JSON 格式）
{"timestamp":"2025-03-21T14:32:10.123Z","level":"ERROR","traceId":"a1b2c3d4","service":"order-svc","duration":1523,"errorCode":"TIMEOUT","message":"redis read timeout"}

3.4 三层数据采集架构总览

下图展示了从系统层、应用层到日志层的完整数据采集链路，以及各层数据最终汇聚到特征存储的路径：

3.5 采集工程化要点

• 时间戳对齐：系统层、应用层、日志层使用同一台 NTP 服务器，时间戳精度至少到毫秒级，否则特征拼接会出现偏移。
• 采样窗口统一：所有指标在特征工程阶段统一重采样到相同时间窗口（如 5s、10s），避免因采集频率不同导致特征维度不一致。
• 元数据标记：每条采集记录附带压测场景 ID、并发数、请求类型等标签，便于后续按场景切片分析。
• 数据完整性校验：压测结束后，对比各层数据条数与预期请求数，差值超过 1% 则视为采集链路存在丢点，需排查 agent 或网络问题。