OpenTelemetry云原生全链路可观测标准

可视化演示

展示OTel分布式链路追踪、指标采集与日志聚合三大遥测信号，交互切换查看全链路可观测性。

背景定位：为什么需要统一标准

早晨，游乐城里的过山车突然停了十分钟。作为运营总监，你需要知道：排队区有多少人？游客有没有抱怨？过山车前后调用了哪些设备？可是小丑摊位、旋转木马、过山车各自用不同的表格记录，你要跑三个办公室才能拼出线索。云原生系统也一样——几十个微服务分散在不同容器、节点和云上，日志、指标、链路分别存在三套系统里，出了问题很难快速定位。

OpenTelemetry（简称 OTel）的出现，就是要解决这种“各记各账”的混乱。它由 OpenTracing 和 OpenCensus 两个项目合并而来，是 CNCF 孵化的云原生可观测性事实标准。它做的事情可以概括为：用一套统一的 API、SDK、协议和语义约定，采集日志（Logs）、指标（Metrics）、链路追踪（Traces），并通过统一的 Collector 管道送往后端。

在 OTel 之前，团队为了观察系统往往要同时接入 Prometheus、ELK、Jaeger 三套体系，埋点代码被三种 SDK 绑定，迁移成本很高。OTel 把“产生数据”与“数据去哪”解耦：应用只面向标准 API 埋点，由 Exporter 或 Collector 决定把数据发给谁。就算后端从 Jaeger 换成 Tempo，应用代码也不需要大改。这就是“一次埋点，随处对接”的含义。

回到游乐城，这相当于游管委统一发放了接线规范：每台设备上都保留统一的插口，后面接哪家档案室，则由中央调度室决定，而不是每个摊位自己各接一套线。

三支柱：日志、指标、链路

游乐城最想让运营者看到三类信息：游客留言簿记录某个时刻发生了什么；入口计数器每小时汇总入园人数；游客手环记录从入园到出园玩了哪些项目、在每个项目前等了多久。这三类信息刚好对应可观测性的三支柱：日志、指标、链路追踪。

日志是一条条离散的事件，适合记录错误堆栈、用户动作；指标是聚合后的数值，适合反映 CPU、QPS、延迟；链路追踪则把一次请求跨多个服务的完整路径串起来，回答“这个请求到底走了哪些路”。它们各有侧重，组合起来才能既看到树木，又看到森林。

在 OTel 中，三者通过统一的数据模型和语义约定对齐：日志里带 trace_id 和 span_id，就能跳转到对应的链路；链路由若干 Span 构成，Span 的属性又可以联动指标。不过，三支柱并不是三个独立系统，而是同一套管道里的三种信号。下面用一条公式说明指标最常见的用途——服务可用性：

所以不要只把日志、指标、链路当三个孤岛。它们就像留言簿、计数器、手环记录，虽然载体不同，但都描述同一批游客的经历；在 OTel 的标准里，三者的关联字段让它们能拼成一张完整的乐园体验地图。

核心架构：API、SDK、Exporter

为了给全园区设备统一装感应器，游管委规定每个摊位必须使用标准插头（API）、标准适配器（SDK）和标准传送带（Exporter）。无论摊位后面接什么系统，插头长得都一样。

OTel 的架构顶层是 API，它定义 Tracer、Meter、Logger 等接口；SDK 是实现这些接口的默认工具，负责生成 Span、累计指标、处理采样、管理 Context；Exporter 则负责把生成的数据序列化并发送出去。这种分层让应用可以不依赖任何具体后端。OTel 还为 Java、Python、Go 等主流语言提供自动埋点能力，借助 agent 或库的 instrumentation 自动为 HTTP、数据库等框架生成 Span，减少手动埋点工作量。

除 API/SDK 外，还有几个关键概念：Resource 用来描述数据来自哪个服务、版本、环境；语义约定（Semantic Conventions）规定属性命名，保证不同团队埋点能互相理解。典型的数据流是：应用调用 API → SDK 生成 Span/Metric/Log → Exporter 发送到 OTel Collector 或后端。

这就像每个摊位只要遵守标准插头，里面的电路怎么布置是摊位自己的事；如果以后要更换电表（后端），只需要在配电房改一下线路，不必把摊位重新装修一遍。

Collector管道：接收、处理、导出

游乐城的中央调度室是数据的“快递分拣中心”。摊位上报的数据先到这里，而不是直接冲向不同的档案室。调度室统一收货、分拣、打包，再按目的地把包裹送上不同的车。

在 OTel 中，这个调度室就是 Collector。它是一个独立进程，接收来自多个应用的 OTLP 或专有格式数据；它由 Pipeline（管道）定义处理流程，管道由三部分组成：Receiver 负责收包，Processor 负责加工，Exporter 负责发送。

Processor 可以做很多事情：批处理合并小数据包、过滤无用的属性、给数据打标、限流，以及最重要的——采样。面对海量链路，我们可以只保留一部分样本。比如每秒产生 10000 条链路，只保留 1000 条，那么采样比例就是：

调度室不是简单搬箱子，它可以根据目的地、数据量、敏感程度动态调整路线。正因为有了 Collector，应用侧可以保持轻量，复杂的数据治理都收拢到管道中完成。

上下文传播：让链路不迷路

想象一位游客在游乐城玩了“穿越魔法城堡”，城堡里的三个项目分别由三个摊位负责。如果每个摊位只记录自己的客流，管理处就无法知道他到底怎么从入口走到出口。要让路线完整，必须有一张游园卡，上面印着同一个游玩团体的暗号，每经过一个项目就盖一个章。

