什么是 OpenTelemetry？

OpenTelemetry 定义

OpenTelemetry (OTel) 是一个开源可观测性框架，允许开发团队以单一、统一的格式生成、处理和传输遥测数据（telemetry data） 。它由云原生计算基金会 (CNCF) 开发，旨在提供标准化协议和工具，用于收集和路由指标、日志和跟踪到监控平台。

OpenTelemetry 提供与供应商无关的 SDK、API 和工具，因此你的数据可以发送到任何可观测性后端进行分析。

OpenTelemetry 正迅速成为云原生应用程序中占主导地位的可观测性遥测标准。对于希望为未来的数据需求做好准备而不受特定供应商或现有技术限制的组织来说，采用 OpenTelemetry 至关重要。

那么，什么是遥测数据？

遥测数据包括从分布式系统收集的日志、指标和跟踪。这三类数据被称为 "可观察性支柱"，可帮助开发人员、DevOps 和 IT 团队了解其系统的行为和性能。

日志（logs）：日志是系统中在特定时间点发生的离散事件的文本记录。每次执行代码块时都会生成日志条目。它们通常包含显示事件发生时间的时间戳以及上下文负载。日志数据有多种格式，包括纯文本、结构化和非结构化。日志对于故障排除、调试和验证代码特别有用。
指标（metrics）：指标是在时间间隔内测量的数值，通常称为时间序列数据。它们包括时间戳、事件名称和事件值等属性。在现代系统中，指标使我们能够监控、分析和响应问题并促进警报。它们可以告诉你有关基础架构或应用程序的信息，例如系统错误率、CPU 利用率或服务请求率。
跟踪（traces）：跟踪表示请求通过分布式系统的路径。OpenTelemetry 中的跟踪（traces）由其跨度（spans）定义。一组跨度构成一个跟踪。跟踪可帮助团队了解请求通过各种服务和组件的端到端旅程和行为。分布式跟踪允许你跟踪完整的执行路径并识别导致问题的代码。跟踪提供了对应用程序整体运行状况的可见性，但对其底层基础架构的可见性有限。要全面了解你的环境，你需要可观察性的另外两个支柱：日志和指标。

OpenTelemetry 简史

OpenTracing 和 OpenCensus 是重叠的分布式跟踪项目，它们独立开发，旨在解决缺乏标准化数据格式的问题。OpenTelemetry 的创建是为了合并 OpenTracing 和 OpenCensus 项目的代码库，将每个项目的优势结合到由云原生计算基金会托管的单个项目中。

OpenTracing 提供与供应商无关的 API，用于将数据发送到后端。OpenCensus 是一组特定于语言的库，开发人员用它来检测他们的代码并将数据发送到后端。两者都是开源的，这意味着软件的源代码是协作开发的，任何人都可以使用、修改和分发。

有了 OpenTelemetry，开发人员不再需要在 OpenTracing 和 OpenCensus 之间做出选择。OpenTelemetry 提供了一套统一的库、API、代理和收集器服务，用于收集和传输数据。

OpenTelemetry 如何工作？

OpenTelemetry 提供了一个通用框架，用于收集遥测数据并将其导出到你选择的 Observability 后端。它使用一组标准化、与供应商无关的 API、SDK 和工具来提取、转换和传输数据。

特定于语言的 OpenTelemetry API 协调整个系统的遥测数据收集并检测你的代码。OpenTelemetry SDK 通过帮助数据收集、处理和导出的库实现和支持 API。OpenTelemetry 还提供服务的自动检测并支持自定义检测。你可以使用供应商提供的导出器或 OpenTelemetry 协议 (OpenTelemetry protocol - OTLP) 导出遥测数据。

OpenTelemetry 的核心组件

OpenTelemetry 的核心组件包括：

收集器

OpenTelemetry 收集器是一个与供应商无关的代理，用于接收、处理和导出遥测数据。它支持接收多种格式的遥测数据，以及在导出之前处理和过滤遥测数据。

语言 SDK

OpenTelemetry 语言 SDK 允许你使用 OpenTelemetry API 生成语言遥测数据并将数据导出到后端。

检测库

OpenTelemetry 支持各种组件，这些组件可从受支持语言的流行库和框架中生成相关的遥测数据。

自动检测

OpenTelemetry 的特定语言实现可以提供一种无需更改源代码即可检测应用程序的方法。

导出器

通过将检测与后端配置分离，导出器可以更轻松地更改后端而无需更改检测。它们还允许你将遥测上传到多个后端。

