OpenTelemetry 深度实战：当可观测性终于有了统一标准——从三大信号模型、Collector 管线到 eBPF 零侵入采集的生产级完全指南

如果你凌晨三点被报警叫醒，打开 Grafana 看到 CPU 飙红、错误率上涨，却无法回答「到底是哪一次用户请求、走了哪条调用链、卡在了哪个下游依赖」，那么恭喜你，你踩中的正是「有监控、无可观测性」的经典困局。本文从工程视角讲透 OpenTelemetry（OTel）的信号模型、协议、架构与采集管线，配 Go/Python/Java 的手动与自动埋点、Collector 生产配置、eBPF 零侵入采集，以及尾部采样、基数治理与成本优化的完整方案。

一、背景介绍：从「监控」到「可观测性」

1.1 监控回答的是「已知问题」，可观测性回答的是「未知问题」

传统监控（Monitoring）的本质是预定义 dashboard：你事先想好了要盯哪些指标（CPU、QPS、错误率），系统把它们画成曲线。一旦线上出了问题，而你恰好没在 dashboard 上放对应的指标，就只能抓瞎。

可观测性（Observability）的定义来自控制论：一个系统如果是「可观测的」，那么仅通过观察它的外部输出（日志、指标、链路），就能推断其内部任意状态。换句话说，你不需要提前知道 bug 长什么样，也能在它发生后把它揪出来。

两者的差距在分布式系统里被无限放大。一个下单请求可能穿越网关、鉴权、库存、支付、履约 5 个服务，横跨 3 种语言、2 个 Kubernetes 集群。当支付超时，你需要的不是「支付服务错误率」这一条曲线，而是「这一次失败请求完整的调用轨迹」。

1.2 三大支柱曾经是三座孤岛

可观测性的「三大支柱」——链路追踪（Traces）、指标（Metrics）、日志（Logs）——在过去十年里各自独立演化，形成了三套互不相通的工具链：

• Traces：Jaeger、Zipkin 各搞一套私有协议与 SDK；
• Metrics：Prometheus 用 Pull 模型 + PromQL，业内却还有 StatsD、Graphite；
• Logs：ELK、Loki 各自定义日志格式。

结果是：同一个 trace_id 在 Jaeger 里能看到，在日志里却搜不到；同一个服务的名字在三个系统里叫三种写法。运维同学不得不在三个平台之间手动对账，可观测性沦为一句口号。

1.3 OpenTelemetry 是怎么统一的

2019 年，CNCF 把两个互相竞争的项目——OpenTracing（专注链路 API 标准）和 OpenCensus（Google 出品，含 metrics+traces+agent）合并，成立 OpenTelemetry。它的野心不是再做一个 APM 后端，而是做可观测性的「USB 接口」：

用统一的 API/SDK 采集遥测数据，用统一的 OTLP 协议传输，你爱导出到 Jaeger、Prometheus、Grafana、Datadog、阿里云还是字节内部平台，随你便。

2021 年 Traces 信号率先 GA，2023 年 Metrics GA，2024 年 Logs 信号也达到稳定性里程碑。到 2026 年，OTel 已经是 CNCF 发展速度仅次于 Kubernetes 的第二大项目，70% 以上的头部科技公司已在生产环境落地或迁移。换句话说，不会 OTel，等于不会给现代分布式系统装「行车记录仪」。

二、核心概念：先把「信号」「协议」「语义」这三个词嚼碎

2.1 Signal（信号）：不是三类数据，而是一个对象模型

OTel 把遥测数据抽象成若干「信号」。不要把它们理解成三种格式，而要理解成三种观察视角：

一个关键认知升级：三大支柱不是割裂的，而是用 trace_id / span_id / exemplar 串起来的。一条 log 可以带 trace_id；一个 metric 数据点可以通过 exemplar 关联到一个具体的 trace。这也是 OTel 区别于旧时代工具的本质。

2.2 OTLP：让数据「说同一种语言」

OTLP（OpenTelemetry Protocol） 是 OTel 定义的统一传输协议，基于 gRPC + Protobuf（默认端口 4317），也支持 HTTP/Protobuf（4318）。它的价值在于：

1. 一种协议承载三种信号，SDK 不用为 traces/metrics/logs 分别对接后端；
2. 二进制、紧凑、可演进，Protobuf schema 向后兼容，新增字段不影响旧 receiver；
3. 天然支持批处理与背压，Collector 之间用 OTLP 级联几乎零成本。

