OpenTelemetry 是一个开源的可观察性框架，用于生成、收集和导出来自应用和基础设施的遥测数据。它支持包括跟踪、指标和日志在内的重要可观察性信号。
现代应用通常跨越多个服务、容器、云平台、数据库和外部API。当某些东西失败时，单个服务器日志可能无法解释发生了什么。OpenTelemetry提供了常见的仪表化和遥测实践，帮助工程师理解这些组件的系统行为。
什么是 OpenTelemetry？
OpenTelemetry，通常缩写为OTel，是一个在云原生计算基金会下的供应商中立的可观察性项目。它为遥测工作流提供API、SDK、仪表化、语义约定、协议和OpenTelemetry Collector。
OpenTelemetry本身并不是一个完整的监控后端。相反，它帮助应用和基础设施生成和传输遥测数据到能够存储、分析、可视化和对这些数据进行警报的系统。
OpenTelemetry 支持哪些遥测？
追踪
跟踪代表请求在分布式系统中的路径。它可以显示请求如何从API网关通过应用服务、数据库、缓存和外部服务移动。
指标
指标是随时间收集的数值测量。示例包括请求计数、延迟、错误率、CPU利用率以及其他应用或基础设施的测量。
日志
日志是由应用和系统生成的带时间戳的事件记录。当与跟踪和指标正确关联时，日志可以在故障排除过程中提供额外的上下文。
为什么 OpenTelemetry 重要
没有共同的仪表化标准，组织可能会与个别的可观察性供应商紧密绑定，或维持不同应用的不同集成。
OpenTelemetry提供了一个通用框架，可以简化仪表化，并允许遥测被导出到兼容的后端。这可以给工程团队在设计可观察性架构时更多的灵活性。
OpenTelemetry 的工作原理
- 一个应用或基础设施组件生成遥测数据。
- OpenTelemetry API和SDK提供仪表化和遥测处理能力。
- 遥测可以由OpenTelemetry Collector或其他支持的组件进行处理。
- 遥测使用支持的协议和导出器进行导出。
- 观察性后端存储和分析结果数据。
这种架构将应用程序仪器化和遥测收集与最终存储和分析数据的系统分开。
OpenTelemetry 架构
API
OpenTelemetry API 定义了应用程序和库可以用来创建和交互遥测的接口。
SDK
SDK 提供语言特定的实现和配置，用于生成、处理和导出遥测。
仪器化
仪器化向应用程序添加遥测。这可以是手动的，即开发者自己添加仪器化，或者自动的，支持的库和框架在较少修改应用程序代码的情况下生成遥测。
OpenTelemetry Collector
OpenTelemetry Collector 是一个与供应商无关的组件，可以接收、处理和导出遥测。它可以靠近工作负载操作，或作为服务多个应用程序的网关。
什么是 OpenTelemetry Collector？
Collector 可以在应用程序和观察性后端之间集中遥测处理。它的管道可以接收遥测，应用处理如批处理或过滤，并将数据导出到选定的目标。
例如，一个组织可以使用 Collector 添加属性、过滤不需要的数据、控制批处理或将不同的遥测信号路由到不同的目的地。这可以减少应用程序服务内部的后端特定逻辑。
OpenTelemetry 与传统可观察性仪器化的比较
| 领域 | OpenTelemetry | 点集成 |
|---|---|---|
| 仪器化 | 常见 API、SDK 和约定 | 通常是特定于供应商的库或代理 |
| 遥测路由 | 可以使用 Collector 管道和标准化协议 | 可能直接将数据发送到特定后端 |
| 后端灵活性 | 旨在实现互操作性 | 可以创建更强的供应商耦合 |
| 分布式追踪 | 标准化追踪概念 | 实现因平台而异 |
使用 OpenTelemetry 的分布式追踪
分布式追踪对微服务尤其有用。单个请求可能跨越多个组件，使得识别延迟或错误的来源变得困难。
OpenTelemetry 使用跨度来表示追踪中的单个操作。相关的跨度可以显示服务间工作的顺序和持续时间。
当追踪上下文正确传播时，工程师可以跨越进程和网络边界跟随请求。
OpenTelemetry 与微服务
微服务通过 API、消息系统、数据库和其他协议进行通信。这种架构可以提供部署灵活性，但也可能使故障排除变得更加困难。
OpenTelemetry可以提供跨服务的一致遥测。共同的属性和追踪上下文可以帮助连接请求、操作和跨服务边界的故障。
OpenTelemetry 语义约定
语义约定定义了常见录制的遥测属性的标准名称和含义。一致的约定使遥测更易于查询和在应用程序及服务之间进行比较。
这些约定可以涵盖常见的技术和操作，例如HTTP、数据库、消息系统和服务资源。
自动与手动仪器化
自动化仪器化 可以生成支持的库和框架的遥测，只需相对较少的应用程序代码修改。这对于快速建立广泛覆盖很有用。
手动仪器化 让开发人员添加应用程序特定的跨度、指标和自动化仪器化可能不理解的属性。
许多成熟的可观察性实现同时使用这两种方法：对常见框架进行自动化仪器化，对重要的应用程序操作进行手动仪器化。
OpenTelemetry 的好处
- 供应商中立： 遥测可以导出到兼容的可观察性系统。
- 标准化： 共同的API和约定减少了分散的仪器化。
- 分布式追踪： 团队可以在多个服务中跟踪请求。
- 灵活的收集： 收集器可以处理和路由遥测。
- 开放生态系统： 该项目有广泛的社区和行业参与。
- 信号关联： 指标、日志和追踪可以提供更连贯的系统行为视图。
OpenTelemetry 与可观察性后端
OpenTelemetry不一定是用于分析遥测的数据库或仪表板。相反，遥测可以导出到兼容的后端。
在选择后端时，团队应评估存储、查询能力、报警、保留、成本、安全性和可视化。OpenTelemetry可以帮助将应用程序仪器化决策与后端选择分开。
性能和成本考虑
可观察性数据会消耗CPU、内存、网络带宽和存储。以最大详细程度收集每一个可能的事件可能会变得昂贵，并可能使重要信号更难识别。
团队应建立适当的采样、过滤、保留和属性政策。敏感信息也应根据安全和隐私要求被排除或保护。
OpenTelemetry安全与隐私
遥测可能包含敏感信息。请求属性、URLs、用户标识符、数据库语句和日志消息如果仪器化设计不当，可能会泄露机密信息。
- 审查收集哪些属性。
- 切勿将凭据或秘密放入遥测中。
- 对可观察性系统应用访问控制。
- 在适当的情况下保护传输中的遥测。
- 为遥测数据定义保留政策。
- 过滤或涂黑敏感值。
- 审查第三方导出器和后端集成。
如何开始使用OpenTelemetry
- 识别需要更好可观察性的应用程序和服务。
- 选择适当的OpenTelemetry语言SDK或仪器方法。
- 从高价值的服务和信号开始。
- 使用一致的资源属性和语义约定。
- 在集中处理有用时部署OpenTelemetry Collector。
- 将遥测导出到兼容的后端。
- 验证服务之间的跟踪上下文传播。
- 测量遥测的质量、数量、成本和实用性。
专家建议
- 从一些重要的服务开始，而不是一次性对所有服务进行仪器化。
- 使用一致的服务名称和资源属性。
- 将自动仪器化与定向手动仪器化相结合。
- 对高数量系统明智地使用跟踪采样。
- 保持敏感信息不出现在遥测中。
- Monitor the telemetry pipeline itself for dropped data and resource usage.
- Define retention and cost controls before telemetry volume grows significantly.
常见的OpenTelemetry错误
- Assuming OpenTelemetry is a complete observability backend.
- Collecting excessive telemetry without cost or retention controls.
- Using inconsistent service names and attributes.
- Ignoring trace-context propagation between services.
- Exposing sensitive information through logs or span attributes.
- Relying entirely on automatic instrumentation for application-specific behavior.
- Failing to monitor the Collector and telemetry pipeline.
常见问题解答
OpenTelemetry简单来说是什么？
OpenTelemetry is an open-source framework for generating, collecting, and exporting telemetry such as traces, metrics, and logs.
OpenTelemetry是监控工具吗？
OpenTelemetry is primarily an observability framework and telemetry ecosystem. It typically sends telemetry to another backend for storage, querying, visualization, and alerting.
OpenTelemetry的主要信号是什么？
The commonly used signals are traces, metrics, and logs. The project also has ecosystem support for related observability data as its capabilities evolve.
什么是OpenTelemetry Collector？
The Collector is a vendor-neutral component that can receive, process, and export telemetry between applications and observability backends.
OpenTelemetry取代Prometheus吗？
Not necessarily. OpenTelemetry and Prometheus have different architectures and roles, although their metrics capabilities can overlap. OpenTelemetry can collect and export metrics to compatible systems.
OpenTelemetry可以与Kubernetes一起使用吗？
Yes. OpenTelemetry can be deployed in Kubernetes environments to collect application and infrastructure telemetry, including through the OpenTelemetry Collector.
OpenTelemetry是供应商中立的吗？
Yes. Vendor neutrality and interoperability are central goals of the project, although the final backend and exporter choices still affect an organization’s architecture.
初学者应该学习OpenTelemetry吗？
It is useful for engineers working with distributed applications, cloud infrastructure, microservices, or modern observability. Beginners should first understand basic monitoring and telemetry concepts.
结论
OpenTelemetry provides a common foundation for instrumenting applications and collecting telemetry across modern distributed systems. Its APIs, SDKs, semantic conventions, and Collector can help teams build more consistent and portable observability pipelines.
The best results come from purposeful instrumentation. Teams should collect signals that answer operational questions, protect sensitive information, control telemetry costs, and connect metrics, logs, and traces into a coherent view of application behavior.
Continue the technology series: next is Application Observability, which focuses on understanding application health and behavior through telemetry and actionable operational insights.
