作者：来自 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 自行决定。当前不可用的功能或特性，可能无法按时提供，甚至可能永远不会提供。
原文：https://www.elastic.co/blog/opentelemetry-overview-blueprint-otel-architecture
)
)
