3. 数据采集策略与工具链

问题排查的起点是现象识别，但真正让现象“开口说话”的是精准的数据采集。本章围绕排查流程中的数据采集环节，讲解如何根据现象特征选择正确的指标、日志、分布式追踪或性能剖析工具，并构建可复用的采集策略。

3.1 现象识别与采集策略映射

不同现象类型对应不同的数据采集优先级，如下表所示。建议在出现问题时，先按表快速匹配初始采集方向。

3.2 系统指标采集 — 资源级“心电图”

系统指标是所有排查的基础层数据。常用工具有 node_exporter + Prometheus、Telegraf、collectd。关键采集项包括：

• CPU：利用率、上下文切换、运行队列长度
• 内存：可用/总量、交换分区使用率、OOM次数
• 磁盘：IOPS、吞吐量、await、%util
• 网络：带宽利用率、重传率、连接队列溢出

典型采集配置示例（Prometheus + node_exporter）：

# /etc/prometheus/prometheus.yml 片段
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
    scrape_interval: 15s
    metrics_path: '/metrics'

3.3 日志采集 — 多维度的“黑匣子”

结构化日志（JSON/Protobuf）是诊断业务逻辑错误的利器。推荐工具链：

• 采集：Filebeat / Fluentd / Vector
• 传输：Kafka / 直接写入ES
• 存储检索：Elasticsearch + Kibana / Loki + Grafana

日志字段应包含：timestamp、level、service、trace_id、message、error_stack。以下是一个标准JSON日志行：

{
  "timestamp": "2025-04-07T10:32:15.123Z",
  "level": "ERROR",
  "service": "payment-api",
  "trace_id": "abc123def456",
  "message": "支付超时，商户ID: 8876",
  "error_stack": "com.example.PaymentException: timeout\n  at ..."
}

3.4 Trace采集 — 分布式请求的全路径回放

在微服务架构中，Trace（链路追踪）是定位延迟和错误传递的关键。主流工具：

• OpenTelemetry（标准SDK+协议）
• Jaeger（存储+UI）
• Zipkin（轻量级替代）

采集策略建议：

1. 固定采样率：生产环境建议10%头部采样，结合错误标签100%采样。
2. 尾部采样：对已完成请求按规则过滤（如耗时>P99）保留完整Trace。
3. 分布式上下文传播：必须统一W3C TraceContext协议。

3.5 Profiling工具选型 — 代码级“手术刀”

当系统指标和日志无法解释CPU或内存异常时，需要借助Profiling进行代码级分析。常见类型对比：

3.6 采集决策树：从现象到工具链

下图为问题排查中数据采集工具的选择逻辑。当新现象出现时，按直觉回答决策点问题，快速定位最有效的采集手段。

3.7 采集策略与后续环节衔接

完成数据采集后，进入原因定位阶段。注意以下衔接要点：

• 保留原始上下文：采集到的指标、日志、Trace必须携带实例标识和环境标签，方便聚合分析。
• 避免过度采集：高频指标（如1s间隔）持续存储成本高，生产环境建议将原始数据保留7天，降采样后保留30天。
• 自动化触发：配置告警规则，当指标或日志出现特定模式时自动拉起Profiling或Trace全量采样（例如：CPU>90%持续5分钟触发5分钟持续Profiling）。