什么是 OpenTelemetry？
OpenTelemetry 定义
OpenTelemetry (OTel) 是一个开源可观测性框架，允许开发团队以单一、统一的格式生成、处理和传输遥测数据。它由云原生计算基金会 (CNCF) 开发，旨在为收集和路由指标、日志和追踪到监控平台提供标准化的协议和工具。
OpenTelemetry 提供与供应商无关的 SDK、API 和工具，因此您的数据可以发送到任何可观测性后端进行分析。
OpenTelemetry 正在迅速成为云原生应用程序中占主导地位的可观测性遥测标准。对于希望为未来的数据需求做好准备，而不受特定供应商或现有技术限制的组织来说，采用 OpenTelemetry 被认为是至关重要的。
那么，什么是遥测数据？
遥测数据由从分布式系统中收集的日志、指标和追踪组成。这三个类别的数据被称为“可观测性的支柱”，可帮助开发人员、DevOps 和 IT 团队了解其系统的行为和性能。
日志：日志是系统中在特定时间点发生的离散事件的文本记录。每次执行代码块时都会生成日志条目。它们通常包括一个显示事件发生时间的时间戳以及一个上下文有效负载。日志数据有多种格式，包括纯文本、结构化和非结构化。日志对于故障排除、调试和验证代码特别有用。
指标：指标是在一段时间间隔内测量的数值，通常称为时间序列数据。它们包括诸如时间戳、事件名称和事件值之类的属性。在现代系统中，指标使我们能够监控、分析和响应问题并促进警报。它们可以告诉您有关您的基础架构或应用程序的信息，例如系统错误率、CPU 利用率或服务的请求率。
追踪 (Traces)： 追踪代表请求在分布式系统中的路径。在 OpenTelemetry 中，追踪由其跨度 (span) 定义。一组跨度构成一个追踪。追踪有助于团队理解请求通过各种服务和组件的端到端旅程和行为。分布式追踪使您能够跟踪完整的执行路径并识别导致问题的代码。追踪提供了应用程序整体运行状况的可视性，但对底层基础架构的可视性有限。要全面了解您的环境，您需要可观察性的另外两个支柱：日志和指标。
OpenTelemetry 的简史
OpenTracing 和 OpenCensus 是重叠的分布式追踪项目，它们独立开发以解决缺乏标准化数据格式的问题。创建 OpenTelemetry 是为了合并 OpenTracing 和 OpenCensus 项目的代码库，将各自的优势整合到一个由云原生计算基金会托管的单一项目中。
OpenTracing 提供了与供应商无关的 API，用于将数据发送到后端。OpenCensus 是一组特定于语言的库，开发人员使用它们来检测他们的代码并将数据发送到后端。两者都是开源的，这意味着该软件的源代码是协作开发的，并且可供任何人使用、修改和分发。
使用 OpenTelemetry，开发人员不再需要在 OpenTracing 和 OpenCensus 之间进行选择。OpenTelemetry 提供了一套统一的库、API、代理和收集器服务，用于收集和传输数据。
OpenTelemetry 如何工作？
OpenTelemetry 提供了一个通用的框架，用于收集遥测数据并将其导出到您选择的可观察性后端。它使用一组标准化的、与供应商无关的 API、SDK 和工具来摄取、转换和传输数据。
特定于语言的 OpenTelemetry API 协调整个系统中的遥测数据收集并检测您的代码。OpenTelemetry SDK 通过库实现并支持 API，这些库有助于数据收集、处理和导出。OpenTelemetry 还提供服务的自动检测并支持自定义检测。您可以使用供应商提供的导出器或 OpenTelemetry 协议 (OTLP) 导出您的遥测数据。
OpenTelemetry 的核心组件
OpenTelemetry 的核心组件包括
收集器 (Collector)
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 可观察性无缝地将 OpenTelemetry 数据集成到开放且可扩展的 Elasticsearch 平台中。
Elastic 本身支持 OpenTelemetry 协议，这使我们能够跨多种语言提取日志、指标和追踪。这使得大规模利用 Elastic 强大的分析和可视化功能变得更加容易。
2023 年 4 月，Elastic 将其 Elastic Common Schema (ECS) 贡献给 OpenTelemetry，其长期目标是使语义约定与 ECS 融合，从而形成通用的遥测数据模式。Elastic 计划在数据架构上标准化 OpenTelemetry，并将在未来增加对 OpenTelemetry 项目的投资和协作。
Elastic 也是 OpenTelemetry 项目的强大贡献者。为了帮助管理员监控和排除 CI/CD 平台的故障，并帮助开发人员提高 CI/CD 管道的速度和可靠性，Elastic 可观察性提供了CI/CD 流程的可视性。为了提供管道上的监控仪表板、警报和根本原因分析，Elastic 与最流行的 CI/CD 平台的社区合作，包括 Jenkins、Ansible 和 Maven，使用 OpenTelemetry 检测工具。
Elastic 可观察性是一种企业级解决方案，使组织能够将 OpenTelemetry 检测收集的数据直接发送到 Elastic 部署。它使您可以完全查看您的混合云应用程序，并能够存储、分析和可视化所有数据。您还可以使用 Elastic 强大的机器学习功能来减少分析和恢复时间。
OpenTelemetry 常见问题解答
OpenTelemetry 是标准吗？
是的。OpenTelemetry 是一个开源项目，也是日志、追踪和指标的统一标准。
遥测的示例有哪些？
遥测数据的示例包括系统监控和可观察性中使用的日志、指标和追踪。
OpenTelemetry 和 Jaeger 之间的区别是什么？
OpenTelemetry 帮助您处理数据并将其导出到各种开源和商业后端，但它不是像 Jaeger 这样的可观察性后端。虽然 OpenTelemetry 提供了一组 API、SDK 和工具来帮助生成和管理遥测数据，但 Jaeger 是一种开源分布式追踪工具。IT 团队使用 Jaeger 来监控和排除基于微服务架构的应用程序的故障。Jaeger 不支持日志和指标。
OpenTelemetry API 和 SDK 之间的区别是什么？
OpenTelemetry API（或应用程序编程接口）协调整个系统中的遥测数据收集并检测您的代码。由于 API 是特定于语言的，因此它们必须与您的代码的语言匹配。OpenTelemetry SDK（或软件开发工具包）通过库实现并支持 API，这些库有助于数据收集、处理和导出到可观察性后端。