作者：来自 Elastic David Hope
OpenTelemetry（ OTel ）已经毫无争议地成为可观测性的标准。我们正在见证行业的一个转折点 —— 像 AWS 和p Google 这样的主要厂商正在从专有 agent 转向 OTel 标准。然而，虽然采用意愿很高，真正落地仍然是一个难题。许多团队从“为什么”走向“怎么做”时遇到阻碍，卡在架构设计、迁移路径以及合适用例的识别上。
作为每天在真实环境中帮助团队采用 OTel 的实践者，我们看到一个反复出现的模式：组织往往只是把 OpenTelemetry 当作一次工具替换。现实是，成功的采用需要把 OTel 视为一种新的运行模式，而不仅仅是一项技术。
因此，我们提供了一份 OTel 采用的战略蓝图。让我们跳出流行语，直面实现和架构的实际问题。
OpenTelemetry 的真正价值：上下文，而不仅是厂商无关性
当高管批准 OpenTelemetry 时，通常基于几个原因，其中包括厂商无关性和效率。他们希望只采集一次数据，并避免 “vendor lock-in” 问题，也就是专有 agent 使用彼此不兼容的语言。
避免锁定确实有价值，但它并不是采用 OpenTelemetry 的最重要驱动因素。OpenTelemetry 的真正力量在于通过保留上下文层来减少问题排查时间。
我们需要停止用 “三大支柱”（ logs、 metrics 和 traces ）来思考可观测性，而应将其视为一条编织在一起的辫子。如果一个系统产出 CPU metrics，另一个系统产出 logs，但它们对 hostname 的命名不同，规范化就会变成一场噩梦，也就无法有效地关联这些数据。
这正是 OTel 语义约定发挥作用的地方。命名本身就很难；OTel 通过强制约定 “我们如何称呼事物” 来解决这个问题。通过利用这些约定，尤其是 resource attributes，我们可以识别出正在发出遥测数据的具体实体，无论是 VM、 Kubernetes pod，还是某个 node。这带来了开箱即用的关联能力。目标是查询一个实体，就能看到与之相关的所有信号，而无需进行人工转换。
“ Collector First ” 架构
一个常见的陷阱是把 OTel 的采用当作对现有监控工具的 “一次性大爆炸式” 替换。这几乎注定会失败。相反，我们建议采用 Collector First 策略。
OpenTelemetry collector 是整个架构的核心。它可以接收数据、处理数据（例如过滤、打标签和增强），并将数据导出到多个 backend。通过在完全重新为应用进行 instrumentation 之前，先在基础设施中部署 collector，你可以将数据生成与数据去向解耦。
Edge 与 Gateway 的取舍
在设计 collector 部署架构时，你必须区分 Edge 和 Gateway。
- Edge collector：理想情况下，它应当部署在尽量靠近应用的位置（例如作为 sidecar 或 daemonset）。关键在于必须保持轻量。不要在这里执行复杂的转换或基于尾部的采样。如果 Edge 上的 collector 被压垮，back pressure 会直接反映到应用本身，影响用户体验。
- Gateway collector：这是你的集中式处理层。在这里进行摄取扩展、处理复杂采样，并管理流量突发。
另一个重要考量是供应商发行版的使用。许多团队更倾向于使用上游的 “ 纯原生版本 ” OTel，以确保中立性。然而，上游的 “ contrib ” 仓库几乎包含了所有东西，但并不一定经过生产环境的充分验证。供应商发行版可以提供必要的支持、经过测试的构建版本以及更快的修复速度。最近一项针对 500 多位可观测性负责人所做的调查显示，行业正在明显从 纯原生版本 OTel 和自建版本，转向由 供应商 提供的发行版。
判断 供应商中立性 的试金石并不在于你是否使用某个发行版，而在于你是否在 edge 端发送 OpenTelemetry Protocol（ OTLP ）。只要你的 edge 使用 OTLP 通信，你就仍然保持 厂商无关性。如果某个供应商要求在 edge 端使用专有 exporter，你就重新引入了锁定；而 gateway 则不同，它可以替换为特定 供应商发行版。
用于迁移的 strangler 模式
如何在不影响现有运行的情况下，将一个庞大的 IT 环境迁移到 OTel？我们倡导使用 strangler 模式/蚕食模式。
不要立刻对深度集成的遗留系统进行 “推倒重来” 的替换。相反，应当先从低垂的果实入手，逐步迁移系统。Kubernetes 是天然的起点。由于 OTel 与 CNCF 生态系统具有相同的 DNA，它与 Kubernetes 环境天然契合。
你可以先部署 OTel operator，并使用 Helm charts 启动 collectors。Receivers 可以从 Kubernetes endpoints 拉取 Prometheus metrics，将其规范化为 OTel 语义约定，然后沿着 pipeline 向下游传递。一旦基础设施层能够正确上报数据，你就可以向内推进到应用逻辑层。
应用监测：自动与手动的二元性
有一种常见误解，认为你必须在自动监测（使用 agents）和手动监测（通过 SDK 编码）之间二选一。事实上，最成熟的组织通常两者并用。
- 自动监测：它可以帮你完成 70%–80% 的工作。只需为 Kubernetes pods 添加注解，就可以注入监测，用于捕获标准的 HTTP 请求、数据库调用以及响应时间。
- 手动监测：这是连接 “系统可用性” 和 “业务健康度” 的关键。你应该在代码中手动埋点，捕获业务相关的属性，例如 Customer ID。
想象这样一个场景：某个事务变慢了。自动监测会告诉你数据库查询出现了延迟；而手动监测则允许你在 traces 中按某个 Customer ID 进行搜索，查看是否影响到了 VIP 客户。你甚至可以将这些属性注入到 logs 中，使整个数据集都可以按业务上下文进行搜索。
OpenTelemetry 的落地运维
最后，成功的采用需要一个运行模式。你需要明确谁负责 schemas、pipelines 和成本控制。不能简单地认为更多的遥测数据就意味着更多的洞察。
为了保持可控性，验证至关重要。我们建议使用像 Weaver 这样的工具来维护 schema 的一致性，以及使用监测 Score 来验证遥测质量。这些项目有助于确保随着采用规模的扩大，你的数据仍然可用，并符合你已达成一致的语义约定。
结论：OpenTelemetry 成为可观测性数据的事实标准
我们正朝着一个未来迈进，在那里 OpenTelemetry 将成为默认 —— 既隐形又无处不在。它正从 traces 和 metrics 扩展到 CI/CD pipelines，甚至扩展到大语言模型（ LLM ）的可观测性。
行业正在发生转变。你可以选择在每次更换 供应商 时重新埋点应用，也可以采用 OpenTelemetry，一次性为你的可观测性架构做好未来适配。前进的道路不仅仅是安装 collector，而是采用一种策略——优先考虑上下文、一致性，以及逐步、可管理地迁移到可观测性平台的开源标准。
想获取 Elastic 关于 OpenTelemetry 的更多专业知识，可观看我们的网络研讨会：开始使用 OpenTelemetry ：可观测性团队的规划与技巧。
本文中描述的任何功能或特性的发布时间和内容，完全由 Elastic 自行决定。当前不可用的功能或特性，可能无法按时提供，甚至可能永远不会提供。
