什么是 OpenTelemetry？
OpenTelemetry 是一个开源可观测性框架，提供统一的 API、SDK 和工具集，用于从分布式系统中生成、收集和导出遥测数据（链路追踪、指标和日志），帮助开发者监控和排查应用程序问题。
快速了解
| 全称 | OpenTelemetry 开源可观测性框架 |
|---|---|
| 创建时间 | OpenTelemetry 于 2019 年由 OpenTracing 和 OpenCensus 项目合并而成 |
| 规范文档 | 官方规范 |
工作原理
OpenTelemetry（OTel）是 CNCF 托管的厂商中立可观测性框架，用于插桩和传输 Trace、Metric 与 Log。API 和 SDK 生成遥测，上下文传播关联跨服务工作，Collector 负责接收、过滤、批处理、脱敏并导出到一个或多个后端。OpenTelemetry 不定义应用质量或授权，团队仍需维护业务事件、服务目标、隐私分类和评估契约。GenAI 语义约定位于独立仓库且仍处于 Development 阶段，因此 Agent、模型、Tool、Retrieval 与 MCP 属性应固定版本并按持续演进处理。信号边界和隐私控制见<a href="https://qubittool.com/zh/blog/agent-observability-engineering">Agent 可观测性工程指南</a>。
主要特点
- 厂商中立的遥测数据收集和导出标准
- 支持可观测性三大支柱：链路追踪、指标和日志
- 提供自动埋点和手动埋点两种方式
- 提供 Go、Java、Python、JavaScript、.NET 等语言的 SDK
- Collector 组件作为代理接收、处理和路由数据
- 上下文传播实现跨服务边界的分布式追踪
常见用途
- 分布式追踪：跟踪请求在微服务间的路径，识别延迟瓶颈
- 应用性能监控：收集响应时间、错误率和吞吐量等指标
- 日志关联：将日志与特定的链路和 Span 关联，实现上下文化调试
- 基础设施监控：从容器、主机和云服务收集系统级指标
- SLO 追踪：使用标准化遥测数据定义和监控服务级别目标
- 迁移灵活性：在不重新埋点的情况下切换可观测性后端
示例
Loading code...常见问题
OpenTelemetry 和 OpenTracing 有什么区别？
OpenTelemetry 是 OpenTracing（和 OpenCensus）的继任者。OpenTracing 只提供追踪 API 规范，而 OpenTelemetry 提供覆盖链路追踪、指标和日志的完整可观测性框架，包含完整的 SDK、自动埋点和 Collector 组件。OpenTracing 已归档，所有开发工作已转移到 OpenTelemetry。
OpenTelemetry 中可观测性的三大支柱是什么？
三大支柱是链路追踪（记录请求在分布式系统中的路径）、指标（随时间变化的系统行为数值度量，如延迟、错误率和吞吐量）和日志（带时间戳的离散事件文本记录）。OpenTelemetry 为三者提供统一的 API，并通过上下文传播将它们关联起来。
使用 OpenTelemetry 需要修改代码吗？
不一定。OpenTelemetry 为许多流行的框架和库（Express、Spring、Django 等）提供自动埋点，只需极少的代码改动——通常只需添加一个配置文件。对于自定义业务逻辑的埋点，则需要使用手动 API 在代码的特定位置创建 Span 和记录指标。
什么是 OpenTelemetry Collector？
Collector 是一个厂商无关的代理，用于接收遥测数据、处理数据（过滤、批处理、丰富）并将其导出到一个或多个后端。它将埋点与后端选择解耦，允许在不修改应用代码的情况下切换可观测性平台。可以作为 Sidecar、Daemon 或独立服务运行。
OpenTelemetry 可以用于生产环境吗？
生产就绪状态取决于具体信号、语言和组件，应核对当前 OpenTelemetry 规范、SDK 与 Collector 实现状态。核心信号可能稳定，而 GenAI 与 Agent 语义属性仍持续演进，因此需要固定版本并测试 Schema 变更。