生产环境里，你的应用只管把数据用 OTLP 推给本机或集群内的 Collector，至于 Collector 再转发到哪里，应用完全不关心——这就是「采集与导出解耦」。

2.3 Semantic Conventions（语义约定）：别再自己发明属性名

早期各自埋点时，有人写 http_status，有人写 status_code，有人写 http.code。OTel 用语义约定把常用属性名标准化了，例如：

• service.name、service.version、deployment.environment
• http.method、http.route、http.status_code、url.full
• db.system、db.statement、db.operation
• error.type、error.message

标准化带来两个实打实的好处：后端能自动识别并渲染，比如 Jaeger 看到 http.route 就知道画路由维度；跨团队协作零沟通成本，A 团队埋的 user.id 和 B 团队埋的 user.id 天然能对上。

2.4 Context Propagation：链路之所以能「连起来」，靠的是它

分布式追踪最容易被忽视、却最关键的一环是上下文传播（Context Propagation）。一个请求从网关进入，经过服务 A 调服务 B，要让 B 的 span 挂在 A 的 trace 下面，必须沿着调用把 trace_id/span_id 传递下去。

OTel 默认使用 W3C Trace Context 标准，HTTP 场景下通过 traceparent 请求头传递，例如：

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

traceparent 的四段分别是：版本、trace-id、parent-span-id、trace-flags（是否采样）。除了 trace，OTel 还有 Baggage 机制，可以附加任意业务上下文（比如 user.tier=premium），沿链路透传，下游无需回查就能拿到。

踩坑提示：消息队列（Kafka/RabbitMQ）、gRPC 元数据、甚至定时任务，凡是「跨进程边界」的地方，都必须显式注入/提取上下文，否则链路就会「断」。下文代码实战会专门演示。

2.5 Resource 与 Scope：给数据打上「来自谁、由谁产生」

每条遥测数据都带两类元数据：

• Resource：描述「被观测的对象是谁」，如服务名、版本、主机、K8s namespace。通常由 SDK 在初始化时统一设置，全进程共享。
• Instrumentation Scope：描述「这段埋点代码是谁写的」，区分是你手写的 SDK 调用，还是自动埋点 agent 注入的。

这两层元数据让后端能精准过滤「生产环境 / checkout 服务 / v1.4.2 / 由 javaagent 产生」的数据，是做多维下钻的基础。

三、架构分析：API、SDK、Collector 三层，以及为什么 Collector 是心脏

3.1 三层结构

应用代码 ──(API/SDK 采集)──> Collector ──(OTLP/导出)──> 后端(Jaeger/Prometheus/...)
               自动埋点 agent ↗        ↘ 级联到上游 Collector

• API：语言无关的抽象接口（Tracer、Meter），你的代码只依赖它，不依赖具体实现。
• SDK：API 的官方实现，负责采样、批处理、资源组装、OTLP 编码。
• Collector：独立进程，接收（Receive）→ 处理（Process）→ 导出（Export），是整个体系的中枢。

把导出逻辑放在 Collector 而非 SDK 里，是 OTel 最聪明的设计：应用升级 SDK 不用动后端配置，换后端只需改 Collector 的 exporter，多语言服务共用一套管线。

3.2 自动埋点 vs 手动埋点

生产实践：自动埋点打底（框架/库/网络），手动埋点补关键业务路径。例如用 javaagent 自动拿到 HTTP 和 JDBC 的 span，再手动在「下单」函数里加一个 create_order span 并打上 order.amount、coupon.id。

3.3 Collector 的管线：Receivers → Processors → Exporters（+ Connectors）

Collector 的配置是一个 Pipeline，三段式：

• Receivers：数据入口，如 otlp（收 OTLP）、prometheus（拉 Prometheus 指标）、hostmetrics（采主机指标）。
• Processors：对数据做变换，常用：
  • batch：攒批发送，降低后端 QPS 压力（生产必开）；
  • resource：统一追加/修改资源属性（如注入 deployment.environment）；
  • tail_sampling：尾部采样，等整条 trace 收齐再决定是否保留（生产级关键）；
  • attributes / filter：脱敏、丢弃高基数标签。
