作者：来自 Elastic Miguel Luna
Elastic 托管 OTLP Endpoint 现已在 Elastic Cloud Hosted 上正式可用，为任何 OpenTelemetry 数据发送端带来基于 Kafka 的托管弹性能力以及原生 OTLP 数据接入。
Elastic 托管 OTLP Endpoint（ mOTLP）现已在 Elastic Cloud Hosted 上正式可用。任何符合 OTLP 标准的数据源，无论是上游 OpenTelemetry SDK、任意 Collector 发行版、 EDOT，还是自定义转发器，都可以将 traces、 metrics 和 logs 发送到 Elastic Cloud，而无需部署或管理数据接入基础设施。
mOTLP 之前已经在 Elastic Cloud Serverless 上正式发布。随着此次发布， Elastic Cloud Hosted 部署也获得了相同的托管接入能力：基于 OpenTelemetry Collector 的架构，并结合 Kafka 支撑的弹性机制，可以吸收流量高峰，并在关键时刻防止数据丢失。
你只需要设置两个环境变量
从使用角度来看，通过托管 OTLP Endpoint 向 Elastic 发送 OpenTelemetry 数据，只需设置以下环境变量即可：
`
1. export OTEL_EXPORTER_OTLP_ENDPOINT="https://<your-motlp-endpoint>"
2. export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <your-api-key>"
`AI写代码
只需两个环境变量。这就是全部的集成接口。不需要部署 Collector gateway，不需要管理 ingest pipelines，也不需要在边缘 agent 之间分发凭证。
这种极简设计之所以可行，是因为其背后是一个完整的基于 OpenTelemetry Collector 的数据接入架构，专为应对生产环境中的极端情况而设计 —— 无论是发布上线时的流量激增，还是故障期间错误 traces 的爆发。这些时刻正是遥测数据最关键的时候，同时也是接入系统最容易被压垮的时候。
该托管 Endpoint 通过一个基于 OpenTelemetry Collector 的接入层接收 OTLP 数据，并在写入 Elasticsearch 之前先缓冲到一个托管的 Kafka 集群中。 Kafka 可以吸收流量突发，将接入与索引过程解耦，并提供内存队列无法实现的持久性保障。如果 Elasticsearch 暂时承受压力，数据会保存在 Kafka 中，而不会丢失。当压力缓解后，缓冲区会被逐步清空，系统恢复正常。这与你在自建 collector pipeline 中使用 Kafka exporter 和 Kafka receiver 构建的弹性模式相同，只不过现在由 Elastic 为你代管。
这使得整个链路实现了端到端的 OpenTelemetry：
- 你的应用通过 OTel SDK 生成遥测数据。
- 你的 collectors（或直接由 SDK）通过 OTLP 进行导出。
- 托管 Endpoint 通过基于 OTel Collector 的接入层接收这些 OTLP 数据，经由 Kafka 缓冲后，按照 OpenTelemetry 数据模型原生存储到 Elasticsearch 中。
整个 pipeline 中没有专有协议，没有 schema 转换，也没有格式转换。完全是纯粹的 OTel。
引入你的 OTLP 数据，无论来源如何
该端点接受通过 HTTP 和 gRPC 的标准 OTLP。任何支持 OTLP 的工具都可以向其发送数据。
这意味着你可以从以下来源发送数据：
- 来自 OpenTelemetry SDKs（upstream，EDOT，或任何发行版），直接从你的应用程序导出。
- 来自 OpenTelemetry Collectors（Contrib，EDOT，或自定义构建），以代理、网关或 sidecar（部署在主应用旁边、辅助运行的轻量级服务或容器） 形式运行。
- 来自 EDOT Cloud Forwarder，转发云提供商的日志和指标。
- 任何你构建或采用的符合 OTLP 的 forwarder。
这一点值得特别说明，因为这并不是大多数供应商的做法。
许多可观测性后端在你的管道中需要特定于供应商的组件。即使这些组件存在于 OpenTelemetry Collector Contrib 仓库中，它们通常也会在数据输出过程中重塑你的数据。一个特定于供应商的 exporter 可能会扁平化资源属性，丢弃资源与 scope 之间的层级关系，或将语义约定转换为专有 schema。当你的遥测数据到达后端时，它已经不再是标准的 OpenTelemetry 数据。它只是最初是 OpenTelemetry 数据。
Elastic 不需要这些。托管端点会摄取标准 OTLP，这意味着你可以使用每个 OpenTelemetry Collector 自带的标准 otlphttp 或 otlp exporter。不需要 Elastic 专用 exporter，不需要供应商插件，也不需要转换层。你的数据会以与你的 instrumentation 生成时相同的资源层级、相同的语义约定以及相同的属性结构到达 Elasticsearch。
实际结果：团队采用 OpenTelemetry 的速度和工具各不相同。有些团队从 upstream SDK 和 Contrib Collector 开始。其他团队使用 EDOT 以进行 Elastic 特定优化。许多团队则混合使用。托管端点不会强制选择，也不会在供应商 exporter 背后悄悄重塑你的数据。
对于已经在生产环境中运行 OpenTelemetry 的组织来说，这意味着切换到 Elastic 或将 Elastic 添加为目标，只需要更改 exporter URL，而不需要重新设计管道或添加供应商特定组件。
你不再需要管理的内容
在托管 OTLP 端点出现之前，将 OpenTelemetry 数据发送到 Elastic Cloud Hosted 需要部署你自己的 OTLP 兼容摄取层，通常是作为网关运行的 EDOT Collector。该网关需要进行容量规划、扩展、监控，并保持可用。如果网关宕机，遥测数据就会停止流动。
使用 mOTLP，这一整层由 Elastic 负责。以下是从你手中移除的工作：
- 端点根据你的流量进行扩展。在 Elastic Cloud Hosted 上，速率限制会根据 Elasticsearch 的背压动态扩展。无需预先配置。
- Collector-to-Kafka 缓冲区处理突发吸收和背压。你不需要自己操作 Kafka 集群。
- 你的 shippers 使用 API key 直接与端点认证。无需中间网关持有和分发后端凭证。
- 端点是托管的、多租户的。你不需要运行冗余 Collector 副本或为摄取层配置健康检查。
这并不意味着你应该从架构中移除所有 collectors。边缘 collectors（DaemonSet agents、sidecars、host agents）仍然有作用：通过基于 pull 的接收器（如 filelog 和 hostmetrics）收集基础设施遥测，应用本地转换，并在导出前对数据进行批处理。变化在于，现在的目标是托管端点，而不是自运营网关。
动态速率扩展：系统适应你的集群
在 Elastic Cloud Hosted 上，托管端点没有固定吞吐上限。它使用动态速率扩展，根据你的 Elasticsearch 集群容量和当前负载进行调整。
这与静态速率限制是根本不同的模型。系统不是为峰值预置容量并为闲置支付费用，而是持续校准摄取量以匹配集群实际可处理能力。突发负载仍可能在系统扩展期间触发临时 429 响应，但这些会自动解决。
如果你持续看到 429 错误，信号很明确：你的 Elasticsearch 集群需要更多容量。扩展集群会减少背压，从而提高摄取速率限制。Elastic Cloud Hosted 的自动扩展功能可以帮助自动化此过程，AutoOps 可以通过监控部署并在检测到容量限制时提供扩展或调整资源的建议。
原生 OTLP 存储：从 OTel 起点到终点
端到端的 OTel 流程并不会在摄取时停止。通过托管端点到达的数据使用 OpenTelemetry 数据模型存储。资源属性、语义约定和信号结构保持原样。管道中没有任何点会将数据翻译成 ECS 或其他 schema。
这意味着你的 SDK 生成的属性名称与你在 ES|QL 和 Discover 中查询的名称相同：service.name、http.request.method、k8s.pod.name 完全按照 OpenTelemetry 规范存储。你无需调试映射层或猜测哪个 schema 转换丢失了属性。你的 instrumentation 输出的内容就是 Elasticsearch 存储的内容，也是你搜索的内容。
如果未配置特定数据集或命名空间，遥测数据会落入默认数据流：traces-generic.otel-default、metrics-generic.otel-default 和 logs-generic.otel-default。你可以通过设置 data_stream.dataset 属性，将日志路由到专用数据集，这可以在 collector 配置中或通过 OTEL_RESOURCE_ATTRIBUTES 进行设置。
`
1. processors:
2. transform:
3. log_statements:
4. - set(log.attributes["data_stream.dataset"], "app.orders") where resource.attributes["service.name"] == "orders-service"
`AI写代码
失败存储：映射冲突的安全网
即使经过仔细的 schema 设计，映射冲突仍然会发生。一个服务中的字段是 string，而在另一个服务中可能是 integer。在传统设置中，这些冲突会导致索引失败和数据丢失。
托管端点默认对所有 OTLP 数据流启用失败存储。因映射冲突或摄取管道异常导致索引失败的文档会存储在单独的索引中，而不是被丢弃。你可以从 Data Set Quality 页面检查失败文档，并修复根本问题而不丢失数据。
这在 OpenTelemetry 环境中特别有价值，因为多个团队可能独立进行 instrumentation，属性类型在各服务之间可能会漂移。
入门
托管 OTLP 端点现已在 Elastic Cloud Hosted 部署（版本 9.0+）的支持区域提供。
查找你的端点：
- 登录 Elastic Cloud Console。
- 选择你的部署并进入 Manage。
- 在 Application endpoints 部分，选择 Managed OTLP 并复制公共端点。
然后将任何 OTLP exporter 指向它：
`
1. export OTEL_EXPORTER_OTLP_ENDPOINT="https://<your-motlp-endpoint>"
2. export OTEL_EXPORTER_OTLP_HEADERS="Authorization=ApiKey <your-api-key>"
`AI写代码
就这些。Traces、metrics 和 logs 会在几秒内开始流入你的部署。
有关详细操作指南，请参阅 发送数据到 Elastic Cloud Managed OTLP Endpoint 快速入门。
