什么是 OpenTelemetry？[您需要了解的一切]

发布: 3天前 (2026年2月23日 GMT+8 19:15)

13 分钟阅读

原文: Dev.to

Source: Dev.to

请提供您希望翻译的具体文本内容，我将按照要求保留源链接并将文本翻译成简体中文。

可观测性曾是一团碎片化的混乱

你为日志使用一个代理，为指标使用另一个库，还要使用专有的 SDK 来进行分布式追踪。
如果想要更换供应商，就必须从头重写你的仪表化代码。

OpenTelemetry（OTel）解决了这个问题。

它已成为 CNCF（云原生计算基金会）中仅次于 Kubernetes 的第二活跃项目。通过标准化应用程序生成和传输遥测数据的方式，OpenTelemetry 确保 你拥有自己的数据，而不是被供应商锁定。

本指南涵盖内容

什么是 OpenTelemetry
它的架构如何工作
为什么它现在是现代基础设施的默认选择

漫画: 解释 OTel 的强大功能（插图占位）

什么是 OpenTelemetry?

OpenTelemetry 是一个 开源可观测性框架，让您生成、收集和导出遥测数据（traces、metrics 和 logs）。

它不是存储后端或可视化工具。
相反，它充当您遥测数据的通用语言和传输系统。

把 OpenTelemetry 想象成管道：它从您的应用程序和基础设施收集数据，处理后将其传输到您选择的后端——无论是 SigNoz、Prometheus、Jaeger，还是其他系统。

History

成立于 2019 年，通过合并两个主要项目而形成：
- Google 的 OpenCensus
- CNCF 的 OpenTracing
目标：统一业界的单一仪器化标准。

可观测性的三大核心支柱

支柱	功能描述	示例
追踪	跟踪请求在分布式系统中的整个路径。一次追踪由跨度组成（例如，数据库查询或 HTTP 请求）。	显示问题发生位置。
指标	随时间测量的数值数据点（CPU 使用率、内存消耗、请求速率等）。	显示问题发生时间。
日志	带时间戳的文本记录，通常包含错误信息或状态更新。	显示问题发生原因。

使用 OTel 处理这三类数据可以让您自动关联它们。例如，您可以查看特定的追踪，并立即看到在同一时间段内生成的日志，它们共享相同的上下文标签。

供应商中立，即插即用

使用 OTel 时，不受单一供应商限制。
您可以轻松接入任意您选择的可观测性后端。
支持多种语言（Java、Python、Go 等）和平台，使其在不同开发环境中具有通用性。

Source: …

OpenTelemetry 框架

规范

OTel 的核心是它的规范——一套正式的指南，定义了遥测数据应如何生成、处理和导出。

保证 跨语言、跨工具、跨供应商的互操作性。
为可观测性数据提供一致的模型。

API 与 SDK

组件	目的	若缺失会怎样
API（接口）	用于给代码植入遥测的入口（创建 Span、记录指标的类和方法）。	如果只导入 API，实现会是 no‑op——代码可以运行，但不会产生任何数据。
SDK（实现）	负责处理数据：采样、资源属性（例如 `service.name`、`k8s.pod.name`）、批处理和导出。	实际的遥测发送需要它。

为什么要分离？

允许在开源库中嵌入原生仪表化代码，而不必引入沉重的依赖。
保持 API 轻量且安全，SDK 则可以包含更复杂的逻辑和可选依赖。
能在软件中内置可观测性，而不会对不需要它的用户产生运行时开销。

OTLP – OpenTelemetry 协议

OpenTelemetry 的 原生语言。
高效的协议，用于在 SDK → Collector 或 Collector → 后端之间传输数据。
支持 gRPC 和 HTTP 传输。
虽然 OTel 也可以使用 Zipkin 或 Jaeger 格式，但 OTLP 是推荐的默认选项，因为它在遥测传输上更高效。

OpenTelemetry Collector

一个 供应商无关的代理，位于应用程序和后端之间。可选，但在生产环境中强烈推荐使用。

三大主要职责

接收 – 接受多种格式的数据（OTLP、Jaeger、Prometheus 等）。
处理 – 清洗和修改数据（例如过滤健康检查的 trace、清除 PII、添加基础设施标签）。
导出 – 将数据同时发送到一个或多个后端。

Collector 可以以以下方式部署：

Agent – 在每台主机上运行的守护进程。
Gateway – 集中式服务。

语义约定

规范定义了 通用属性名称（例如 http.request.method、db.system），以确保跨组件和跨服务的一致性。这意味着无论是 Python 应用还是 Java 应用发起的数据库调用，都会使用相同的属性表示方式。

为什么 OpenTelemetry 是未来

模块化、可扩展且面向未来 – 只需一次埋点，后期可切换后端（SigNoz、Prometheus、Grafana、Datadog 等）。
供应商中立 – 让您始终掌控遥测数据。
生态系统广阔 – 强大的社区支持、丰富的语言库以及众多集成。

TL;DR

