4. 数据采集策略：日志采集、APM工具埋点、数据库慢查询日志、网络抓包的数据源选择
压力测试的数据采集是特征构建的“原材料”环节。不同数据源在采集粒度、性能开销、覆盖维度上差异显著。选择错误的数据源会导致特征失真或测试环境失真。本节从四个主流数据源出发，分析其适用场景、采集策略与工程约束。
4.1 四种数据源的核心差异
| 数据源 | 采集粒度 | 性能开销 | 覆盖维度 | 典型延迟 | 主要风险 |
|---|---|---|---|---|---|
| 日志采集 | 请求级 / 行级 | 低（异步写入） | 业务逻辑、错误码、耗时 | 秒级～分钟级 | 日志丢失、磁盘IO瓶颈 |
| APM工具埋点 | 调用链 / 方法级 | 中（采样率可控） | 全链路拓扑、SQL、外部调用 | 实时～10秒 | 采样偏差、Agent侵入 |
| 数据库慢查询日志 | SQL语句级 | 低（仅记录超阈值） | 索引效率、锁等待、扫描行数 | 分钟级 | 漏报短查询、日志膨胀 |
| 网络抓包 | 数据包级 | 高（全量捕获） | 协议、重传、延迟、吞吐 | 实时 | 数据量大、解析复杂 |
选型原则： 压测场景下优先使用 APM + 慢查询日志 组合作为主力数据源；日志采集用于补充业务特征；网络抓包仅在协议层问题排查或带宽瓶颈分析时启用。
4.2 日志采集策略
日志采集是成本最低、覆盖最广的数据源，但压测场景下需注意以下要点：
- 结构化日志：强制使用 JSON 格式，包含 traceId、spanId、timestamp、costMs、statusCode、requestBody 摘要等字段。
- 异步采集：使用 Logstash / Filebeat 等轻量采集器，避免同步写盘影响压测线程。
- 采样策略：压测流量大时，对非关键接口按 1:10 或 1:100 采样，关键接口全量采集。
- 磁盘预留：压测前确保日志盘有至少 20GB 余量，并配置日志轮转（按大小或时间）。
# 结构化日志示例（JSON）
{
"timestamp": "2025-03-21T14:32:10.123Z",
"traceId": "a1b2c3d4e5f6",
"spanId": "span-001",
"service": "order-service",
"method": "createOrder",
"costMs": 342,
"statusCode": 200,
"userId": "u_98765",
"skuCount": 3,
"errorMsg": null
}
4.3 APM工具埋点策略
APM（Application Performance Monitoring）工具如 SkyWalking、Pinpoint、Jaeger 提供调用链级别的数据采集，是压测特征构建的核心数据源。
- 全量 vs 采样：压测场景建议设置采样率为 100%（短时压测）或 10%～50%（长时压测），避免 Agent 内存溢出。
- 关键指标：采集每个 Span 的 startTime、endTime、status、errorCount、db.executeTime、external.http.url。
- 拓扑构建：利用 APM 的依赖图自动生成服务调用拓扑，用于识别压测中的热点路径。
- Agent 配置：关闭不必要的插件（如 MQ、Redis 非关键操作），减少埋点开销。
实践建议： 在压测脚本中注入自定义 Tag（如压测批次号、场景名称），便于在 APM 控制台快速过滤压测流量与正常流量。
4.4 数据库慢查询日志策略
慢查询日志是定位数据库性能瓶颈的直接证据。压测期间需调整以下参数：
| 参数 | 压测推荐值 | 说明 |
|---|---|---|
| long_query_time | 0.1～0.5 秒 | 压测场景下降低阈值，捕获更多慢 SQL |
| log_queries_not_using_indexes | ON | 发现全表扫描的 SQL |
| log_slow_admin_statements | ON | 记录 DDL 等管理语句 |
| slow_query_log_file | 独立文件 | 与业务日志分离，便于分析 |
# MySQL 慢查询日志示例
# Time: 2025-03-21T14:32:15.123456Z
# User@Host: root[root] @ localhost []
# Query_time: 2.345678 Lock_time: 0.000123
# Rows_sent: 1000 Rows_examined: 500000
SET timestamp=1742567535;
SELECT * FROM orders WHERE status = 'PENDING' ORDER BY create_time DESC;
注意： 压测结束后务必恢复 long_query_time 为生产默认值（通常 1～2 秒），避免慢查询日志持续膨胀占用磁盘。
4.5 网络抓包策略
网络抓包（tcpdump / Wireshark）在压测中主要用于协议层问题定位，不建议作为常规数据源。适用场景包括：
- TCP 重传率异常升高时的根因分析。
- TLS 握手耗时过长时的证书链排查。
- 带宽瓶颈验证（对比抓包吞吐与压测吞吐）。
- DNS 解析延迟或 HTTP 连接复用失效。
# tcpdump 常用压测抓包命令
tcpdump -i eth0 -s 0 -w /data/capture.pcap \
'tcp port 8080 and host 10.0.1.100' \
-c 1000000
抓包注意事项： 全量抓包会产生巨大文件（1Gbps 流量下约 450GB/小时），建议使用 BPF 过滤器 缩小范围，或使用 采样抓包（如 -c 参数限制包数）。
4.6 数据源选择决策流程
4.7 多数据源融合策略
实际压测中，单一数据源往往无法覆盖所有特征维度。推荐采用以下融合策略：
- APM + 慢查询日志：APM 提供调用链上下文，慢查询日志提供 SQL 级细节，两者通过 traceId 或时间窗口关联。
- 日志 + APM：日志补充业务字段（如用户等级、商品类目），APM 提供性能指标，用于构建业务维度的性能特征。
- 网络抓包 + APM：当 APM 显示外部调用耗时异常时，用抓包验证网络延迟、重传、带宽等底层原因。
融合示例： 某电商压测发现下单接口 P99 延迟从 200ms 飙升到 2s。APM 显示数据库调用耗时正常，但外部 HTTP 调用耗时异常。网络抓包确认是第三方物流 API 的 TLS 握手超时。最终特征构建时，将“第三方 API 握手耗时”作为独立特征加入压测模型。
4.8 数据采集避坑清单
| 常见问题 | 后果 | 解决方案 |
|---|---|---|
| APM 采样率过低 | 特征稀疏，无法构建统计模型 | 压测期间临时提高采样率至 50%～100% |
| 日志采集阻塞主线程 | 压测结果失真（延迟偏高） | 使用异步日志框架（Log4j2 AsyncAppender） |
| 慢查询日志阈值过高 | 漏报大量慢 SQL | 压测前调低 long_query_time 至 0.1s |
| 网络抓包未过滤 | 磁盘写满，压测中断 | 使用 BPF 过滤器 + 限制抓包时长 |
| 多数据源时间不同步 | 特征关联失败 | 统一使用 NTP 同步，日志时间戳精确到毫秒 |