在前两篇文章中我们建立了可观测性的理论认知并了解了 LGTM 栈的整体架构。但在实际落地中最大的挑战不是“选什么后端”而是如何让应用产生可观测性数据以及如何让这些数据在不同工具之间拥有统一的含义。这正是 OpenTelemetry简称 OTel要解决的核心问题——它为可观测性数据定义了统一的 API、SDK 和语义约定让日志、指标、链路追踪拥有了“通用语言”。本文从 OTel 的诞生背景讲起系统讲解其核心组件、三大数据类型的采集与导出并通过一个 Go 微服务的完整实战带你从零到一掌握 OpenTelemetry 的使用。一、为什么需要 OpenTelemetry在 OTel 出现之前可观测性领域是一个“巴别塔”——Prometheus 有自己的指标格式Jaeger 有自己的 Trace 格式Elasticsearch 有自己的日志格式。每接入一个新的后端应用代码就需要重新插桩一次。更麻烦的是同一份数据在不同工具中的字段名可能完全不一样例如“服务名”在一个工具里叫 service_name在另一个工具里叫 app。OpenTelemetry 的统一价值它提供了一套供应商无关的标准包括统一的 API/SDK各语言使用相同的 API 进行插桩切换后端只需修改导出配置统一的协议OTLP 所有数据通过同一种协议传输统一的语义约定Semantic Conventions 确保字段名在不同服务、不同语言之间含义一致OTel 由 CNCF 托管是继 Kubernetes 之后 CNCF 最活跃的项目之一已成为可观测性领域的“通用语言”。二、OTel 的核心架构OpenTelemetry 的架构可以分为四个层次text应用代码 → OTel API → OTel SDK → OTel Collector → 可观测性后端OTel API定义插桩的接口创建 Span、记录指标等与具体实现解耦。使用 OTel API 插桩的代码可以在不同 SDK 实现之间切换。OTel SDKAPI 的具体实现负责数据的采样、处理和导出。SDK 包含三个主要组件Tracer Provider管理 Trace 的生成和导出Meter Provider管理 Metrics 的采集和导出Logger Provider管理 Logs 的采集和导出OTel Collector独立的数据管道服务负责接收、处理和导出遥测数据。Collector 有两大部署模式Agent 模式每个节点部署一个 Collector作为本地代理收集该节点上所有服务的数据Gateway 模式集中部署 Collector 集群作为数据聚合和路由的中心节点OTLPOpenTelemetry Protocol OTel 的原生数据传输协议支持 gRPC 和 HTTP 两种传输方式统一承载 Traces、Metrics、Logs 三种数据类型。三、OTel 的三大数据类型OpenTelemetry 统一支持三大可观测性数据类型Traces链路追踪 记录请求在分布式系统中的完整路径。每个 Trace 由多个 Span 组成每个 Span 代表一个操作单元。OTel 的 Trace 数据格式与 Jaeger、Zipkin 兼容。Metrics指标 系统运行状态的量化数据。OTel 的 Metrics API 支持 Counter、Gauge、Histogram 等标准指标类型数据可以导出到 Prometheus 或通过 OTLP 直接推送。Logs日志 结构化或非结构化的事件记录。OTel 的 Logs API 支持将日志与 Trace 关联通过注入 Trace ID 和 Span ID实现日志与追踪的无缝衔接。四、语义约定让数据“说同一种语言”语义约定Semantic Conventions是 OTel 中最容易被忽视但极其重要的部分。它定义了属性字段的标准命名确保不同服务产生的数据具有一致的含义。2025-2026 年的关键进展数据库语义约定于 2025 年 5 月正式稳定RPC 语义约定于 2025 年 6 月启动稳定化项目涵盖 gRPC、JSON-RPC、Apache Dubbo 等多种 RPC 技术Kubernetes 属性于 2026 年 3 月晋升为 Release Candidate 状态语义约定的价值当所有服务都遵循 http.method、http.status_code、db.statement 等统一命名时告警规则、仪表盘和查询语句可以跨服务复用而无需为每个服务单独配置。五、实战从零开始插桩一个 Go 微服务5.1 安装 OTel Go SDKgo get go.opentelemetry.io/otel\go.opentelemetry.io/otel/trace\go.opentelemetry.io/otel/sdk\go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc5.2 初始化 Tracer Providerpackagetracingimport(contexttimego.opentelemetry.io/otelgo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpcgo.opentelemetry.io/otel/sdk/resourcesdktracego.opentelemetry.io/otel/sdk/tracesemconvgo.opentelemetry.io/otel/semconv/v1.32.0)funcInitTracer(ctx context.Context,serviceNamestring)(*sdktrace.TracerProvider,error){// 1. 创建 OTLP gRPC Exporter发送到 Collector 或直接发送到 Tempoexporter,err:otlptracegrpc.New(ctx,otlptracegrpc.WithEndpoint(otel-collector:4317),otlptracegrpc.WithInsecure(),)iferr!nil{returnnil,err}// 2. 创建 Tracer Providertp:sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter,sdktrace.WithBatchTimeout(5*time.Second),),sdktrace.WithResource(resource.NewWithAttributes(semconv.SchemaURL,semconv.ServiceName(serviceName),)),sdktrace.WithSampler(sdktrace.AlwaysSample()),)// 3. 设置为全局 Tracer Providerotel.SetTracerProvider(tp)returntp,nil}5.3 创建自定义 Spanpackagemainimport(contextlognet/httpgo.opentelemetry.io/otelgo.opentelemetry.io/otel/attribute)funcmain(){ctx:context.Background()tp,_:tracing.InitTracer(ctx,order-service)defertp.Shutdown(ctx)http.HandleFunc(/order,func(w http.ResponseWriter,r*http.Request){tracer:otel.Tracer(order-service)ctx,span:tracer.Start(r.Context(),OrderService.CreateOrder,trace.WithAttributes(attribute.String(user_id,r.URL.Query().Get(user_id)),),)deferspan.End()// 业务逻辑...result:processOrder(ctx)w.Write([]byte(result))})log.Fatal(http.ListenAndServe(:8080,nil))}5.4 部署 OTel Collector在 Kubernetes 中以 DaemonSet 形式部署 CollectorapiVersion:v1kind:ConfigMapmetadata:name:otel-collector-confdata:config.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 memory_limiter: limit_mib: 512 spike_limit_mib: 128 exporters: otlp: endpoint: tempo:4317 tls: insecure: true service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, batch] exporters: [otlp]应用 Collector 配置后应用产生的 Trace 数据会通过 OTLP 协议发送到 Collector再由 Collector 转发到 Tempo 后端。六、零代码插桩eBPF 自动注入对于无法修改源码的场景OTel 支持通过 eBPF 自动插桩 实现零代码接入。从 OpenTelemetry Go v1.36.0 开始自动 SDK 作为标准 API 的间接依赖自动导入。eBPF 框架会自动插桩传入的 HTTP 请求并将手动 Span 链接到同一个 Trace 中。七、小结OpenTelemetry 是 CNCF 托管的可观测性统一标准提供供应商无关的 API、SDK 和语义约定OTel Collector 是数据管道中枢通过 Receivers、Processors、Exporters 三个组件接收、处理和导出遥测数据OTLP 协议 是 OTel 的原生数据传输协议统一承载 Traces、Metrics、Logs语义约定 确保不同服务产生的数据字段名一致2025 年数据库语义约定已稳定RPC 和 K8s 属性正在稳定化进程中实战要点使用 OTel SDK 进行手动插桩通过 OTLP 将数据发送到 Collector再转发到 LGTM 栈零代码插桩eBPF 自动注入支持在不修改源码的情况下采集遥测数据
在前两篇文章中我们建立了可观测性的理论认知并了解了 LGTM 栈的整体架构。但在实际落地中最大的挑战不是“选什么后端”而是如何让应用产生可观测性数据以及如何让这些数据在不同工具之间拥有统一的含义。这正是 OpenTelemetry简称 OTel要解决的核心问题——它为可观测性数据定义了统一的 API、SDK 和语义约定让日志、指标、链路追踪拥有了“通用语言”。本文从 OTel 的诞生背景讲起系统讲解其核心组件、三大数据类型的采集与导出并通过一个 Go 微服务的完整实战带你从零到一掌握 OpenTelemetry 的使用。一、为什么需要 OpenTelemetry在 OTel 出现之前可观测性领域是一个“巴别塔”——Prometheus 有自己的指标格式Jaeger 有自己的 Trace 格式Elasticsearch 有自己的日志格式。每接入一个新的后端应用代码就需要重新插桩一次。更麻烦的是同一份数据在不同工具中的字段名可能完全不一样例如“服务名”在一个工具里叫 service_name在另一个工具里叫 app。OpenTelemetry 的统一价值它提供了一套供应商无关的标准包括统一的 API/SDK各语言使用相同的 API 进行插桩切换后端只需修改导出配置统一的协议OTLP 所有数据通过同一种协议传输统一的语义约定Semantic Conventions 确保字段名在不同服务、不同语言之间含义一致OTel 由 CNCF 托管是继 Kubernetes 之后 CNCF 最活跃的项目之一已成为可观测性领域的“通用语言”。二、OTel 的核心架构OpenTelemetry 的架构可以分为四个层次text应用代码 → OTel API → OTel SDK → OTel Collector → 可观测性后端OTel API定义插桩的接口创建 Span、记录指标等与具体实现解耦。使用 OTel API 插桩的代码可以在不同 SDK 实现之间切换。OTel SDKAPI 的具体实现负责数据的采样、处理和导出。SDK 包含三个主要组件Tracer Provider管理 Trace 的生成和导出Meter Provider管理 Metrics 的采集和导出Logger Provider管理 Logs 的采集和导出OTel Collector独立的数据管道服务负责接收、处理和导出遥测数据。Collector 有两大部署模式Agent 模式每个节点部署一个 Collector作为本地代理收集该节点上所有服务的数据Gateway 模式集中部署 Collector 集群作为数据聚合和路由的中心节点OTLPOpenTelemetry Protocol OTel 的原生数据传输协议支持 gRPC 和 HTTP 两种传输方式统一承载 Traces、Metrics、Logs 三种数据类型。三、OTel 的三大数据类型OpenTelemetry 统一支持三大可观测性数据类型Traces链路追踪 记录请求在分布式系统中的完整路径。每个 Trace 由多个 Span 组成每个 Span 代表一个操作单元。OTel 的 Trace 数据格式与 Jaeger、Zipkin 兼容。Metrics指标 系统运行状态的量化数据。OTel 的 Metrics API 支持 Counter、Gauge、Histogram 等标准指标类型数据可以导出到 Prometheus 或通过 OTLP 直接推送。Logs日志 结构化或非结构化的事件记录。OTel 的 Logs API 支持将日志与 Trace 关联通过注入 Trace ID 和 Span ID实现日志与追踪的无缝衔接。四、语义约定让数据“说同一种语言”语义约定Semantic Conventions是 OTel 中最容易被忽视但极其重要的部分。它定义了属性字段的标准命名确保不同服务产生的数据具有一致的含义。2025-2026 年的关键进展数据库语义约定于 2025 年 5 月正式稳定RPC 语义约定于 2025 年 6 月启动稳定化项目涵盖 gRPC、JSON-RPC、Apache Dubbo 等多种 RPC 技术Kubernetes 属性于 2026 年 3 月晋升为 Release Candidate 状态语义约定的价值当所有服务都遵循 http.method、http.status_code、db.statement 等统一命名时告警规则、仪表盘和查询语句可以跨服务复用而无需为每个服务单独配置。五、实战从零开始插桩一个 Go 微服务5.1 安装 OTel Go SDKgo get go.opentelemetry.io/otel\go.opentelemetry.io/otel/trace\go.opentelemetry.io/otel/sdk\go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc5.2 初始化 Tracer Providerpackagetracingimport(contexttimego.opentelemetry.io/otelgo.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpcgo.opentelemetry.io/otel/sdk/resourcesdktracego.opentelemetry.io/otel/sdk/tracesemconvgo.opentelemetry.io/otel/semconv/v1.32.0)funcInitTracer(ctx context.Context,serviceNamestring)(*sdktrace.TracerProvider,error){// 1. 创建 OTLP gRPC Exporter发送到 Collector 或直接发送到 Tempoexporter,err:otlptracegrpc.New(ctx,otlptracegrpc.WithEndpoint(otel-collector:4317),otlptracegrpc.WithInsecure(),)iferr!nil{returnnil,err}// 2. 创建 Tracer Providertp:sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter,sdktrace.WithBatchTimeout(5*time.Second),),sdktrace.WithResource(resource.NewWithAttributes(semconv.SchemaURL,semconv.ServiceName(serviceName),)),sdktrace.WithSampler(sdktrace.AlwaysSample()),)// 3. 设置为全局 Tracer Providerotel.SetTracerProvider(tp)returntp,nil}5.3 创建自定义 Spanpackagemainimport(contextlognet/httpgo.opentelemetry.io/otelgo.opentelemetry.io/otel/attribute)funcmain(){ctx:context.Background()tp,_:tracing.InitTracer(ctx,order-service)defertp.Shutdown(ctx)http.HandleFunc(/order,func(w http.ResponseWriter,r*http.Request){tracer:otel.Tracer(order-service)ctx,span:tracer.Start(r.Context(),OrderService.CreateOrder,trace.WithAttributes(attribute.String(user_id,r.URL.Query().Get(user_id)),),)deferspan.End()// 业务逻辑...result:processOrder(ctx)w.Write([]byte(result))})log.Fatal(http.ListenAndServe(:8080,nil))}5.4 部署 OTel Collector在 Kubernetes 中以 DaemonSet 形式部署 CollectorapiVersion:v1kind:ConfigMapmetadata:name:otel-collector-confdata:config.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 memory_limiter: limit_mib: 512 spike_limit_mib: 128 exporters: otlp: endpoint: tempo:4317 tls: insecure: true service: pipelines: traces: receivers: [otlp] processors: [memory_limiter, batch] exporters: [otlp]应用 Collector 配置后应用产生的 Trace 数据会通过 OTLP 协议发送到 Collector再由 Collector 转发到 Tempo 后端。六、零代码插桩eBPF 自动注入对于无法修改源码的场景OTel 支持通过 eBPF 自动插桩 实现零代码接入。从 OpenTelemetry Go v1.36.0 开始自动 SDK 作为标准 API 的间接依赖自动导入。eBPF 框架会自动插桩传入的 HTTP 请求并将手动 Span 链接到同一个 Trace 中。七、小结OpenTelemetry 是 CNCF 托管的可观测性统一标准提供供应商无关的 API、SDK 和语义约定OTel Collector 是数据管道中枢通过 Receivers、Processors、Exporters 三个组件接收、处理和导出遥测数据OTLP 协议 是 OTel 的原生数据传输协议统一承载 Traces、Metrics、Logs语义约定 确保不同服务产生的数据字段名一致2025 年数据库语义约定已稳定RPC 和 K8s 属性正在稳定化进程中实战要点使用 OTel SDK 进行手动插桩通过 OTLP 将数据发送到 Collector再转发到 LGTM 栈零代码插桩eBPF 自动注入支持在不修改源码的情况下采集遥测数据
