Elastic Common Schema 与 OpenTelemetry 融合 — 一条免受供应商锁定，实现更好可观测性和安全性的途径
在 Twitter 上分享
在 LinkedIn 上分享
在 Facebook 上分享
通过邮件分享
打印
KubeCon Europe 大会宣布 OpenTelemetry (OTel) 已接受 Elastic Common Schema (ECS) 作为对该项目的一项贡献。这项举措的目标是将 ECS 与 OpenTelemetry 的语义约定 (SemConv) 融合到一个由 OpenTelemetry 维护的单一开放模式中。本常见问答详细介绍了 Elastic 的 Elastic Common Schema 对 OpenTelemetry 的贡献，它将如何助推行业采用通用模式，以及它对可观测性和安全性的影响。
宣布了什么内容？
Elastic 将自己的开源项目 Elastic Common Schema (ECS) 贡献给了云原生计算基金会 (CNCF) 下的 OpenTelemetry 项目，以助力二者融合为适用于处理可观测性和安全性数据的通用模式。使用通用模式，将有助于将数据规范化，进而能够更好地在任何可观测性或安全性平台上对数据进行分析、可视化和关联。OpenTelemetry 通过采用 ECS，可为 OTel 用户社区提供一种成熟且经过验证的通用模式，用于处理指标、日志、痕迹、资源（主机、容器等）和安全事件。
Elastic 用户需要了解什么？
Elastic 会保护用户在 ECS 上的投资。ECS 在 OpenTelemetry 内部的持续发展，将会为 ECS 用户提供一条清晰的路径，以采用我们期望成为业界使用最广泛的语义约定标准。
Elastic 将会参与其中并与 OTel 社区密切合作，以随着时间的推移，适当合并 ECS 和 OpenTelemetry 的语义约定。在新合并的模式上，模式演变不可避免，但 Elastic 仍会继续支持采用当前 ECS 格式的用户数据。Elastic 用户可以选择继续采集数据并使用当前（“冻结”）的 ECS 格式，也可以迁移到新模式。
Elastic 将会为决定迁移到新模式的用户提供进行简单迁移的指导和工具。
为什么 Elastic 向 OTel 贡献 ECS？
OpenTelemetry 的语义约定 (SemConv) 和 Elastic Common Schema 的融合，将会为多种资源、指标、日志、痕迹、安全事件和审计事件提供一种通用的命名模式，以便在代码库、各种库和平台之间使用。ECS 与 OTel 语义约定的这一融合将：
- 围绕单一标准协调工作，以供事件数据生产者广泛采用
- 为运营推动更好的可见性和根本原因分析
- 让供应商和社区专注实现更丰富的可观测性和安全功能，而不必忙于处理数据转换任务
- 促进跨多种信号类型的跨组织分析，包括安全性和可观测性之间的分析
- 提升 OpenTelemetry 的采用率以及可观测性和安全域的持续发展与融合
为什么组织需要一种通用模式？
很多时候，组织很难弄清楚问题发生的时间（可见性）和发生的原因（根本原因分析）。导致出现这种运营挑战的原因是，数据都是孤岛式的存储，并以不同模式进行结构化。组织在不必要的数据转换上花费的时间比了解问题、分析根本原因和优化运营还要多。
借助根据通用模式建构的数据，运营团队将能够集中精力识别、解决和预防问题，同时缩短平均问题解决时间 (MTTR)。此外，由于数据不再重复且无需对数据进行规范化处理，因此运营成本也会随之降低。
是否有通用模式的说明性示例？
举一个简单的说明性示例：当客户端的 IP 地址是从监测或管理有关该客户端的遥测数据的多个源发送时，可观测性平台就会以多种格式接收这些信息：
src:10.42.42.42
client_ip:10.42.42.42
apache2.access.remote_ip: 10.42.42.42
context.user.ip:10.42.42.42
src_ip:10.42.42.42一个 IP 地址以多种方式表示，就会给分析潜在问题甚至识别问题带来复杂性。如果观测到的数据没有清晰的语义且不使用通用模式，那么可观测性解决方案将难以自动关联、分析数据并从中识别根本原因。这样的情况下，运营团队（SRE 和 DevOps 等）必须理解这些多重定义，知道如何查找这些定义，然后手动将数据规范化以进行分析。
有了通用模式后，所有传入数据都将采用标准化的格式。以上面的例子来说，每个来源都会以相同的方式识别客户端的 IP 地址：
source.ip:10.42.42.42可观测性和安全解决方案现在可以利用统一定义的数据模式来实现数据关联和分析的自动化。现在，运营团队可以有更多时间专心了解问题，查找根本原因和优化运营，而不必在数据转换上花费精力。
什么是 Elastic Common Schema (ECS)？
Elastic Common Schema (ECS) 是在 Elastic 用户社区的支持下开发的一种开源 (Apache 2.0) 规范，用于定义在 Elasticsearch 中存储事件数据时使用的一组通用字段。ECS 的目标是支持并鼓励 Elasticsearch 用户将他们的事件数据规范化，以便更好地对事件中表示的数据进行分析、可视化和关联。ECS 是 Elastic 可观测性和安全解决方案的基础，是一种可靠且被广泛采用的模式，自 2019 年面市以来，已经过多年的发展和完善。
什么是 OpenTelemetry 和 OpenTelemetry 语义约定？
OpenTelemetry (OTel) 是一个提供了一系列规范、工具、API 和 SDK 的开源项目，这些规范、工具、API 和 SDK 可用来生成、收集、处理和导出遥测数据（指标、日志和痕迹），以理解软件性能和行为。它已成为 CNCF 生态系统中成长速度第二快的项目。
OpenTelemetry 的语义约定 (SemConv) 为各种操作和数据都规定了通用名称。使用 OpenTelemetry SemConv 的益处在于：遵循一种通用的命名模式，可以为 OTel 最终用户在代码库、资料库和平台之间实现标准化。此外，它的另一大益处是能够解耦供应商特定的语义。这样，通过 OpenTelemetry 的 SemConv，数据用户便可解决他们数据的供应商锁定问题。因此，他们可以轻松地在可观测性解决方案（以及有 ECS 贡献的安全解决方案）之间切换，而无需对他们的数据收集进行调整。
ECS 的贡献对 OpenTelemetry 有何帮助？
OpenTelemetry 最大的需求是加速对描述日志和安全事件模式的定义。ECS 的贡献者已经定义了一组统一且广为接受的日志语义约定，这些语义约定都可在 OTel 中采用。ECS 被广泛用于建构可观测性和安全用例中使用的日志。
通过这两者的结合，将会加速供应商创建的日志记录和 OTel 组件日志（例如，OTel 收集器日志接收器和处理器）的整合。这项举措的目标是，为最常用类型的系统定义与供应商无关的语义约定，并支持供应商创建的组件或开源组件（例如，HTTP 访问日志、网络日志、系统访问/身份验证日志），从而将 OTel 关联性扩展到这些新信号。此外，用户还可充分享用一站式日志集成的便利，OTel 兼容的可观测性和安全性产品和服务可完全识别这些集成。
ECS for Security 的日臻成熟恰逢其时，可以提高使用 OpenTelemetry 为安全性用例收集的数据的实用性。通过整合 ECS，将可让 OTel 生产者建构安全事件。
ECS 的许可是否会有变化？
ECS 许可不会有任何变化。与 OpenTelemetry 一样，ECS 也获得了 Apache 2.0 许可。
Elastic 目前是否支持 OpenTelemetry？
Elastic 原生支持 OTel。Elastic 用户可以直接从应用程序或通过 OTel 收集器将 OTel 数据发送到 Elastic APM；Elastic APM 可同时处理 OTel SemConv 和 ECS。借助这种对 OTel 的原生支持，所有 Elastic APM 功能都可以在 OTel 中使用。请参阅 Elastic 文档，了解有关 OTel 集成的更多信息。
在哪里可以了解更多关于 ECS 和 Elastic 对 OpenTelemetry 的支持？
下列是有关 Elastic 对 OpenTelemetry 的支持和集成的其他信息和文档：
分享
在 Twitter 上分享
在 LinkedIn 上分享
在 Facebook 上分享
通过邮件分享
打印
