OpenTelemetry 是什么？简单说，它是一个开源、厂商中立的可观测性标准和工具集，用于统一生成、收集、处理和导出指标、日志、链路追踪等遥测数据。它不替代 Prometheus、Jaeger、Grafana 或商业可观测性平台，而是让应用和基础设施用更标准的方式把数据送到这些后端。
如果您从事软件开发、SRE 或 DevOps 工作，您可能听说过可观测性、遥测和跟踪等术语。这些概念对于理解应用程序在生产环境中的行为至关重要，并且它们是现代软件开发实践的重要组成部分。
本文将介绍 OpenTelemetry 101：它是什么、它如何工作、为什么它对现代软件开发重要，以及团队应该如何开始落地。读完后，您应能区分 OpenTelemetry、遥测数据、Collector、SDK、Exporter 和后端系统各自解决的问题。
本文翻译自：https://www.dynatrace.com/news/blog/opentelemetry-101-guide-for-enthusiasts/
核心要点
- OpenTelemetry 的核心价值是统一遥测数据的生成、上下文传播、处理和导出方式。
- 遥测数据主要包括 Metrics（指标）、Logs（日志）和 Traces（链路追踪），它们分别回答性能趋势、事件细节和请求路径问题。
- OpenTelemetry Collector 是数据管道组件，可以接收、处理、过滤、采样并导出遥测数据。
- OpenTelemetry 的厂商中立性可以降低工具迁移和多后端集成成本，但它不会自动完成排障流程设计。
- 实施 OpenTelemetry 时，应先从关键服务和关键指标开始，再逐步扩展到更多语言、框架和数据类型。
什么是 OpenTelemetry？
OpenTelemetry 是一个开源可观测性项目，包含一组 API、SDK、库、代理、Collector 和埋点标准。使用 OpenTelemetry，开发人员可以收集和处理来自应用程序、服务和系统的遥测数据，并将这些数据导出到不同的可观测性后端。
为了理解这意味着什么，我们首先看一下两个核心概念：可观测性和遥测。
可观测性
可观测性是通过分析系统生成的数据（例如日志、指标和链路追踪）来理解系统运行状况和内部状态的能力。
与传统监控不同，传统监控通常侧重于观察系统运行状况的单个或少量指标；可观测性更强调把指标、日志、链路追踪和上下文放到同一个系统背景下分析，从而帮助团队理解“为什么异常发生”。
Telemetry 遥测
遥测涉及收集和分析来自分布式来源的数据，以深入了解系统的运行情况。遥测数据主要分为三种类型：
- 指标。跟踪系统随时间变化的性能和运行状况的定量测量。指标通常会聚合并存储在时间序列数据库中，以用于监控和警报目的。
- 日志。由应用程序和基础设施组件生成的基于文本的事件和活动记录。日志用于调试、故障排除和审核目的。
- 追踪。通过分布式系统的请求流的详细记录，包括计时信息和上下文数据。跟踪用于性能分析、延迟优化和根本原因分析。
这三类数据不是互相替代的关系。指标适合发现趋势和告警，日志适合查看事件细节，链路追踪适合理解一次请求跨服务流转时的调用路径和耗时分布。
OpenTelemetry 101
在此背景下，OpenTelemetry 的统一、平台无关 API、SDK、代理和埋点标准，允许开发人员以一致方式收集、处理和导出来自应用程序的遥测数据。开放遥测协议（OTLP）在此框架中发挥着关键作用，它标准化了系统格式化和传输遥测数据的方式，确保数据可互操作和高效传输。
这种标准化的意义在于：应用侧不必为每个后端重复埋点，平台侧可以把数据接入、加工、采样、路由和导出沉淀到统一管道里。
总体而言，OpenTelemetry 具有以下优势：
- 标准化数据收集。它通过提供用于收集、处理和导出指标、日志和跟踪的标准化工具和 API 来增强可观察性。
- 互操作性和供应商中立性。一组通用的 API 和数据格式可确保不同工具和平台之间的互操作性。这种互操作性使组织能够避免供应商锁定，并在多个可观察性工具之间切换或集成，而无需重新检测其应用程序。
- 增强上下文和相关性。它丰富了遥测数据的相关属性，有助于指标、日志和跟踪的关联，以全面了解系统行为。
- 与现有工具集成。它与现有的可观测性工具集成，增强数据收集和分析，同时提供标准化数据格式，以实现更深入的洞察并提高互操作性。例如，使用日志聚合工具的公司可以使用 OpenTelemetry 来获取额外的跟踪数据，而无需中断其设置，从而实现从遗留系统到现代可观测性的逐步平稳过渡。
- 面向未来的可观察性。它通过充满活力的社区的贡献和主要科技公司的支持不断发展，这确保了它与最新的行业标准、技术进步和最佳实践保持一致。
OpenTelemetry 组件
OpenTelemetry 由几个关键组件组成，包括 API、SDK、埋点库、Exporter 和 OpenTelemetry Collector。理解这些组件的边界，有助于避免把所有工作都误认为“装一个 Collector”。
追踪和埋点
OpenTelemetry 中的跟踪器跟踪应用程序不同部分的请求流，类似于跟踪包裹从一个邮政中心到另一个邮政中心。他们记录数据通过服务的过程，以帮助确定延迟或问题发生的位置。
埋点涉及向应用程序添加代码以收集跟踪信息，类似于在商店中安装安全摄像头以监控客户的移动和行为。根据应用程序的语言和框架，您将使用许多不同的埋点库。
跟踪器和埋点库都是收集和记录应用程序性能见解的重要组件。当跟踪主动记录并跟踪应用程序中的数据路径时，埋点库提供了必要代码，可以将这些跟踪器和其他遥测数据收集机制集成到应用程序中。
指标和日志
指标是衡量应用程序性能的数字数据点。将指标视为应用程序的生命体征，例如健康检查中的心率或血压。它们会告诉您有多少用户正在访问该服务、请求需要多长时间或应用程序使用了多少内存等信息。
日志是应用程序内发生的事件的详细记录。这类似于记日记，记下一天中的每一个重要事件。日志通过记录错误、事务和其他重要操作来为应用程序实现此目的。它们提供上下文和详细信息，帮助您在出现问题时诊断问题。
OpenTelemetry Collector
OpenTelemetry Collector 是一种集中式服务，用于收集应用程序的遥测数据（指标、日志和跟踪）。它就像一个邮政分拣中心，从不同的地方收集邮件，进行整理，然后将其发送到正确的目的地。收集器可以处理这些数据，过滤掉不必要的信息，并将有用的见解发送到各种监控和分析工具。
监控、可观测性领域的内容确实极为驳杂，如果想找靠谱的供应商来建设整套体系，欢迎和我们交流产品技术。我们专注在这个领域十年有余了。
OpenTelemetry 入门
OpenTelemetry 入门涉及为您的编程语言和运行环境安装适当的 SDK、埋点库或代理。OpenTelemetry 支持多种语言，包括 Java、Python、JavaScript 等，使其可供大多数应用程序使用。受支持的框架和语言的完整列表可以在 OpenTelemetry 注册表 中找到。
安装过程通常包括将 OpenTelemetry 依赖项添加到项目中并初始化 OpenTelemetry 软件开发工具包 (SDK)。 OpenTelemetry 网站提供每种语言的详细文档，指导您完成设置环境的必要步骤。
为您的应用程序配置 OpenTelemetry
安装库后，下一步是配置 OpenTelemetry 以从应用程序收集遥测数据。这涉及设置工具来捕获指标、日志和跟踪。您可以通过向应用程序添加特定代码片段来手动设置检测，也可以使用 OpenTelemetry 自动检测代理自动设置检测。
您还需要配置导出器，它确定 OpenTelemetry 将其收集的数据发送到何处进行分析。常见的导出器包括用于指标的 Prometheus、用于跟踪的 Jaeger 和用于日志的 Elasticsearch。配置文件或环境变量通常用于设置这些参数，从而可以轻松地根据您的特定需求调整设置。
根据您的使用案例，您可以自定义采样率、过滤规则和其他设置以优化数据收集和分析。 OpenTelemetry 提供了大量的文档和示例，可帮助您微调配置以实现最大效率。
对于刚开始接入的团队，建议先选一个关键服务，确认服务名、环境、版本、实例、trace_id、span_id 等基础属性稳定，再扩展到更多服务。否则后续即便数据采上来了，也可能因为字段不一致而难以关联。
实施 OpenTelemetry 的最佳实践
为了最大限度地发挥 OpenTelemetry 的优势，请遵循下面概述的最佳实践。
从小规模和渐进开始
从试点项目或单个服务开始，以验证您的设置并了解正在收集的数据。这种方法允许您测试和完善配置、管理实施复杂性并向利益相关者展示价值。
关注相关遥测数据
通过关注特定用例和问题，确保您收集正确类型的遥测数据以实现有效的可观察性：
- 确定关键指标。捕获关键性能指标，例如请求延迟、错误率和资源使用情况。
- 将数据置于情境中。向遥测数据添加相关上下文，例如服务名称、环境标签和自定义属性。
- 采用高效抽样。使用跟踪采样来管理数据量，而不会丢失重要的见解。
确保安全和数据隐私
为了避免通过遥测数据泄露敏感信息，您应该确保遥测数据在传输过程中和静态时使用 TLS 等协议进行加密。您还必须实施强大的访问控制，以限制谁可以查看和管理遥测数据，并在发送遥测数据之前对敏感信息进行匿名或编辑。这些做法不仅可以保护敏感信息，还可以保持对数据隐私法规的遵守。
实施高效的采样技术
实施有效的采样技术来管理数据量。例如，您可以使用跟踪采样来捕获具有代表性的跟踪子集，并收集足够的信息来有效地诊断问题。
源头聚合指标
通过在源处聚合指标来减少数据量和处理开销。在应用程序内或边缘聚合指标将最大限度地减少发送到可观察性后端的数据量。
利用现有工具
将 OpenTelemetry 与现有日志记录和跟踪工具集成，以增强您当前的监控基础设施。 OpenTelemetry 可以补充和扩展您现有的可观测性工具，以确保统一且有效的策略。
先定义排障路径
OpenTelemetry 解决的是数据生成、上下文传播和数据管道标准化问题。真正降低故障排查成本，还需要提前设计“指标告警如何跳到日志、日志如何跳到 Trace、Trace 如何回到服务对象和责任团队”。如果只接入数据，但入口仍然割裂，排障体验不会自动变好。
OpenTelemetry 用例
OpenTelemetry 有多个用例，包括：
- 分布式系统的监控和故障排除。 OpenTelemetry 通过捕获跨多个服务的请求的详细跟踪，提供分布式系统中的端到端可见性。例如，如果用户在电子商务应用程序中遇到响应时间缓慢的情况，OpenTelemetry 可以通过各种微服务跟踪请求，以查明导致延迟的服务。这种可视性简化了故障排除，并使 IT 团队能够快速识别和解决问题，从而最大限度地减少停机时间并提高系统可靠性。
- 性能优化。通过收集和分析指标和跟踪，OpenTelemetry 有助于识别系统效率低下的地方。例如，如果应用程序遇到高延迟，OpenTelemetry 可以显示特定数据库查询执行时间过长。这种数据驱动的方法使 IT 团队能够优化性能缓慢的组件，从而提高应用程序效率和用户体验。
- 与现有工具集成。 OpenTelemetry 与现有的可观测性工具无缝集成，将遥测数据导出到监控和分析平台。例如，使用 Prometheus 进行监控的组织可以合并 OpenTelemetry 来获取额外的跟踪数据，以丰富其可观测性策略。这种互操作性使组织能够利用全面的遥测数据增强其当前的监控基础设施，从而确保统一且有效的可观测性策略。
常见问题
OpenTelemetry 是监控系统吗？
不是。OpenTelemetry 更像一套遥测数据标准、SDK 和数据管道。它负责让应用和基础设施按统一方式产生、处理和导出数据；数据的长期存储、查询、告警和展示通常由 Prometheus、Jaeger、Loki、Tempo、Grafana 或商业可观测性平台承担。
OpenTelemetry 能替代 Prometheus 吗？
OpenTelemetry 不等价于 Prometheus。Prometheus 擅长指标抓取、时序存储和 PromQL 查询；OpenTelemetry 更强调多信号遥测数据的标准化、上下文传播和导出。很多团队会同时使用二者，例如通过 Collector 将指标导出到 Prometheus 或兼容后端。
为什么日志里要带 trace_id？
trace_id 能把某条日志和某次分布式请求关联起来。没有 trace_id，团队通常只能靠时间窗口、请求 ID 或人工经验在日志和 Trace 之间匹配；有了 trace_id，就能从错误日志跳到完整调用链，也能从慢 span 回到相关日志。
OpenTelemetry 的未来
OpenTelemetry 正在迅速发展，不断更新、增强，以及充满活力的开发人员和组织社区的贡献，更重要的是，它不断得到更广泛的采用。
了解 OpenTelemetry 最新动态的最佳方式是遵循该项目的公共路线图，其中概述了即将推出的功能、改进和计划。
也就是说，最令人兴奋的功能之一将是客户端检测项目，该项目将使开发人员能够真正了解其应用程序延迟和性能的端到端可见性。通过传统的监控和日志记录，您通常会获得应用程序性能的孤立视图，但这种开发将使您能够从浏览器交互一直到系统后端查看应用程序性能。
OpenTelemetry 101：灵活、可定制的遥测收集，可实现全面的可观测性
OpenTelemetry 是组织创建、收集和自定义指标、跟踪和日志的标准方法，以便更全面地了解系统行为。使用这种标准化的遥测数据方法，开发人员可以更好地观察其系统，并且可以通过持续分析系统行为并在异常问题出现之前识别异常来变得更加主动。
此外，由于 OpenTelemetry 是开源的，因此您可以避免供应商锁定。当开发人员创建新的工具和库时，这种供应商中立性使得 OpenTelemetry 能够面向未来。最重要的是，它是一种跨各种可观察性后端进行分析的有效方法。
总结
OpenTelemetry 是一个开源项目，旨在标准化遥测数据的生成、收集、处理和导出。通过提供 API、SDK、库、代理和 Collector，OpenTelemetry 使开发人员能够以更一致的方式收集来自应用程序、服务和系统的遥测数据。
它的价值不只是“多采一种数据”，而是让指标、日志和链路追踪拥有更一致的上下文，为跨工具、跨服务、跨团队的可观测性建设打基础。真正落地时，仍然要结合采样策略、字段规范、数据后端、权限治理和排障路径设计，才能把数据标准转化为工程效率。