OpenTelemetry 的优势

OpenTelemetry 的优势在于数据标准化和面向未来的灵活性，从而提高了可观察性、提高了效率并降低了成本。

数据收集标准化

OpenTelemetry 为 DevOps 团队提供了一种解决方案，他们希望以一致的方式收集遥测数据并将其导出到 Splunk、New Relic、Dynatrace 和 Datadog 等后端，而无需更改检测。借助开放标准和标准化数据收集，OpenTelemetry 可以提高可见性并简化可观察性。借助更易于设置的可观察性，团队可以更好地了解系统运行状况、识别性能问题并减少在服务中断之前修复根本原因所需的时间。使用 OpenTelemetry 的组织/单位无需浪费时间开发内部解决方案或研究用于多个应用程序的单个工具。通过减少噪音、成本和配置更改的需求，OpenTelemetry 使组织能够专注于利用数据，而不是数据收集方式。并且可以使用最合理的工具或格式向团队提供见解，从而改善协作。

避免供应商锁定

OpenTelemetry 让团队可以自由选择他们想要的任何后端，而不必受限于特定供应商，从而确保他们的投资面向未来。它可以适应系统、后端和流程的变化，因此你永远不会被锁定在单一平台、解决方案或合同中，从而允许组织随着技术需求的发展而扩展和适应。这种独立性和灵活性意味着你可以根据对你的底线和客户最有利的原则来制定业务决策，而不是技术的限制。

借助 OpenTelemetry，你可以获得可扩展性以适应增长、跨平台兼容性以及与现有监控和可观察性工具的轻松集成。

OpenTelemetry 与 Elastic

OpenTelemetry 提供了一种使用统一遥测格式对应用程序进行检测的标准方法，但它不提供后端或分析组件。Elastic Observability 将 OpenTelemetry 数据无缝集成到开放且可扩展的 Elasticsearch 平台中。

Elastic 原生支持 OpenTelemetry 协议，允许我们提取多种语言的日志、指标和跟踪。这使得大规模利用 Elastic 强大的分析和可视化功能变得更加容易。

2023 年 4 月，Elastic 将其 Elastic Common Schema (ECS) 贡献给 OpenTelemetry，其长期目标是将语义约定与 ECS 融合，形成通用遥测数据模式。Elastic 计划在其数据架构上标准化 OpenTelemetry，并将在未来增加对 OpenTelemetry 项目的投资和合作。

Elastic 也是 OpenTelemetry 项目的强大贡献者。为了帮助管理员监控和排除 CI/CD 平台故障，并帮助开发人员提高 CI/CD 管道的速度和可靠性，Elastic Observability 提供了对 CI/CD 流程的可见性。为了提供管道的监控仪表板、警报和根本原因分析，Elastic 与最流行的 CI/CD 平台（包括 Jenkins、Ansible 和 Maven）的社区合作，使用 OpenTelemetry 来检测工具。

Elastic Observability 是一种企业级解决方案，使组织能够将 OpenTelemetry 检测收集的数据直接发送到 Elastic 部署。它让你可以完全了解你的混合云应用程序，并能够存储、分析和可视化所有内容。你还可以使用 Elastic 强大的机器学习功能来减少分析和恢复时间。

探索 OpenTelemetry 解决方案

OpenTelemetry 资源

OpenTelemetry 常见问题解答

OpenTelemetry 是标准吗？

是的。OpenTelemetry 是一个开源项目，也是日志、跟踪和指标的统一标准。

遥测的例子有哪些？

遥测数据的例子包括系统监控和可观察性中使用的日志、指标和跟踪。

OpenTelemetry 和 Jaeger 有什么区别？

OpenTelemetry 可帮助你处理数据并将其导出到各种开源和商业后端，但它不是像 Jaeger 这样的可观察性后端。虽然 OpenTelemetry 提供了一组 API、SDK 和工具来帮助生成和管理遥测数据，但 Jaeger 是一个开源分布式跟踪工具。IT 团队使用 Jaeger 来监控和排除基于微服务架构的应用程序故障。Jaeger 不支持日志和指标。

OpenTelemetry API 和 SDK 有什么区别？

OpenTelemetry API 或应用程序编程接口可协调整个系统的遥测数据收集并检测你的代码。由于 API 是特定于语言的，因此它们必须与你的代码语言相匹配。OpenTelemetry SDK 或软件开发工具包通过库来实现和支持 API，这些库有助于数据收集、处理和导出到可观察性后端。