OpenTelemetry 深度实战：可观测性的「世界语」如何用 OTLP + Collector 把 Metrics/Traces/Logs 收编进同一标准——从 SDK 埋点到生产级采样全链路拆解
如果你在 2026 年还在给每个监控系统写一套专属 SDK，或者因为换了一家 APM 厂商就要把全公司埋点翻一遍——这篇文章就是写给你的。OpenTelemetry（以下简称 OTel）已经不是「又一个监控框架」，它是可观测性领域的世界语：一套 API、一套 SDK、一套协议（OTLP），让你和后端存储彻底解耦。本文从三大信号的底层模型讲起，一路拆到 Collector 的架构、跨进程传播、生产级采样与 2026 年最热的 GenAI 可观测性，配可运行代码。
目录
- 背景介绍：可观测性的三支柱与厂商锁定之痛
- 核心概念：Signal、Span、OTLP 与语义约定
- 架构分析：SDK → OTLP → Collector → Backend 的数据流
- 代码实战：Python/Go 埋点、Collector 配置、GenAI 追踪
- 性能优化：采样、批处理、基数爆炸与内存护栏
- 总结展望：OTel 成为「世界语」之后
一、背景介绍：可观测性的三支柱与厂商锁定之痛
先说清楚一个词：可观测性（Observability）不是监控（Monitoring）换个好听的说法。监控回答「系统现在健康吗」，可观测性回答「系统为什么是这个状态」。它的理论根基来自控制论——如果一个系统的内部状态，可以仅凭它的外部输出推断出来，那它就是可观测的。
工程界把可观测性的外部输出归纳成 MELT（Metrics、Events、Logs、Traces），其中最常被提起的是三大支柱：
- Metrics（指标）：用数字描述系统的聚合状态，比如 QPS、P99 延迟、CPU 使用率。特点是低开销、适合做告警。
- Logs（日志）：离散事件的文本记录，信息最丰富，但成本和噪声也最高。
- Traces（链路）：一次请求穿越多个服务时的「调用树」，用来回答「这次慢请求到底卡在哪一跳」。
问题来了：2019 年以前，这三样东西各自为政。
链路领域有两个标准在打架：OpenTracing（偏 API 规范，由 Uber 等推动）和 OpenCensus（Google 出品，自带 SDK 和 Agent）。指标和日志更是每个厂商一套：Prometheus 有它自己的 client library，Jaeger 有它自己的 SDK，Datadog、New Relic、Elastic 各自发明轮子。结果就是——你的业务代码里写满了厂商专属的 import，换监控平台等于重写一遍埋点。这在微服务时代是灾难：一个公司有 200 个服务，迁移 APM 要改 200 个仓库。
2019 年，CNCF 把 OpenTracing 和 OpenCensus 合并，诞生了 OpenTelemetry。它的目标非常激进也很朴素：
定义一套与厂商无关的 API 和 SDK，让开发者只埋一次点，数据想发到哪家后端都行。
到 2026 年，OTel 已经是 CNCF 旗下发展最快的项目之一。Traces 与 Metrics 的 API 早在 1.0 阶段就达到了 stable，Logs 也在 2024 年进入 stable，**Profiles（持续性能剖析）**信号正在快速成熟，而 2026 年最热的方向之一，是用 OTel 统一 GenAI / LLM 应用的可观测性。换句话说，OTel 已经不是「可选方案」，而是事实上的行业标准。
本文要解决的，就是「知道 OTel 好，但不知道怎么落地到生产」这个 Gap。
二、核心概念：Signal、Span、OTLP 与语义约定
2.1 什么是 Signal
在 OTel 的术语里，Signal（信号） 是指一类遥测数据的统称。当前 OTel 正式支持的 Signal 有：
| Signal | 含义 | 稳定性（2026） |
|---|---|---|
| Traces | 分布式链路 | Stable |
| Metrics | 指标 | Stable |
| Logs | 日志 | Stable |
| Baggage | 跨服务透传的 KV baggage | Stable |
| Profiles | 持续性能剖析 | 快速演进中 |
一个常见的误区是「OTel 就是一个 SDK」。其实 OTel 包含三层东西：
- API：定义
Tracer、Meter等抽象接口，业务代码只依赖它。 - SDK：API 的实现，负责采样、批处理、导出。
- 协议 OTLP + Collector：数据怎么在网络上传输、怎么在中转层加工。
2.2 Trace / Span / Context
一条 Trace 是一次完整事务的链路，由一棵 Span 树组成。Span 是一次操作（比如一次 HTTP 调用、一次 DB 查询）的时间区间记录。
一个 Span 的关键字段：
trace_id：整条链路的唯一 IDspan_id：本 Span 的唯一 IDparent_span_id：父 Span 的 ID（根 Span 没有）name：操作名，如GET /checkoutkind：Span 类型，CLIENT/SERVER/PRODUCER/CONSUMER/INTERNALstart_time/end_timeattributes：结构化键值对（如http.method="GET"）events：Span 生命周期内的事件（带时间戳）status：成功 / 错误码links：与其它 Span 的关联（用于批处理、异步场景）
Context（上下文） 是 OTel 最精妙的设计之一。它把 SpanContext（含 trace_id/span_id）通过语言运行时的上下文（Python 的 contextvars、Go 的 context.Context、Java 的 ThreadLocal）传递下去，让你在任意函数里都能 tracer.start_span("xxx") 并且自动挂到当前链路上，而不用手动把 parent 传来传去。
2.3 W3C Trace Context：跨进程传播的基石
链路能串起来，靠的是传播（Propagation）。当请求从一个服务跳到下一个服务，必须把 trace_id 和 parent_span_id 塞进传输协议里带过去。OTel 默认使用 W3C Trace Context 标准，通过 traceparent 请求头传递：
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
│ │ │ │
版本 32位trace_id 16位parent_span_id trace标志位(01=sampled)
除了 traceparent，还有可选的 tracestate 头，用于多厂商透传各自的私有状态。OTel 提供 TextMapPropagator，可以注入到 HTTP header、Kafka message header、gRPC metadata 等任何载体。
2.4 Metrics 的四种同步 Instrument
指标模型比很多人想的要严谨。OTel 把指标 instruments 分为同步（在请求上下文中记录）和异步（通过回调周期性拉取）两大类：
同步 instruments（在业务代码里实时 Add/Record）：
Counter：只增不减的累加器，如请求总数。UpDownCounter：可增可减，如当前在线连接数。Histogram：记录数值分布（自动算分位数），如请求延迟。
异步 instruments（注册回调，被动上报）：
ObservableCounter/ObservableUpDownCounter/ObservableGauge：适合采集「进程已存在」的值，比如 GC 堆内存，你不想在每次分配时去 Add，而是让 SDK 定时回调读一次。
很多人把 Gauge 和 ObservableGauge 混用，记住：OTel 里没有名为 Gauge 的同步 instrument，你想表达「当前值」应该用异步的 ObservableGauge。
2.5 OTLP：OTel 的「普通话」
OTLP（OpenTelemetry Protocol） 是 OTel 原生的传输协议，基于 gRPC（默认端口 4317）和 HTTP/protobuf（默认端口 4318）。它用 protobuf 编码 Traces/Metrics/Logs，高效且强类型。
为什么不直接用 Prometheus 的拉模型或者 Jaeger 的 thrift？因为 OTLP 是推送 + 统一的：一个端口、一种编码，同时承载三种信号。这也是 OTel 能成为「世界语」的关键——前端应用只管往 Collector 推 OTLP，后面接 Jaeger、Prometheus、Grafana、ClickHouse、还是厂商云，那是 Collector 的事。
2.6 Semantic Conventions（语义约定）
这是 OTel 经常被忽视但极其重要的「隐藏标准」。它规定了 attribute 的标准命名，比如：
service.name、service.version、deployment.environmenthttp.method、http.route、http.status_codedb.system、db.statement、db.operationmessaging.system、messaging.destination
遵循语义约定，你的数据在不同后端之间就能直接复用仪表盘和告警规则。2024 年起，OTel 又推出了 Generative AI 语义约定，专门给 LLM 调用定义属性，比如 gen_ai.system="openai"、gen_ai.request.model、gen_ai.usage.prompt_tokens——这是 2026 年最值得关注的方向，本文第五节会实战。
三、架构分析：SDK → OTLP → Collector → Backend 的数据流
3.1 一条数据的完整旅程
┌──────────────┐ OTLP ┌─────────────────┐ OTLP / 其它 ┌──────────────┐
│ 你的应用 │ ───────▶ │ OTel Collector │ ─────────────▶ │ 后端存储 │
│ (SDK 埋点) │ │ (接收/处理/导出) │ │ Jaeger/Prom/ │
└──────────────┘ └─────────────────┘ │ ClickHouse… │
关键点：应用只和 Collector 说话，不直接和后端耦合。好处是：
- 换后端（从 Jaeger 切到 Tempo）只改 Collector 配置，不动业务代码。
- 后端不支持 OTLP？Collector 负责转换（比如把 metrics 转成 Prometheus 格式暴露）。
- 多个后端可以同时接收（一份数据 fan-out 给 Grafana 和厂商云）。
3.2 Collector 的四类组件
Collector 是 OTel 架构的中枢。它的处理单元按信号组织成 Pipeline（管道），每条 pipeline 由三类组件串联：Receiver → Processor(s) → Exporter。
Receiver（接收器）——数据的入口：
otlp：接收 OTLP（gRPC/HTTP），最常用prometheus：拉取 Prometheus 指标jaeger/zipkin：兼容旧链路协议hostmetrics：采集主机 CPU/内存/磁盘kafka：从 Kafka topic 消费
Processor（处理器）——加工与治理（最新 otelcol 已迭代到 v1.63.x，2026 年中）：
batch：把多条数据打包发送，省网络开销（务必开启）memory_limiter：内存护栏，防 OOM（务必第一个放）tail_sampling：尾部采样，根据整条链路结果决定保留（生产必备）attributes/resource：增删改 attributespanmetrics：从链路自动派生 RED 指标（请求数/错误/时延）probabilistic_sampler：概率采样
Exporter（导出器）——数据的出口：
otlp：转发给另一个 Collector 或云端prometheus：暴露/metrics给 Prometheus 拉logging：打印到标准输出（调试神器）clickhouse/kafka/ 各厂商 exporter
Extension（扩展）——不参与数据管道，提供辅助能力：
health_check：存活/就绪探针pprof/zpages：性能分析与内部可视化oauth2client：对外 exporter 做鉴权
3.3 部署模式：Agent 还是 Gateway？
生产环境通常是两级部署：
- Agent 级（边车 / DaemonSet）：每个节点或 Pod 一个轻量 Collector，负责接收本机应用的 OTLP、做
batch+memory_limiter、压缩后转发给网关级。好处是离应用近、失败域小。 - Gateway 级（中心）：集中式 Collector，负责
tail_sampling、attributes加工、再 fan-out 到多个后端。所有敏感的数据路由决策放在这里。
3.4 2026 年 Collector 的三个新动向
- 原生支持 MCP Server 暴露：2026 年 Q2 起，社区出现让 Collector 通过 MCP 协议把 PromQL 查询、K8s 诊断、日志检索暴露给 AI Agent 的方案，AIOps 开始和 OTel 打通。
- eBPF 持续剖析：
otel-profiling-agent（原 Elastic 贡献）能在零代码侵入的情况下，对 C/C++/Go/Rust/Python/Java/Node 做生产级 CPU profiling，作为 Profiles 信号进入 OTel 体系。 - Profiles 信号标准化：火焰图数据开始走 OTLP，和 traces/metrics 在 TraceID 维度关联，真正把「慢」和「为什么慢」对上。
四、代码实战
光说不练假把式。下面全部是可运行代码（基于 2026 年主线版本的 OTel SDK）。
4.1 Python 手动埋点：从 TracerProvider 到 Span
先装依赖：
pip install opentelemetry-api opentelemetry-sdk \
opentelemetry-exporter-otlp-proto-grpc
最核心的初始化：配置 TracerProvider，挂上 OTLP 导出器和批处理器。
# tracer_setup.py
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
# Resource 描述「这是哪个服务」，会被打在每个 Span 上
resource = Resource.create({
"service.name": "checkout-service",
"service.version": "1.4.2",
"deployment.environment": "production",
})
provider = TracerProvider(resource=resource)
# OTLP 导出器默认连 localhost:4317
otlp_exporter = OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True)
provider.add_span_processor(BatchSpanProcessor(otlp_exporter))
# 全局注册——之后任何地方 trace.get_tracer(__name__) 都能拿到
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("checkout.tracer")
注意一个生产级细节：一定要用 BatchSpanProcessor 而不是 SimpleSpanProcessor。后者每条 Span 都同步发，性能崩。前者攒一批再发，吞吐差一个数量级。
业务代码里创建 Span：
# business.py
from opentelemetry import trace
from opentelemetry.trace import Status, StatusCode
tracer = trace.get_tracer("checkout.tracer")
def create_order(user_id: int, items: list):
# start_as_current_span 会自动把新 Span 设为「当前」，子调用自动挂上来
with tracer.start_as_current_span("create_order") as span:
span.set_attribute("user.id", user_id)
span.set_attribute("order.item_count", len(items))
# event：Span 内某个时间点发生的事
span.add_event("inventory_locked", {"sku": items[0]["sku"]})
try:
total = _charge_payment(user_id, items) # 内部也会创建子 Span
span.set_attribute("order.total_cents", total)
except Exception as e:
# 标记错误，并附带异常
span.set_status(Status(StatusCode.ERROR, str(e)))
span.record_exception(e)
raise
return total
这里 with 块结束时 Span 自动 end()，异常也会带着 record_exception 进入后端，调试时你能在 Jaeger 里直接看到堆栈。
4.2 跨进程传播：让链路真正串起来
单进程埋点没用，关键是跨服务。假设 checkout-service 用 requests 调 payment-service：
# client.py
import requests
from opentelemetry import trace
from opentelemetry.propagate import inject
tracer = trace.get_tracer("checkout.tracer")
def call_payment(order_id: str):
headers = {}
# inject 会把当前 SpanContext 写进 headers（默认 W3C traceparent）
inject(headers)
with tracer.start_as_current_span("HTTP POST /pay", kind=trace.SpanKind.CLIENT) as span:
span.set_attribute("http.method", "POST")
span.set_attribute("http.url", "http://payment:8080/pay")
resp = requests.post("http://payment:8080/pay",
json={"order_id": order_id}, headers=headers)
span.set_attribute("http.status_code", resp.status_code)
return resp
payment-service 这一侧用 auto-instrumentation 或手动 extract：
# server.py (payment-service)
from opentelemetry.propagate import extract
def handle(request):
# extract 从入站 header 还原父 SpanContext，新 Span 自动成为子节点
ctx = extract(request.headers)
with tracer.start_as_current_span("order_payment", context=ctx):
...
这就是 W3C Trace Context 的威力——两边哪怕用不同语言、不同框架，只要都遵循 inject/extract，链路就能自动拼成树。
4.3 Go 埋点：Metric 与 Trace 双管齐下
Go 项目同样优雅。先初始化，再埋指标和链路：
// main.go
package main
import (
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
"go.opentelemetry.io/otel/sdk/resource"
sdktrace "go.opentelemetry.io/otel/sdk/trace"
"go.opentelemetry.io/otel/attribute"
"go.opentelemetry.io/otel/metric"
"context"
)
func initTracer() func(context.Context) error {
exp, _ := otlptracegrpc.New(context.Background())
tp := sdktrace.NewTracerProvider(
sdktrace.WithBatcher(exp),
sdktrace.WithResource(resource.Default()),
)
otel.SetTracerProvider(tp)
return tp.Shutdown
}
func main() {
shutdown := initTracer()
defer shutdown(context.Background())
meter := otel.Meter("payment.meter")
// 直方图：记录支付处理延迟分布
latency, _ := meter.Float64Histogram(
"payment.process.latency",
metric.WithDescription("payment latency in seconds"),
metric.WithUnit("s"),
)
tracer := otel.Tracer("payment.tracer")
ctx := context.Background()
_, span := tracer.Start(ctx, "process_payment")
defer span.End()
// 业务...
latency.Record(ctx, 0.137, metric.WithAttributes(
attribute.String("currency", "CNY"),
attribute.Bool("is_retry", false),
))
span.SetAttributes(attribute.String("payment.gateway", "stripe"))
}
几个 Go 专属的最佳实践：
WithBatcher等价于 Python 的BatchSpanProcessor，必开。- Go 的指标用
metric.WithAttributes打维度，维度数量（cardinality）要克制，否则后端存储爆炸——这点第五节细讲。 defer span.End()是 Go 里防止漏关 Span 的标准写法。
4.4 Collector 配置实战：一套配置吃遍后端
这是生产落地的核心。下面是一份 otel-collector-config.yaml，实现：接收 OTLP → 内存护栏 + 批处理 + 尾部采样 → 同时导出到 Jaeger（链路）、Prometheus（指标）、以及另一个 OTLP 网关（厂商云）。
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
# 内存护栏必须第一个，防 OOM
memory_limiter:
check_interval: 1s
limit_mib: 1500
spike_limit_mib: 500
batch:
timeout: 5s
send_batch_size: 1024
# 尾部采样：错误全留、慢请求全留、其余抽 10%
tail_sampling:
decision_wait: 10s
num_traces: 50000
policies:
- name: errors-policy
type: status_code
status_code: { status_codes: [ERROR] }
- name: slow-policy
type: latency
latency: { threshold_ms: 500 }
- name: rest-policy
type: probabilistic
probabilistic: { sampling_percentage: 10 }
exporters:
debug:
verbosity: detailed
otlp/jaeger:
endpoint: jaeger-collector:4317
insecure: true
prometheus:
endpoint: 0.0.0.0:8889
otlp/cloud:
endpoint: otel.gateway.internal:4317
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, tail_sampling]
exporters: [otlp/jaeger, otlp/cloud]
metrics:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [prometheus, otlp/cloud]
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [debug, otlp/cloud]
这份配置回答了一个经典问题：「怎么既不过滤掉该查的故障，又不让数据量爆仓？」 答案是尾部采样——等整条链路跑完，错误和慢请求 100% 保留，正常的只抽 10%。这比客户端头部采样聪明太多，因为客户端在请求刚开始时根本不知道它最后会不会报错。
4.5 自动埋点：一行命令零侵入
不是所有代码都值得手埋。OTel 提供自动埋点，无需改业务代码：
# Python：用 opentelemetry-instrument 包裹启动命令
pip install opentelemetry-instrumentation-flask \
opentelemetry-instrumentation-requests \
opentelemetry-instrumentation-sqlite3
opentelemetry-instrument \
--traces_exporter otlp \
--metrics_exporter otlp \
--service_name my-flask-app \
python app.py
它会自动给 Flask 路由、requests 调用、数据库查询套上 Span。生产建议：框架级调用用自动埋点（覆盖广），核心业务逻辑用手动埋点（带业务属性），两者结合性价比最高。
4.6 2026 新实战：用 GenAI 语义约定追踪 LLM 调用
这是 2026 年 OTel 最值得写一笔的能力。LLM 应用的可观测性和传统应用有本质不同：延迟是秒级甚至几十秒、错误是「语义错误（幻觉）」而非 HTTP 500、成本按 Token 计费。OTel 的 Generative AI 语义约定 专门定义了属性：
# llm_trace.py
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry import trace
import time, json
trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
BatchSpanProcessor(OTLPSpanExporter(insecure=True))
)
tracer = trace.get_tracer("llm.tracer")
def chat_with_model(prompt: str):
with tracer.start_as_current_span("gen_ai.client.chat") as span:
# —— GenAI 语义约定标准属性 ——
span.set_attribute("gen_ai.system", "openai") # 模型厂商
span.set_attribute("gen_ai.operation.name", "chat") # 操作类型
span.set_attribute("gen_ai.request.model", "qwen3.8-27b")
span.set_attribute("gen_ai.request.temperature", 0.7)
span.set_attribute("gen_ai.request.max_tokens", 1024)
span.set_attribute("gen_ai.prompt.tokens", 128) # 输入 token
# 把 prompt 作为 event，方便事后复盘（注意脱敏）
span.add_event("gen_ai.user.message", {"role": "user",
"content": prompt[:200]})
t0 = time.time()
# 伪代码：实际调用你的推理网关
resp = call_inference_gateway(prompt)
cost = time.time() - t0
span.set_attribute("gen_ai.response.model", "qwen3.8-27b")
span.set_attribute("gen_ai.usage.prompt_tokens", resp["usage"]["prompt_tokens"])
span.set_attribute("gen_ai.usage.completion_tokens", resp["usage"]["completion_tokens"])
span.set_attribute("gen_ai.response.finish_reasons", "stop")
span.set_attribute("llm.latency_seconds", round(cost, 3))
return resp
配合 2026 年成熟起来的 OTel GenAI 语义约定 + 持续剖析，你能在同一块 Grafana 面板上同时看到：一次聊天请求的总延迟、各阶段 Token 消耗、背后 GPU 的火焰图热点——这才是「AI 原生可观测性」该有的样子。
五、性能优化：采样、批处理、基数爆炸与内存护栏
埋点最怕两件事：拖慢业务 和 把后端存储打爆。下面四个杠杆是生产必调项。
5.1 采样：别把所有数据都存下来
头部采样（Head Sampling） 在客户端决定。默认 ParentBased(root=AlwaysOn) 表示：有父链路就跟随父决策，没父链路就全采。生产高流量服务应该改成按比例：
from opentelemetry.sdk.trace.sampling import TraceIdRatioBased, ParentBased
from opentelemetry.sdk.trace import TracerProvider
# 只采 20%，但保证父链路的一致性
provider = TracerProvider(
sampler=ParentBased(root=TraceIdRatioBased(0.2))
)
但头部采样有个致命缺陷：请求刚开始时你不知道它会不会失败，所以错误链路可能被采样掉。因此生产环境真正的利器是 Collector 的尾部采样（tail_sampling），也就是 4.4 配置里的那段——等链路完整了再决策。
5.2 批处理：把网络开销摊薄
batch processor 把多条 Span 打包成一个请求。send_batch_size 和 timeout 是调优点：批量太大延迟高，太小网络利用率低。经验值：
timeout: 5s：最多等 5 秒必须发出去（保证实时性）send_batch_size: 1024：攒够 1024 条就发（提高吞吐）
务必同时在客户端 SDK 用 BatchSpanProcessor，两边批处理叠加效果最佳。
5.3 基数爆炸：指标维度的隐形杀手
这是很多人踩过的坑。一个 Histogram 带了 user_id 当 dimension：
latency.Record(ctx, d, metric.WithAttributes(attribute.String("user_id", uid)))
后果是：每个不同用户生成一个独立的时间序列，后端（Prometheus/ClickHouse）瞬间多出几百万条序列，存储和查询全崩。这条铁律请刻在心里：
指标维度只放「低基数且有聚合意义」的标签（如
endpoint、status_code、region）；用户级、请求级的高基数 ID 只能放 Span 的attributes，绝不能放 metric 维度。
5.4 内存护栏：给 Collector 上保险
memory_limiter 必须放在 processor 链最前面。它周期性检查 Collector 自身内存，超阈值就丢弃新数据并强制 flush，避免进程被 OOM kill 导致全部数据丢失。参数经验值：
memory_limiter:
check_interval: 1s
limit_mib: 1500 # 硬上限，建议容器内存的 70%~80%
spike_limit_m... # 软上限，应对突发
5.5 成本与留存策略
生产级可观测性本质是成本工程：
- 原始 trace 保留 7~14 天，热数据用 SSD。
- 聚合指标（RED）长期保留 13 个月，用于趋势。
- 用 tail_sampling 把「正常链路」压到 5%~10%，「错误/慢链路」100% 保留——你查问题时最关心后者，前者只是凑数。
- Profiles 信号按服务粒度采样，别全量。
六、总结展望：OTel 成为「世界语」之后
回顾一下我们走过的路：
- 背景：厂商锁定让埋点成为迁移噩梦，OTel 用「一次埋点、任意后端」破局，三大信号 API 均已 stable。
- 核心：Signal 是数据分类；Span 是链路节点；W3C Trace Context 负责跨进程串链；OTLP 是统一传输协议；语义约定保证数据可移植。
- 架构：App → SDK → OTLP → Collector → Backend，应用只和 Collector 耦合，后端随意替换。
- 实战：Python/Go 手动埋点、自动埋点、Collector 三级 pipeline 配置、以及 2026 最热的 GenAI 语义约定追踪 LLM。
- 优化：头部+尾部采样、批处理、基数控制、内存护栏，四件事决定生产成败。
OTel 的意义，远不止「少写几行埋点」。它正在做一件当年 SQL 对数据库、HTTP 对网络做过的事——把可观测性变成一种通用协议。当所有语言、所有框架、所有后端都说同一套 OTLP「普通话」时，监控系统之间的切换成本趋近于零，AI Agent（正如 2026 年出现的 Collector-MCP 方案）也能直接「读懂」你的系统。
给准备落地的团队三条建议：
- 先 Collector 后后端：把 Collector 当作数据中转标准层先立起来，后端以后随便换。
- 自动埋点打底，手动埋点点睛：框架调用交给 instrument 自动包，核心业务手动加属性。
- 把 GenAI 可观测性提上日程：如果你的系统里已经有 LLM 调用，现在就用 gen_ai.* 语义约定埋点，等规模上来再补就晚了。
可观测性的终极目标，不是画漂亮图，而是让系统在出问题时「自己说清楚哪错了」。OpenTelemetry，就是这套自白能力的通用语法。
附录：最小可运行清单
# 1. 起一个本地 Collector（docker）
docker run -p 4317:4317 -p 4318:4318 \
otel/opentelemetry-collector-contrib:latest
# 2. 装 Python SDK
pip install opentelemetry-api opentelemetry-sdk \
opentelemetry-exporter-otlp-proto-grpc
# 3. 跑你的埋点脚本，数据即会进入 Collector
python your_app.py
本文所有代码示例均可在 Python 3.11+ / Go 1.22+ 与 OTel SDK 主线版本运行。生产环境请务必开启
BatchSpanProcessor与 Collector 的batch+memory_limiter+tail_sampling。