• Exporters：数据出口，如 otlphttp（推到云端）、debug（打到 stdout 调试）、prometheus（暴露给 Prometheus 来拉）。
• Connectors（较新能力）：把一条管线的输出当另一条的输入，比如把 traces 里的指标派生出来。

3.4 部署拓扑：Agent 模式、Gateway 模式、混合模式

• Agent 模式：每个节点/Pod 里跑一个 Collector（DaemonSet），就近接收应用 OTLP，做批处理、限流后转发。优势是网络就近、故障隔离。
• Gateway 模式：集群边缘部署少量中心 Collector，统一对接后端、做尾部采样与鉴权。优势是配置集中、便于治理。
• 生产推荐混合模式：节点侧 Agent 做轻量批处理 + 重试，中心 Gateway 做尾部采样 + 多后端路由。Kubernetes 里就是 DaemonSet + Deployment 各一套 Collector。

3.5 发行版：otelcol-contrib 不是唯一选择

官方核心版（otelcol）只含核心组件；opentelemetry-collector-contrib 才是功能最全的社区发行版（含各种 receiver/exporter）。此外 Grafana 的 Alloy、各云厂商的定制版都兼容 OTLP。选型建议：先上 contrib 跑通，再按需要换更轻量的发行版。

四、代码实战：从「能跑」到「生产可用」

下面用 Go（手动埋点）、Python/Java（自动埋点）、Collector（管线）和 eBPF（零侵入）四个层次给出可落地代码。

4.1 Go 手动埋点：初始化 TracerProvider + 一个业务 Span

package main

import (
	"context"
	"log"
	"time"

	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/attribute"
	"go.opentelemetry.io/otel/codes"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
	"go.opentelemetry.io/otel/sdk/resource"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
	semconv "go.opentelemetry.io/otel/semconv/v1.26.0"
)

// newTracerProvider 初始化全局 TracerProvider，把 trace 通过 OTLP 推给 Collector
func newTracerProvider(ctx context.Context, endpoint string) (*sdktrace.TracerProvider, error) {
	exp, err := otlptracegrpc.New(ctx,
		otlptracegrpc.WithEndpoint(endpoint), // 例如 localhost:4317
		otlptracegrpc.WithInsecure(),         // 内网可简化，生产应走 TLS
	)
	if err != nil {
		return nil, err
	}

	res, err := resource.New(ctx,
		resource.WithAttributes(
			semconv.ServiceName("checkout-service"),
			semconv.ServiceVersion("1.4.2"),
			semconv.DeploymentEnvironment("production"),
		),
	)
	if err != nil {
		return nil, err
	}

	tp := sdktrace.NewTracerProvider(
		sdktrace.WithBatcher(exp),        // 批量导出，降低后端压力
		sdktrace.WithResource(res),
		sdktrace.WithSampler(sdktrace.AlwaysSample()), // 生产应换成尾部采样
	)
	otel.SetTracerProvider(tp)
	return tp, nil
}

在业务函数里创建 span，并记录属性、事件、错误：

func CreateOrder(ctx context.Context, orderID string, items int) error {
	tracer := otel.Tracer("github.com/shop/checkout")
	ctx, span := tracer.Start(ctx, "CreateOrder",
		trace.WithSpanKind(trace.SpanKindServer))
	defer span.End()

	// 业务属性：让这条 span 在后端可被精准过滤
	span.SetAttributes(
		attribute.String("order.id", orderID),
		attribute.Int("order.items", items),
	)

	// 关键节点打 event，等价于结构化日志锚点
	span.AddEvent("inventory_reserved",
		trace.WithAttributes(attribute.Int("reserved", items)))

	if err := chargePayment(ctx); err != nil {
		span.RecordError(err)                       // 记录异常
		span.SetStatus(codes.Error, "payment failed") // 标记 span 失败
		return err
	}
	return nil
}

经验法则：span 名称用稳定模板（如 CreateOrder），不要拼入 orderID 这类高基数值；高基数值放 attribute，否则后端会出现「span 名称爆炸」。

4.2 Go Metrics：计数器与直方图

