Go OpenTelemetry 埋点：对比各选项

在 Go 中向 SigNoz 发送 trace 有三种方式：在代码中引入 OpenTelemetry SDK、在构建二进制文件时注入插桩，或者给运行中的进程挂载 eBPF agent。本页对比这三种方案，帮你选一个上手。

方案对比

	OpenTelemetry SDK	编译时插桩	eBPF
工作原理	在代码中初始化 SDK 并包装各类库	otelc 在 go build 时注入插桩代码	独立的 agent 向运行中的进程挂载探针
是否需要改代码	是	否	否
是否需要重新构建	是	是	否
是否需要高权限	否	否	是，需要 root 和特权容器
操作系统	任意	任意	仅限 Linux
库支持范围	所有有 contrib 包的库	13 个常用库	4 个库
自定义 span	支持	通过 OpenTelemetry API	通过全局 tracer provider
支持的信号	Traces、metrics 和 logs	Traces 和 Go runtime metrics	Traces
项目状态	稳定	自 v1.0.0 起稳定	开发中

如何选择

如果你拥有代码且想要完全掌控，就从 OpenTelemetry SDK 开始。你可以自由选择要插桩的库、在自己的业务逻辑周围添加 span，并支持全部三种信号。代价只是几行初始化代码。

当你想在不修改源码的情况下生成追踪数据时，可以选用编译时插桩。只需在构建命令中加入 otelc，工具就会自动为它识别到的库添加插桩。若团队管理大量服务且希望获得统一的覆盖面，这是理想选择。

仅当无法重新编译二进制文件时，才选择eBPF 插桩。例如供应商提供的二进制文件或冻结发布的产物就适合这种场景。该代理需要运行在特权容器中，仅支持 Linux 系统，且 OpenTelemetry 项目仍将其标记为开发中状态。

混合环境下还有一种第四种选择

OpenTelemetry eBPF 插桩（OBI）在内核层面读取 HTTP、HTTPS 和 gRPC 流量，适用于任何语言编写的服务。当你希望用一个代理覆盖一堆非自研服务时，可以使用它。它能上报请求速率、错误率和延迟，但无法深入应用内部。

从这儿开始

OpenTelemetry SDK

使用 OpenTelemetry SDK 为 Go 代码插桩，并发送追踪、指标和日志

编译时插桩

通过 otelc 将插桩功能内置到二进制文件中，无需修改代码

eBPF 插桩

将代理附加到无法重新编译的运行中的 Go 二进制文件

手动插桩

围绕自定义业务逻辑添加自定义 span、属性和事件

组合多种方法

两种零代码方案都支持携带你自行编写的 span。

• 在使用编译时插桩时，OpenTelemetry API 的用法与常规一致。通过 otel.Tracer(...) 创建的 span 会自动融入注入的追踪链中。详见Go 手动插桩。
• 使用 eBPF agent 时，需设置 OTEL_GO_AUTO_GLOBAL=true。agent 随后将把应用发送至 OpenTelemetry global tracer provider 的 span 数据导出。

下一步

• 通过 Logrus、Zap 或 Zerolog 发送 Go 应用的日志。
• 基于 Go runtime metrics 创建仪表盘。
• 在 SigNoz 中仍未看到数据？请参考排查缺失的 traces、logs 和 metrics。

获取帮助

如果在本节的操作步骤中遇到困难，欢迎通过 SigNoz Community Slack 联系我们。如果你是 SigNoz Cloud 用户，请使用 SigNoz 实例右下角的内置聊天支持，或直接发送邮件至 cloud-support@signoz.io。