分布式链路追踪的“游园卡”就是 Trace Context。一个请求从服务 A 调用服务 B 时，上游会把当前 trace_id、span_id、采样标记等信息放进请求头，下游拿到后继续生成子 Span，从而把整条调用链串起来。OpenTelemetry 默认支持 W3C Trace Context 标准，在 HTTP 中通过 traceparent 头传递。

核心数据结构是 SpanContext，它包含 TraceId（全局唯一链路号）、SpanId（当前节点号）、TraceFlags（采样标记）和 TraceState（供应商扩展信息）。它们组合起来就是 traceparent 头的格式，可以写成：

除了 traceparent，OTel 还支持 Baggage 传递跨服务的业务属性（例如用户等级、页面来源），这些属性会以独立头部传递，帮助下游服务做出更精细的记录。有了这张标准游园卡，无论游客在魔法城堡里绕多少圈、经过多少摊位，只要每个摊位都按规则盖章，管理处就能在事后完整还原他的游玩路线。这就是上下文传播的意义——让分布式世界里散落的痕迹，重新长成一条完整的轨迹。

部署模式：Agent 与 Gateway

调度室该建在哪里？可以直接在每台设备旁边放一个小型收集箱，也可以在一个中心位置建大型调度总站，或者两者都建。游乐城会根据园区大小和每日游客量选择最合适的方案。

OTel Collector 有三种典型部署：Agent 模式——把 Collector 以 sidecar 或 DaemonSet 形式和应用跑在同一台机器上，数据近端采集，延迟低、资源消耗小；Gateway 模式——把 Collector 作为独立集群集中部署，所有 Agent 或应用直接把数据发给它，便于统一脱敏、过滤、聚合与鉴权；混合模式——边缘用 Agent 快速收数，中心用 Gateway 做二次治理，再导出到后端。

选择哪种模式通常看规模和合规要求。小型项目直接 Agent 连后端就够；大型或多集群环境则建议 Agent + Gateway，这样既能在边缘快速处理高频数据，又能在中心统一控制数据出网。混合模式也方便水平扩展：Gateway 可以根据后端压力动态扩容。

游乐城的管理也是这样：小园区可能两台收集箱就够，大型主题乐园则需要在每个片区设收集点，再统一汇总到中央控制室。部署模式没有银弹，只有适合当前规模的配置。

后端对接与生态：数据送往哪里

数据在中央调度室分拣后，要送去不同类型的档案室：人流量档案室看统计图，留言档案室看文字记录，游玩路线档案室看轨迹。每类档案室的存储格式不同，但只要数据已经标准化，送过去就只是换个车的问题。

OTel 的 Exporter 专门负责换车。指标数据可以导出到 Prometheus（通过 Remote Write），链路可以导出到 Jaeger、Tempo，日志可以导出到 ELK/Loki；而支持 OTLP 协议的后端，可以直接接收统一的三种信号。这意味着后端可以替换，埋点不需要重写。

在这个生态里，OTLP 是 OTel 自己的原生协议，传输效率高、支持三种信号；语义约定则保证无论数据去哪一种后端，字段含义都不会扭曲。常见的架构是：应用 SDK → OTLP → Collector → Prometheus/Jaeger/ELK。如果未来公司引入新的可观测平台，只需要调整 Collector 的 exporter 配置。

就像中央调度室知道哪类包裹送往哪个档案室一样，OTel 通过标准协议和 Exporter，让同一份游乐数据可以在不同档案室间自由流转，而不需要每个摊位重新填表。

AI 应用场景

Python 演示

import timeimport uuid  class TelemetryItem:    """Unified container for logs, metrics and traces."""     def __init__(self, kind, name, value=0.0):        self.kind = kind        self.name = name        self.value = value        self.trace_id = uuid.uuid4().hex[:16]        self.span_id = uuid.uuid4().hex[:16]        self.parent_id = ""        self.timestamp = time.time()     def inherit_context(self, parent):        self.trace_id = parent.trace_id        self.parent_id = parent.span_id     def __repr__(self):        return "{0}:{1}(value={2})".format(self.kind, self.name, self.value)  class CollectorPipeline:    """Simplified OpenTelemetry Collector: receive-process-export."""     def __init__(self, name):        self.name = name        self.queue = []        self.result = []     def receive(self, item):        self.queue.append(item)     def process(self, keep):        self.result = [item for item in self.queue if keep(item)]        return self     def export(self):        for item in self.result:            print("[{0}] export {1}".format(self.name, item))        self.queue.clear()        self.result.clear()  if __name__ == "__main__":    pipeline = CollectorPipeline("playground")    parent_span = TelemetryItem("trace", "GET /order", 42)    child_log = TelemetryItem("log", "user.login", 1)    child_log.inherit_context(parent_span)    metric = TelemetryItem("metric", "cpu_usage", 0.31)     pipeline.receive(parent_span)    pipeline.receive(child_log)    pipeline.receive(metric)    pipeline.process(lambda item: item.value >= 0.5 or item.kind == "log")    pipeline.export()

1. child_log.inherit_context(parent_span)把父 Span 的 trace_id 和 span_id 复制到日志里，模拟上下文传播。
2. self.result = [item for item in self.queue if keep(item)]对应 Collector 中 Processor 的过滤逻辑。
3. pipeline.process(lambda item: item.value >= 0.5 or item.kind == "log")只保留数值较大的请求或日志数据，模拟采样/过滤。
4. pipeline.export()对应 Exporter，把处理结果送往后端并清空队列。

常见误区

面试题