OpenTelemetry 不仅仅是成为可观测性的开放摄取标准。 作为主要的云原生计算基金会 (CNCF) 项目之一，其提交数量与 Kubernetes 一样多，它正在获得主要 ISV 和云提供商的支持，为该框架提供支持。 许多来自金融、保险、科技和其他行业的全球公司开始对 OpenTelemetry 进行标准化。 借助 OpenTelemetry，DevOps 团队可以采用一致的方法来收集和摄取遥测数据，从而提供事实上的可观测性标准。
Elastic® 正在战略性地对 OpenTelemetry 进行标准化，以实现主要数据收集架构的可观察性和安全性。 此外，Elastic 还致力于帮助 OpenTelemetry 成为可观测性生态系统事实上最好的数据收集基础设施。 除了最近 Elastic Common Schema (ECS) 对 OpenTelemetry (OTel) 的贡献之外，Elastic 正在加深与 OpenTelemetry 的关系。
如今，自 Elastic 7.14 起，Elastic 原生支持 OpenTelemetry，能够直接提取基于 OpenTelemetry 协议 (OTLP) 的跟踪、指标和日志。
在本博客中，我们将回顾 Elastic 提供的当前 OpenTelemetry 支持，其中包括以下内容：
- 轻松获取使用 Python、NodeJS、Java、Go 和 .NET 配置的 OpenTelemetry 代理的应用程序的分布式跟踪和指标
- OpenTelemetry 使用各种配置记录检测和摄取
- 通过 ECS 开放日志等的语义约定，这不是 OpenTelemetry 的一部分
- 基于机器学习的 AIOps 功能，例如延迟关联、故障关联、异常检测、日志峰值分析、预测模式分析、弹性 AI 助手支持等，都适用于本机 OTLP 遥测。
- 以你自己的速度将应用程序迁移到 OpenTelemetry。 即使使用 OpenTelemetry 和/或 Elastic APM 代理的混合服务，Elastic 的 APM 功能也能无缝运行。 你甚至可以将 OpenTelemetry 仪器与 Elastic Agent 结合起来。
- 与 Kubernetes 集群集成视图和分析，大多数 OpenTelemetry 应用程序都在其上运行。 在分析基于 OpenTelemetry 的应用程序问题时，Elastic 可以突出显示与每个服务相关的特定 Pod 和容器。
将 OpenTelemetry 引入 Elastic
如果你有兴趣了解将 OpenTelemetry 跟踪和指标提取到 Elastic 中是多么简单，请按照本博客中概述的步骤操作。
让我们概述一下 Elastic 为摄取 OpenTelemetry 数据提供的功能。 以下是你的所有选择：
使用 OpenTelemetry 收集器
使用最常见的配置选项 OpenTelemetry Collector 时，你只需添加两个关键变量。
这些说明使用 Elastic 的特定 opentelemetry-collector 配置。 本质上，elastic/opentelemetry-demo 中指定的 Elastic values.yaml文件将 opentelemetry-collector 配置为使用两个主要值指向 Elastic APM 服务器：
- OTEL_EXPORTER_OTLP_ENDPOINT 是 Elastic 的 APM 服务器
- OTEL_EXPORTER_OTLP_HEADERS Elastic 授权
这两个值可以在 Elastic Cloud 中 APM 集成说明（Integrations->APM）下的 OpenTelemetry 设置说明中找到。
嵌入代码中的原生 OpenTelemetry 代理
如果你考虑在代码中使用 OpenTelemetry 库，你只需将该服务指向 Elastic 的 APM 服务器，因为它支持本机 OLTP 协议。 不需要特殊的 Elastic 转换。
为了有效地演示这一点并提供有关如何使用 OpenTelemetry 的一些教育，我们有两个应用程序可供你学习：
Elastic 版本的 OpenTelemetry 演示：与所有其他可观测性供应商一样，我们也有自己的 OpenTelemetry 演示的分叉版本。
- Elastiflix：此演示应用程序是一个示例，可帮助你学习如何对各种语言和遥测信号进行检测。
查看我们关于使用 Elastiflix 应用程序和使用 OpenTelemetry 进行检测的博客：
- Elastiflix 应用程序，使用 OpenTelemetry 检测不同语言的指南
- Python：自动检测、手动检测
- Java：自动检测、手动检测
- Node.js：自动检测、手动检测
- .NET：自动检测、手动检测
我们还制作了有关这些主题的 YouTube 视频：
- 如何使用 OpenTelemetry 手动检测 Java（第 1 部分）
- 如何使用 OpenTelemetry 手动检测 Java（第 2 部分）
- 使用 OpenTelemetry 自定义 Java 检测
- Elastic APM - 使用 OpenTelemetry 的自动 .NET 检测
- 如何使用 OpenTelemetry 手动检测 .NET 应用程序
鉴于 Elastic 和 OpenTelemetry 拥有庞大的用户群，这些为任何试图学习 OpenTelemetry 仪器复杂性的人提供了丰富的教育资源。
支持 OpenTelemetry 的弹性代理
如果你已经实现了 OpenTelemetry，你仍然可以将它们与 OpenTelemetry 一起使用。 如今，Elastic APM 代理能够将 OpenTelemetry span 作为跟踪的一部分发送。 这意味着，如果你的应用程序中有任何发出 OpenTelemetry 范围的组件，它将成为 Elastic APM 代理捕获的跟踪的一部分。
OpenTelemetry 登录 Elastic
如果你查看 OpenTelemetry 文档，你会发现许多语言库仍处于实验或尚未实现状态。 根据文档，Java 处于稳定状态。 根据你的服务的语言以及你对冒险的兴趣，有多种选项可用于从服务和应用程序导出日志并将它们在可观察性后端中结合在一起。
在之前的博客中，我们讨论了 3 种不同的配置来正确地将日志数据记录到 Elastic for Java 中。 该博客探讨了 OpenTelemetry 日志记录的最新技术，并针对以下租户提供了可用方法的指导：
- 将服务日志与 OTel 生成的跟踪（如果适用）相关联
- 正确捕获异常
- 跨跟踪、指标和日志记录的通用上下文
- 支持 slf4j 键值对（“结构化日志记录”）
- 通过 OTel baggage 自动附加服务之间携带的元数据
- 使用 Elastic Observability 后端
- 无论采用何种方法，Elastic 中的数据保真度始终如一
目前，博客中介绍了三种模型，用于将应用程序或服务日志发送到 Elastic 并与 OTel 跟踪和 baggage 相关联：
- 使用嵌入式 OpenTelemetry Instrumentation 库通过 OTLP 协议将服务中的日志（以及跟踪和指标）输出到 Elastic
- 将服务中的日志写入由 OpenTelemetry Collector 抓取的文件，然后通过 OTLP 协议转发到 Elastic
- 将日志从你的服务写入由 Elastic Agent（或 Filebeat）抓取的文件，然后通过 Elastic 定义的协议转发到 Elastic
请注意，与 (2) 和 (3) 相比，(1) 不涉及在摄取到 Elastic 之前将服务日志写入文件。
OpenTelemetry 是 Elastic 的首选模式
Elastic 最近向 OpenTelemetry (OTel) 项目贡献了 Elastic Common Schema (ECS)，从而在 OTel 语义约定框架内实现了安全性和可观测性数据的统一数据规范。
ECS 是一种开源规范，是在 Elastic 用户社区的支持下开发的，用于定义在 Elasticsearch® 中存储事件数据时要使用的一组通用字段。 ECS 有助于降低因数据重复而产生的管理和存储成本，提高运营效率。
同样，OTel 的语义约定 (SemConv) 也为各种操作和数据指定了通用名称。 使用 OTel SemConv 的好处在于遵循通用命名方案，可以在代码库、库和平台上为 OTel 用户进行标准化。
ECS 和 OTel SemConv 的合并将有助于推动 OTel 的采用以及可观测性和安全领域的持续发展和融合。
Elastic Observability APM 和机器学习功能
Elastic Observability 的所有 APM 功能均可通过 OTel 数据使用（请在我们的博客 Independence with OpenTelemetry 中了解更多相关信息）：
- Service maps
- 服务详细信息（延迟、吞吐量、失败的事务）
- 服务之间的依赖关系
- Transactions（跟踪）
- ML 相关性（特别是延迟）
- 服务日志
除了 Elastic 的 APM 和遥测数据的统一视图之外，你现在还可以使用 Elastic 强大的机器学习功能来减少分析，并发出警报以帮助减少 MTTR。 以下是我们拥有的一些基于 ML 的 AIOps 功能：
- 异常检测：Elastic Observability 打开后（请参阅文档），会通过对 OpenTelemetry 数据的正常行为（学习趋势、周期性等）进行持续建模来自动检测异常。
- 日志分类：Elastic 还可以快速识别 OpenTelemetry 日志事件中的模式，以便你可以更快地采取行动。
- 高延迟或错误事务：Elastic Observability 的 APM 功能可帮助你发现哪些属性导致事务延迟增加，并确定哪些属性对区分事务失败和成功影响最大。
- 日志峰值检测器有助于确定 OpenTelemetry 日志速率增加的原因。 通过使用分析工作流程视图，可以轻松查找和调查异常峰值的原因。
- 日志模式分析可帮助你查找非结构化日志消息中的模式，并使检查数据变得更加容易。
Elastic 允许你按计划迁移到 OTel
尽管 OpenTelemetry 支持多种编程语言，但其主要功能组件（指标、跟踪和日志）的状态仍处于不同阶段。 因此，迁移用 Java、Python 和 JavaScript 编写的应用程序是一个不错的选择，因为它们的指标、跟踪和日志（对于 Java）是稳定的。
对于尚不支持的其他语言，你可以使用 Elastic Agents 轻松检测这些语言，从而以混合模式运行可观测平台（Elastic 代理与 OpenTelemetry 代理）。
这是一个简单的例子：
上图显示了我们标准 Elastic Agent 应用程序的一个简单变体，其中一项服务转向 OTel — 时 newsletter-otel 服务。 但在开发资源允许的情况下，我们可以根据需要轻松地将这些服务转换为 OTel。
因此，当特定语言达到稳定状态时，你可以将所需的内容迁移到 OpenTelemetry with Elastic，然后你可以继续迁移到 OpenTelemetry 代理。
Elastic 中集成的 Kubernetes 和 OpenTelemetry 视图
Elastic 使用 Elastic Agent 管理你的 Kubernetes 集群，你可以在运行 OpenTelemetry 应用程序的 Kubernetes 集群上使用它。 因此，你不仅可以在你的应用程序中使用 OpenTelemetry，Elastic 还可以监控相应的 Kubernetes 集群。
Kubernetes 有两种配置：
1）只需在 kubernetes 集群上部署 Elastic Agent 守护进程集。 我们在题为使用 Elastic Observability 管理 Kubernetes 集群的文章中概述了这一点。 这也只会将 Kubernetes 指标和日志推送到 Elastic。
2）部署 Elastic Agent 不仅包含 Kubernetes Daemon 集，还包含 Elastic的APM 集成、Defend（安全）集成和网络抓包集成，以提供更全面的 Kubernetes 集群可观察性。 我们在以下文章中概述了此配置：使用 Elastic 和 OpenTelemetry 实现 Kubernetes 上的现代可观察性和安全性。
这两个配置示例都使用 OpenTelemetry 演示，并且在 Elastic 中，我们将 Kubernetes 信息与应用程序绑定在一起，以便你能够从 APM 中的跟踪中查看 Kubernetes 信息。 这在故障排除时提供了一种更加集成的方法。
概括
从本质上讲，Elastic 的承诺不仅仅是支持 OpenTelemetry。 我们致力于确保我们的客户不仅采用 OpenTelemetry，而且能够与之一起发展。 通过我们的解决方案、专业知识和资源，我们的目标是提升每个企业的可观察性之旅，将数据转化为推动增长和创新的可行见解。
原文：Native OpenTelemetry support in Elastic Observability | Elastic Blog