OpenTelemetry 将追踪、指标和日志标准化为单一数据流。
它的 API/SDK 分离、OTLP 协议 和 Collector 为您提供灵活性、性能和供应商独立性。
立即采用 OTel，让您的可观测性体系面向未来，避免被供应商锁定。

Source: …

OpenTelemetry 概览

OpenTelemetry（OTel）让我们 收集、处理并导出遥测数据。下面是管道的逐步视图。

Instrumentation（仪器化） – 使用 OpenTelemetry 的 API 告诉系统要测量什么（例如 HTTP 延迟、数据库查询、错误事件）。
SDK Collection（SDK 收集） – 应用程序中的 SDK 收集仪器化产生的数据并将其传输以供处理。
Collector Processing（Collector 处理） – OTel Collector 充当处理中心。在这里，遥测数据可以被：
- 采样
- 过滤以降低噪声
- 使用其他系统的元数据进行丰富
  此步骤为原始信号添加有价值的上下文。
Exporters（导出器） – 处理完后，数据会（如有必要）转换为观测后端期望的格式，并交给导出器，将数据送达目的地。
Backend Delivery（后端交付） – 在离开 Collector 之前，数据可能会进行批处理，然后路由到一个或多个后端（例如 SigNoz、其他云 APM 服务）。

结果： 一个从应用程序内部开始、在观测后端结束的遥测管道。

为什么选择 OpenTelemetry？

供应商无关的仪器化 – 使用标准 API 仪器化一次。切换供应商只需在 Collector 或 Exporter 中更改配置；应用代码保持不变。
标准化的上下文传播 – OTel 注入头信息（例如 W3C Trace Context），使跨语言边界的追踪（Go → Python 等）保持完整。
面向开发者的可观测性 – 各库现在自带原生 OTel 钩子，使用库时即可免费获得遥测数据。

权衡

关注点	细节
配置复杂度	Collector 极其灵活，这可能导致正确配置具有挑战性。需要谨慎管理采样率和内存限制。
版本成熟度	Tracing（追踪）在大多数语言中已稳定。Metrics（指标）在主要语言中已稳定，但在其他语言仍在演进。Logging（日志）是最新的信号，各 SDK 的成熟度不尽相同。

OTel 与现有工具对比

特性	OpenTelemetry	Prometheus	Jaeger
主要角色	遥测生成与收集	存储与查询（指标）	存储与可视化（追踪）
信号	追踪、指标、日志	仅指标（大多数情况下）	仅追踪
后端？	否（仅管道）	是	是

OTel 与 Prometheus – 互补。OTel 可以抓取指标并导出到 Prometheus，或者完全跳过抓取，直接将指标发送到支持 PromQL 的后端（例如 SigNoz）。
OTel 与 Jaeger – Jaeger 是用于存储/查看追踪的后端。OTel 是将数据发送到 Jaeger 的管道。Jaeger 客户端库已被 OpenTelemetry SDK 取代。

实现 OpenTelemetry

1. 为您的应用程序添加仪器

方法	描述
自动仪器（零代码）	将代理附加到正在运行的应用程序（例如 Java JAR 代理、Python 发行版）。自动捕获 HTTP 请求、数据库查询和标准指标。
手动仪器	导入 API 并自行创建 span，以监控自定义业务逻辑（例如 `process_payment()`、`calculate_inventory()`）。

2. 配置 OTel Collector

一个最小的 config.yaml：

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp:
    endpoint: "ingest.us.signoz.cloud:443"   # use your region
    headers:
      signoz-ingestion-key: "${SIGNOZ_INGESTION_KEY}"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

3. 将导出器指向后端

将处理后的数据发送到后端，例如 SigNoz 进行分析。

SigNoz – 一个 OpenTelemetry 原生的可观测性平台

SigNoz 从头开始构建，完全 OTel‑native。它作为后端和可视化层，充分利用 OTel 的语义约定。

最近的 OTel 原生特性

Trace Funnels – 智能采样和分析，聚焦最重要的追踪。
External API Monitoring – 对第三方 API 性能的可视化。
Out‑of‑the‑Box Messaging Queue Monitoring – 对流行消息队列系统的自动监控。

由 OTel 注入的应用收集的追踪在 SigNoz 中可视化。

部署选项

选项	描述
SigNoz Cloud	完全托管、可扩展的解决方案——非常适合希望避免运维负担的团队。
SigNoz Enterprise	自行托管（自带云或本地部署），提供专属支持和高级安全，适用于对数据驻留或隐私有严格要求的组织。

接下来怎么办？

现在您已经对 OpenTelemetry 有了基本了解，请尝试以下下一步操作：

使用 OpenTelemetry 为您的应用程序添加仪表
搭建 OpenTelemetry 演示应用
使用 OpenTelemetry 为您的基础设施添加仪表

这些步骤将帮助您构建更易于观察、调试和改进的系统。

Need More Help?

如果您对 What is OpenTelemetry 有进一步的问题，您可以：

使用 SigNoz AI chatbot
加入我们的 Slack community

您还可以 subscribe to our newsletter，获取 SigNoz 观测领域专家的洞见，以及直接发送到您收件箱的开源、OpenTelemetry 和开发工具构建故事。