OTel-Native 的设计 – 构建可导出到任何可观测性堆栈的产品

OTel-Native by Design - 构建可导出到任何可观测性堆栈的产品，由 Dan Gomez Blanco (New Relic) 贡献。如果您正在构建自托管软件或 SaaS 产品，您的用户最终会要求将日志、跟踪和指标发送到他们自己的可观察性堆栈，无论是为了满足合规性、管理成本还是将所有可观察性数据集中在一个地方。将它们锁定到内置仪表板或限制对某些供应商的导出会产生不必要的摩擦。相反，支持导出到任何 OpenTelemetry (OTel) 兼容后端是一种供应商中立、面向未来的做法，使用户可以自由选择其可观测性堆栈。本文概述了如何设计产品，以便用户可以在需要时将其日志、跟踪和指标导出到 OTel 后端。四种可观测性信号 OpenTelemetry 定义了四种信号类型，全部通过标准 OpenTelemetry 协议 (OTLP) 进行： 日志：事件记录、请求/访问日志以及带有时间戳和元数据的应用程序日志。跟踪：分布式跟踪和跨度，以便用户可以查看跨服务的请求流并将其与日志相关联。指标：计数器、仪表和直方图（例如请求率、延迟、错误率）。配置文件：显示应用程序在执行期间消耗资源的位置的示例。 Profiles 已进入公开 alpha 阶段 Profiles 于 2026 年 3 月 26 日进入公开 alpha 阶段。作为一个信号，OpenTelemetry 打算让配置文件与当前三个主要可观测性信号并驾齐驱，通过捕获整个代码库中的资源使用模式来帮助用户解决生产事件问题。尽管我们在此博客中专门关注日志、跟踪和指标，但我们很高兴看到配置文件如何形成，以及社区如何将它们用于可观察性系统。相同的导出故事适用于所有三个（日志、跟踪和指标）：让用户配置 OTLP 端点并向其推送遥测数据。您可以支持一个、两个或全部三个信号，具体取决于您的产品生成的信号。许多支持 OTel 导出的平台至少支持跟踪和日志，并且现在越来越多的平台附带指标支持。从一开始就针对这三个方面进行设计，可以避免以后进行改造。一个“好的”遥测系统是什么样子一个可靠的导出故事对于您支持的每个信号都有一些明确的属性： 供应商中立：用户可以指向任何 OTel 兼容端点 - 收集器实例，或直接支持 OTLP 的众多后端之一 - 无需为每个端点构建自定义集成。无需深度定制开发：外部平台（或用户的工具）可以使用标准 OTel SDK 和 OTLP 协议（​​而不是专有 API）进行集成。保留丰富的上下文：导出的数据应包括元数据、时间戳和可用的跟踪/跨度相关性（例如，链接到跟踪 ID 的日志记录），以便用户可以在自己的后端调试和分析数据，而不会丢失上下文。支持语义约定：遵守语义约定可确保遥测数据保持标准化，并且可由任何兼容的后端轻松解释。它还减轻了最终用户推理软件系统（无论是第一方系统还是第三方系统）如何工作的认知负担。如果您的设计符合您发出的信号的这些原则，那么您就与现代平台对可观察性导出的看法保持一致。两个上下文：您的产品在哪里运行？添加 OTel 导出的方式取决于谁拥有生成遥测数据的系统。弄清楚这一点有助于您选择正确的方法。自托管软件您的产品是客户在其环境（数据中心、云、Kubernetes 集群）中安装和运行的应用程序或系统（例如身份服务器、服务网格、数据库）。在这里，您可以使用 OpenTelemetry 来检测您的产品。当客户配置端点（例如，通过环境变量或配置文件）时，您的应用程序会从它们正在运行的进程中导出遥测数据。由于 OpenTelemetry 提供了此类标准配置选项，因此您的用户可以期待与任何其他 OTel 仪表系统相同的配置体验。导出发生在客户的环境中；他们控制二进制文件和目的地。示例：Keycloak、Kuma。云平台 您的产品是客户部署自己的应用程序或使用您的托管服务（例如 PaaS、无服务器、API 网关）的平台。工作负载在您的基础架构上运行。在这里，您添加一个平台功能，例如“遥测数据消耗”或“可观测性目标”，让客户可以配置遥测数据的发送位置。您的平台从他们的工作负载（以及您自己的服务，如路由器）收集遥测数据，并将其转发到客户的 OTLP 端点。导出是由您的基础设施完成的，而不是由客户运行的应用程序二进制文件完成的。示例：Heroku、Cloudflare。简而言之，用户d