📚 课程目录第1章 APM指标采集概述与技术选型

1. APM指标采集概述与技术选型

APM（Application Performance Monitoring）的核心在于对系统运行时的三大信号进行持续采集与关联分析。本章从信号模型出发，对比主流采集工具，并确定适用于实战课程的采集架构与数据流方向。

1.1 三大可观测信号

Metrics、Traces、Logs 构成可观测性的三大支柱，各自关注不同维度的系统状态：

信号类型	核心关注点	典型示例	数据特性
Metrics	量化指标，聚合趋势	请求延迟P99、CPU利用率、QPS	数值型、时序、可聚合
Traces	请求链路，服务拓扑	一次用户请求经历的服务调用链	有向图、Span、上下文传播
Logs	事件记录，故障定位	错误堆栈、慢查询SQL日志	文本、时间戳、非结构化或半结构化

关联关系：告警依赖 Metrics 的聚合阈值判断，而根因分析需要 Traces 串联上下游，Logs 提供详细上下文。三者在采集阶段应保持一致的标签体系（如 service.name、trace_id）。

1.2 采集工具选型对比

课程选型评估三个主流工具：Prometheus（原生Metrics）、OpenTelemetry（统一信号协议）、SkyWalking（专有APM）。

维度	Prometheus	OpenTelemetry	SkyWalking
信号覆盖	Metrics（核心）	Metrics + Traces + Logs	Traces（强）+ Metrics + Logs
数据采集方式	Pull/Push（Pushgateway）	Agent SDK + Collector（Push）	Java Agent + 原生协议
自定义扩展性	强（Exporter/Relabeling）	极强（Instrumentation API + Processor）	中（插件扩展）
告警引擎	内置 Alertmanager	依赖外部（推荐 Prometheus）	内置告警规则
社区生态	CNCF 毕业项目，生态成熟	CNCF 孵化，云原生标准	Apache 顶级，中文社区活跃
学习曲线	中等（PromQL 掌握）	较高（多信号配置复杂）	低（Agent 自动注入）

课程选型结论：采用 OpenTelemetry + Prometheus + Grafana 组合。OpenTelemetry 负责统一采集三大信号；Prometheus 作为时序数据库存储 Metrics 并触发告警；Grafana 统一展示 Dashboard。此组合兼顾灵活性、社区支持和云原生标准。

1.3 采集架构与数据流方向

整体架构分为四个核心层：应用插桩层 → 采集层 → 存储层 → 展示告警层。下图展示数据流：

数据流方向说明：

应用通过 OpenTelemetry SDK 插桩，自动生成 Metrics、Traces、Logs 三大信号。
SDK 将信号以 OTLP 协议 推送到 OpenTelemetry Collector。Collector 负责批量、过滤、添加资源属性等预处理。
Collector 按信号类型分别导出到对应后端存储：Prometheus（Metrics）、Tempo/Jaeger（Traces）、Loki/Elasticsearch（Logs）。
Grafana 作为统一展示层，通过 DataSource 连接各存储，同时配置告警规则（基于 Prometheus Metrics 触发）。

实践注意：生产环境中，OpenTelemetry Collector 建议部署为独立进程或 DaemonSet，注意 OTLP gRPC 端口（默认4317）和 HTTP 端口（默认4318）的防火墙策略。Metrics 存储与告警引擎应部署在靠近 Collector 的区域以降低延迟。

1.4 关键实现流程

本章后续课程将按以下流程逐步搭建：

环境初始化：Docker Compose 或 Kubernetes 部署各组件
应用插桩：通过 OpenTelemetry SDK 集成 Java/Go/Python 应用
Collector 配置：配置接收器（Receivers）、处理器（Processors）、输出（Exporters）
存储对接：配置 Prometheus remote write / Tempo OTLP / Loki 日志采集
Dashboard 与告警：Grafana 导入预设模板，编写 PromQL 告警规则

以下为 Collector 最小配置示例（YAML）：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
    namespace: apm_lab
  otlp/traces:
    endpoint: tempo:4317
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/traces]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

调试提示：启动 Collector 后，通过 curl http://localhost:8889/metrics 检查 Prometheus 端点是否暴露指标。用 grpcurl -plaintext localhost:4317 list 验证 OTLP 服务可用。

1.5 性能与稳定性考量

数据量预估：Metrics 和 Traces 流量随请求量线性增长，建议为 Collector 分配足够内存（至少 512MB per 1000 spans/s）。
缓冲区配置：Collector 的 batch processor 可设置 send_batch_max_size 避免积压；queued_retry exporter 应对后端抖动。
标签基数控制：Prometheus 对高基数标签敏感，应用插桩时应限制 metric 中 label 数量（如 http.method 而非 user_id 等无限值）。