func initMeter(ctx context.Context, endpoint string) (func(), error) {
	exp, err := otlpmetricgrpc.New(ctx,
		otlpmetricgrpc.WithEndpoint(endpoint),
		otlpmetricgrpc.WithInsecure())
	if err != nil {
		return nil, err
	}
	mp := metric.NewMeterProvider(metric.WithReader(metric.NewPeriodicReader(exp)))
	otel.SetMeterProvider(mp)

	meter := otel.Meter("checkout")
	requests, _ := meter.Int64Counter("checkout.requests.total",
		metric.WithDescription("下单请求总数"))
	duration, _ := meter.Float64Histogram("checkout.order.duration_ms",
		metric.WithUnit("ms"),
		metric.WithExplicitBucketBoundaries(10, 50, 100, 200, 500, 1000))

	// 在 handler 中
	start := time.Now()
	_ = CreateOrder(ctx, id, n)
	elapsed := float64(time.Since(start).Microseconds()) / 1000.0
	requests.Add(ctx, 1, metric.WithAttributes(attribute.String("result", "ok")))
	duration.Record(ctx, elapsed)
	return func() { _ = mp.Shutdown(ctx) }, nil
}

注意这里我们用 metric.WithAttributes 给计数器打维度。但维度字段必须低基数——千万不要把 user_id 当维度，那会瞬间制造百万级时间序列（见 5.3 基数治理）。

4.3 跨服务上下文传播：让链路不断

OTel 已经把 HTTP 传播封装好了。客户端只需给 http.Client 套一层 transport：

import "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"

client := &http.Client{
	Transport: otelhttp.NewTransport(http.DefaultTransport), // 自动注入 traceparent
}
req, _ := http.NewRequestWithContext(ctx, "GET", "http://inventory:8080/reserve", nil)
resp, err := client.Do(req) // ctx 里的 span 上下文被自动带过去

服务端用 otelhttp.NewHandler 包裹 mux，自动从请求头提取上下文并开启 server span。对于非 HTTP 边界（如 Kafka），要手动注入/提取：

import "go.opentelemetry.io/otel/propagation"

// 生产者：把 ctx 里的上下文写进消息头
carrier := propagation.MapCarrier{}
otel.GetTextMapPropagator().Inject(ctx, carrier)
msg.Headers = mapToKafkaHeaders(carrier) // carrier["traceparent"] 等

// 消费者：从消息头还原 ctx，新 span 自动挂到原 trace 下
carrier = headersToMapCarrier(msg.Headers)
ctx := otel.GetTextMapPropagator().Extract(context.Background(), carrier)

4.4 Python 自动埋点：一行命令接入

Python 生态的自动埋点体验极佳。装好 distro 后，用 opentelemetry-instrument 包裹启动命令即可，零改码：

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install      # 自动装上 Flask/Requests/SQLAlchemy 等插桩

export OTEL_SERVICE_NAME=checkout
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317
export OTEL_TRACES_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
opentelemetry-instrument python app.py

如果你还想加业务语义，可手动补一段：

from opentelemetry import trace
tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("create_order") as span:
    span.set_attribute("order.id", order_id)
    span.set_attribute("order.items", len(items))
    # do work ...

4.5 Java 自动埋点：javaagent 字节码注入

Java 是自动埋点最成熟的语言，靠 -javaagent 在类加载期织入，连重启都不用改业务代码：

java -javaagent:/opt/opentelemetry-javaagent.jar \
     -Dotel.service.name=checkout \
     -Dotel.exporter.otlp.endpoint=http://collector:4317 \
     -Dotel.instrumentation.spring-webmvc.enabled=true \
     -Dotel.instrumentation.jdbc.enabled=true \
     -jar checkout.jar

javaagent 会自动为 Spring MVC、JDBC、Kafka、Redis、OkHttp 等生成 span，并注入 traceparent。业务侧如需自定义，用 GlobalOpenTelemetry 拿 tracer 即可：

import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.GlobalOpenTelemetry;

Tracer tracer = GlobalOpenTelemetry.getTracer("checkout");
Span span = tracer.spanBuilder("createOrder").startSpan();
try (var __ = span.makeCurrent()) {
    span.setAttribute("order.id", orderId);
    // business logic
} finally {
    span.end();
}

4.6 Collector 生产配置：尾部采样 + 批处理 + 多后端

下面这份配置是生产可参照的骨架：先用 tail_sampling 等整条 trace 收齐，只保留「出错」或「慢」或「兜底抽样」的；再 batch 攒批；最后导出到云端 OTLP 后端。

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

