用户越来越多地要求自托管软件或 SaaS 产品能够将日志、追踪和指标发送到他们自行选择的可观测性栈中，无论是为了满足合规要求、控制成本还是集中数据。当产品将用户锁定在其内置仪表板中，或仅允许向特定供应商导出时，会产生不必要的摩擦。OTel‑native 方法通过在标准 OpenTelemetry 协议（OTLP）之上设计产品，使其能够将遥测数据推送到任何 OpenTelemetry‑兼容的端点，从而使用户无需为每个系统构建自定义适配器，即可自由选择其偏好的后端。
此图像支持 OTel‑native 方法的介绍，展示了 OTLP 如何让用户无需自定义适配器即可选择任意可观测性后端。
可靠的 OTel‑native 导出方案依赖四个关键属性：供应商中立性（用户可以将数据指向任意 OTel‑兼容的收集器或后端）、无需深度定制开发（用户通过标准 OTel SDK 和 OTLP 进行集成）、保留丰富上下文（元数据、时间戳以及 trace/span 关联得以保留）以及遵循语义约定，以确保数据在不同后端之间保持标准化且可解释。OpenTelemetry 定义了四种信号类型——日志（事件和应用日志）、追踪（分布式追踪和跨度）、指标（计量器、仪表、直方图）以及配置文件（资源使用样本，目前处于公开 alpha 阶段）。根据生成遥测数据的系统的运行主体不同，实现方式也有所差异：对于自托管软件，产品会被 OpenTelemetry 揭露并暴露 OTLP 端点的配置标志（例如通过环境变量或配置文件），如 Kuma 和 Keycloak 所示；对于云平台，提供商会提供诸如“Telemetry Drains”或“Observability Destinations”之类的功能，用于从用户工作负载和第一方服务中收集遥测数据并将其转发至客户定义的 OTLP 端点，Cloudflare Workers 和 Heroku 即是典型例子。
使用 OTLP 进行推送导出优于传统的轮询 API，因为它能够提供近乎实时的数据，免除用户构建和维护轮询管道的运营负担，并自动保留诸如将日志记录关联到父 trace ID 之类的上下文关系。尽管此模型在日志、追踪和指标方面表现良好，但某些实现仍存在不足：Cloudflare Workers 尚未支持指标导出，而 Keycloak 的日志导出仍处于预览阶段且默认禁用。这些限制表明，要在所有信号上实现完整的 OTel‑native 支持仍需持续工作，但核心模式提供了一种面向未来、供应商中立的基础，能够适用于用户选择的任意可观测性栈。