第1章：APM埋点核心概念与选型——数据模型、采样策略、主流APM方案对比
APM（Application Performance Monitoring）埋点是可观测性体系的基石。本章聚焦三个核心决策点：数据模型决定了“采集什么”，采样策略决定了“采集多少”，方案选型决定了“用谁的工具来采集”。理解这些前置知识，才能在后29章中正确埋点、搭建告警与Dashboard。
1.1 APM数据模型：四类信号
现代APM体系统一采用Metrics（指标）、Events（事件）、Logs（日志）、Traces（链路）四类信号。
| 信号类型 | 典型用途 | 采集方式 | 存储成本 |
|---|---|---|---|
| Metrics | CPU使用率、QPS、错误率、p99延迟 | 拉取（Prometheus）或推送（StatsD） | 低（聚合后存储） |
| Events | 版本发布、配置变更、OOM告警 | 主动打点（SDK或API） | 中（单条存储） |
| Logs | 错误堆栈、业务调试信息 | 标准输出 → 采集Agent | 高（按需保留索引） |
| Traces | 请求端到端链路、慢调用根因 | 代码埋点（OpenTelemetry SDK） | 极高（需采样控制） |
选型原则：生产环境优先保证 Metrics 和 Traces 的完整性，Logs 仅在关键错误时全量采集。使用结构化日志（如 JSON 格式）可降低解析成本。
1.2 采样策略：成本与可见性平衡
链路追踪（Traces）数据量极大，不采样会导致存储爆炸。常见采样策略如下：
| 策略 | 原理 | 适用场景 | 风险 |
|---|---|---|---|
| 头部采样 Head-based | 在请求入口按概率决定是否采样整条链路 | 低流量服务、全链路追踪要求不高 | 错失长尾/异常链路 |
| 尾部采样 Tail-based | 根据已收集的Span属性（如错误、慢）动态决策保留哪些完整链路 | 高流量生产环境，关注异常链路 | 需要集中式决策组件，复杂度高 |
| 概率采样 | 全局固定采样率（如10%） | 快速部署，无需动态决策 | 异常链路可能丢失 |
| 自适应采样 | 根据实时流量、错误率自动调整采样率 | 大规模微服务，需要动态平衡 | 实现复杂，需较成熟的可观测性数据平台 |
# OpenTelemetry 配置示例：概率采样（10%）
export OTEL_TRACES_SAMPLER=traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.1
经验之谈：头部采样设置过高（如100%）会导致存储成本激增；尾部采样虽能保证异常链路被保留，但依赖 span 处理延迟，不适合超低延迟场景。建议从10%概率采样起步，逐步过渡到尾部采样。
1.3 主流APM方案对比
当前社区与商业方案主要分为三类：厂商封闭型（Datadog, New Relic）、开源标准化（OpenTelemetry + Jaeger/Prometheus）、平台型（阿里云ARMS, AWS X-Ray）。以下是关键维度对比：
| 方案 | 数据模型 | 采样支持 | 部署成本 | 社区 / 生态 |
|---|---|---|---|---|
| OpenTelemetry + Jaeger + Prometheus | OTel协议，标准化Metrics/Logs/Traces | 头部/尾部/概率/自适应（需配合采样器） | 中（需自建后端） | ⭐️⭐️⭐️⭐️⭐️ (CNCF) |
| Datadog | 专有Agent，统一信号，支持自定义埋点 | 头部/尾部（付费特性） | 高（按数据量付费） | ⭐️⭐️⭐️⭐️ (商业 + 丰富) |
| 阿里云ARMS | 兼容OpenTelemetry，提供控制台 | 头部/自适应（平台侧配置） | 中（按节点 + 数据量） | ⭐️⭐️⭐️ (国内生态强) |
| SkyWalking | 自建协议，支持Metrics和Traces | 头部/尾部（需探针配置） | 低（单实例即可运行） | ⭐️⭐️⭐️⭐️ (亚洲社区活跃) |
课程选型偏好：本教程后续所有实践基于 OpenTelemetry（数据采集标准化）+ Prometheus（指标存储 & 告警）+ Jaeger（链路存储 & 查询）。此为开源社区最成熟、最灵活的组合，适合深度自定义。
1.4 APM埋点数据流整体框架
下图展示了一个典型APM埋点系统从应用侧采集信号，经过采样决策，最终写入存储与可视化层的完整流程：
SVG中节点颜色对应：蓝（应用）→ 绿（指标）、橙（链路）、紫（日志）→ 红（采样决策）→ 青（存储）。采样决策是成本控制的核心。
1.5 常见选型错误与避坑
- 错误1：直接对所有Traces使用100%采样率。纠正：根据服务QPS与存储容量设置采样率，高流量服务建议≤10%。
- 错误2：只采集Metrics而忽略Traces。纠正：Traces是根因分析的唯一依据，至少保留1%全量链路+100%错误链路。
- 错误3：使用厂商锁定方案后无法迁移。纠正：优先选择OpenTelemetry标准化协议，确保数据模型可移植。
- 错误4：日志不采样，导致存储成本失控。纠正：按日志等级（ERROR/WARN/INFO）设置保留策略，INFO按需采样。
# 生产环境推荐初始配置 (OpenTelemetry Collector)
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch:
timeout: 1s
probabilistic_sampler:
hash_seed: 42
sampling_percentage: 10.0
exporters:
jaeger:
endpoint: "jaeger-collector:14250"
tls:
insecure: true
prometheus:
endpoint: "0.0.0.0:8889"
service:
pipelines:
traces:
receivers: [otlp]
processors: [probabilistic_sampler, batch]
exporters: [jaeger]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]