processors:
  batch:
    timeout: 5s
    send_batch_size: 8192
    send_batch_max_size: 16384
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert
  # 尾部采样：等整条 trace 的 span 都到齐后再决策
  tail_sampling:
    decision_wait: 10s          # 最多等 10s 收齐一条 trace
    num_traces: 50000           # 内存中并行跟踪的 trace 上限
    policies:
      - name: keep_errors        # 任何 ERROR 的 trace 全留
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: keep_slow          # 超过 500ms 的 trace 全留
        type: latency
        latency:
          threshold_ms: 500
      - name: baseline            # 其余随机留 10%，保证有统计样本
        type: probabilistic
        probabilistic:
          sampling_percentage: 10

exporters:
  otlphttp:
    endpoint: https://otlp.your-backend.com
    headers:
      authorization: "Bearer ${env:OTEL_TOKEN}"
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling, resource, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlphttp]

顺序很重要：tail_sampling 必须放在 batch 之前（它要看到未批处理的完整 span 才能决策）；resource 一般放在 batch 前统一打标。

4.7 eBPF 零侵入采集：不改一行业务代码拿画像与网络指标

自动埋点仍需语言 SDK 或 agent；而 eBPF 把侵入降到零——它直接在内核态观测进程的系统调用与 CPU 堆栈，连重启都不需要。OTel 体系里有两条现实路径：

（1）OpenTelemetry eBPF Profiler（持续性能剖析）
由 OTel 维护的 eBPF profiler 能在生产环境以极低开销（通常 < 1% CPU）持续采样所有进程的 on-CPU 堆栈，直接产出 OTel 的 Profiles 信号。它不依赖语言、不依赖符号表，C/Go/Rust/Java 通吃：

# 以 DaemonSet 跑在节点上，自动采集本机所有进程火焰图
OTEL_EBPF_PROFILER=1 \
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317 \
./otelcol-ebpf-profiler

（2）Grafana Beyla：用 eBPF 自动出 RED 指标 + 链路
Beyla 监听内核的网络与运行时事件，自动为 Go/Rust/Java/.NET 服务推导出 Rate/Errors/Duration 指标和 trace span，零代码改动：

# beyla-config.yaml
exporters:
  otlp:
    endpoint: collector:4317
discovery:
  services:
    - name: checkout
      executable: /app/checkout   # 匹配进程名即可，无需改代码

eBPF 的意义在于：它补全了 OTel 在「无 SDK 语言 / 遗留系统 / 第三方二进制」场景下的空白，让「一次埋点、全栈可见」真正成立。

五、性能优化与成本治理：生产落地的真正分水岭

很多团队 OTel 跑不起来，不是因为不会埋点，而是栽在「数据量爆炸、账单爆炸、查询卡死」。这一节讲四个关键杠杆。

5.1 采样策略：头部采样 vs 尾部采样

• 头部采样（Head Sampling）：在 span 创建的那一刻就决定是否采集（如 AlwaysSample 或概率 10%）。缺点：它不知道这条 trace 最后是成功还是失败，可能把最有价值的错误 trace 漏掉。
• 尾部采样（Tail Sampling）：等一条 trace 的所有 span 收齐、知道最终结果后再决策。配合 tail_sampling processor，可以「错误全留 + 慢请求全留 + 正常请求抽样」。这是生产环境唯一合理的做法。

头部采样适合「从源头就压低量」的极端省钱场景；尾部采样适合「保住有价值数据」的排障场景。两者可叠加：源头先按 50% 头部采样，Collector 再尾部精选。

5.2 批处理与导出调优

batch processor 是性能命脉：

• send_batch_size：攒够多少条发一次，建议 8192~16384；
• timeout：最多等多久发一次，建议 5s（延迟与吞吐的折中）；
• 太小 → 请求数爆炸、后端被打挂；太大 → 内存占用高、故障时丢数据多。

导出端务必开 重试 + 队列：OTLP exporter 内置退避重试，配合 Collector 的 queued_retry 思路（用内存/文件队列缓冲），避免后端抖动时数据丢失。

5.3 基数治理：别让一个 attribute 干掉整个后端

基数（Cardinality）= 一个时间序列/标签可能取的不同值的数量。这是 OTel 落地最隐蔽的坑：

• http.route=/checkout、http.status_code=200——低基数，安全；
• user.id=12345、trace_id=abc——高基数，绝对不能当 metric 维度。

一旦把 user.id 设为 metric 维度，10 万用户 = 10 万个时间序列，Prometheus/TSDB 直接 OOM。治理手段：

1. metric 维度只用低基数业务键（result、region、http.route）；
2. 高基数信息放 span attribute 或 log，让它在 trace 侧被检索，而不是在 metric 侧被聚合；
3. 用 filter / attributes processor 在 Collector 端丢弃或哈希化高风险标签；
4. 给 metric 名称加 _total、直方图加单位，遵循语义约定，避免重复造轮子。

5.4 Exemplars：把 Metrics 和 Traces 缝起来

直方图（Histogram）默认只给「P99 延迟 800ms」这个结论，但是哪次请求这么慢？ Exemplar 就是答案：OTel 在直方图桶里附带一个真实 trace 的 trace_id，让你点开指标就能跳到那条具体的慢 trace。配置上，只要后端支持（如 Prometheus + Grafana Tempo），OTel SDK 会默认在直方图上挂 exemplar，无需额外代码。

5.5 成本测算：采样到底省多少

假设一个服务 1 万 QPS，平均每次请求产生 5 个 span，每个 span 约 500 字节：

• 全量：1e4 × 5 × 500 B = 25 MB/s ≈ 2.16 TB/天；
• 尾部采样（错误全留 + 慢请求全留 + 正常 5%）：实际保留约 5%8%，约 **110170 GB/天**。

仅这一项，月度存储与传输费用就能从五位数降到三位数。再叠加 eBPF profiler 的持续剖析（只采 on-CPU 样本，开销 < 1%），整体可观测性成本完全可控。

六、总结与展望：可观测性的下一站

6.1 从「三大支柱」到「统一信号模型」

OTel 的终局不是「三个互不相关的 API」，而是一套统一的信号模型：traces、metrics、logs 共享 Resource/Scope 元数据，用 trace_id/span_id/exemplar 互链。2024 年 Logs 信号稳定后，三柱终于在同一套 SDK 里闭环。下一步是 Profiles（持续性能剖析） 作为第四种信号并入——你能在一条 trace 里直接看到它 CPU 时间花在了哪个函数，从「知道慢」跨越到「知道为什么慢」。

6.2 可观测性即代码（Observability as Code）

Collector 的 Pipeline 已经完全声明式（YAML），可以进 Git 做版本管理与 CI 校验。未来趋势是：采样策略、告警、SLO 全部代码化，和环境一起被 Review、被回滚。这跟 IaC 是同一套工程纪律。

6.3 给团队的上手路线图

不要一上来就「三柱全上」，按价值梯度推进：

1. 先上 Traces：用 javaagent / opentelemetry-instrument 自动埋点，半天接入，立刻能看调用链；
2. 再上 Metrics：关键 RED 指标（Rate/Errors/Duration）+ 业务计数器；
3. 然后 Logs 关联：让日志带 trace_id，从 trace 跳日志；
4. 最后上 Profiles：用 eBPF profiler 做持续性能剖析，定位热点；
5. 全程尾部采样 + 基数治理：否则前面白干。

6.4 常见误区

• ❌「有 Prometheus 就够了」——Prometheus 只是 metrics 后端，OTel 是采集与传输标准，二者互补不冲突；
• ❌「把所有东西都采样 100%」——先问问你的账单；
• ❌「span 名称里拼 ID 方便查」——那会制造百万级 span 名，正确做法是放 attribute；
• ❌ 「eBPF 能替代手动埋点」——eBPF 擅长运行时与网络，业务语义（订单金额、优惠 ID）仍靠手动埋点。

写在最后：OpenTelemetry 不是又一个要学习的「框架」，而是现代分布式系统的可观测性底座。它把你从「三套工具对账」里解放出来，让「一次埋点、任意后端、全栈可见」成为默认能力。2026 年，不会 OTel 的工程师，就像 2016 年不会容器的工程师——不是不能干活，而是总在别人已经自动化的地方手动挣扎。把这套方法论落地，下一次凌晨三点的报警，你点开的就是一条直达根因的 trace，而不是一片红色的空白 dashboard。

相关参考实践

• CNCF OpenTelemetry 官方文档与 Semantic Conventions
• OpenTelemetry Collector Contrib 发行版 Pipeline 配置
• W3C Trace Context（traceparent / tracestate）规范
• OpenTelemetry eBPF Profiler 与 Grafana Beyla 零侵入采集
• 尾部采样策略（status_code / latency / probabilistic）生产配置范式