第 7 章：建议的设置和遥测管道
现在我们了解了组成 OpenTelemetry 的各个构件，我们应该如何将它们组合成一个强大的生产管道？
答案取决于你的出发点是什么。OpenTelemetry 是模块化的，设计成可以在各种不同的规模下工作。你只需要使用相关的部分。这就是说，我们已经创建了一个建议的路线图供你遵循。
安装 OpenTelemetry 客户端
可以单独使用 OpenTelemetry 客户端而不部署收集器。这种基本设置通常是绿地部署的充分起点，无论是测试还是初始生产。OpenTelemetry SDK 可以被配置为直接向大多数可观测性服务传输遥测数据。
挑选一个导出器
默认情况下，OpenTelemetry 使用 OTLP 导出数据。该 SDK 提供了几种常见格式的导出器。Zipkin、Prometheus、StatsD 等。如果你使用的可观测性后端没有原生支持 OTLP，那么这些其他格式中的一种很可能会被支持。安装正确的导出器并将数据直接发送到你的后端系统。
安装库仪表
除了 SDK，OpenTelemetry 仪表必须安装在所有 HTTP 客户端、Web 框架、数据库和应用程序的消息队列中。如果这些库中有一个缺少仪表，上下文传播就会中断，导致不完整的追踪和混乱的数据。
在某些语言中，如 Java，仪表可以自动安装，这就更容易了。请确保了解 OpenTelemetry 如何在你使用的编程语言中管理仪表，并仔细检查仪表是否正确安装在你的应用程序中。
选择传播器
仔细检查你的系统需要哪些传播器也很重要。默认情况下，OpenTelemetry 使用 W3C 的追踪上下文和 Baggage 传播器。然而，如果你的应用程序需要与使用不同的追踪传播器的服务进行通信，如 Zipkin 的 B3 或 AWS 的 X-Amzn，那么改变 OTEL_PROPAGATORS 配置以包括这个额外的传播器。
如果 OpenTelemetry 最终要取代这些其他的追踪系统，我建议同时运行 trace-context 和额外的追踪传播器。这将使你在部署中逐步取代旧系统时，能够无缝地过渡到 W3C 标准。
部署本地收集器
虽然有些系统有可能只使用客户端，但通过在你的应用程序所运行的机器上添加一个本地收集器，可以改善你的操作体验。
运行一个本地收集器有许多好处，如图 7-1 所示。收集器可以生成机器指标（CPU、RAM 等），这是遥测的一个重要部分。收集器还可以完成任何需要的数据处理任务，如从追踪和日志数据中清除 PII。
运行收集器后就可以将大多数遥测配置从你的应用程序中移出。遥测配置通常是特定的部署，而不是特定的应用。SDK 可以简单地设置为使用默认配置，总是将 OTLP 数据导出到预定义的本地端口。通过管理本地收集器，运维可以在不需要与应用程序开发人员协调或重新启动应用程序的情况下进行配置更改。在通过复杂的 CI/CD（持续集成 / 持续交付）管道移动应用程序时，这尤其有帮助，因为在不同的暂存和负载测试环境中，遥测需要不同的处理方式。
快速发送遥测数据到本地收集器，可以作为一个缓冲器来处理负载，并确保在应用程序崩溃时，缓冲的遥测数据不会丢失。
部署收集器处理器池
如果你的本地收集器开始执行大量的缓冲和数据处理，它就会从你的应用程序中窃取资源。这可以通过部署一个只运行收集器的机器池来解决，这些机器位于负载均衡器后面，如图 7-2 所示。现在可以根据数据吞吐量来管理收集器池的大小。
本地收集器现在可以关闭其处理器以释放资源。它们继续收集机器级遥测数据，作为来自本地应用程序的 OTLP 的转发机制。
添加额外的处理池
有时，单个收集器池是不够的。一些任务可能需要以不同的速度扩展。将收集器池分割成一个更专门的池的管道，可能允许更有效和可管理的扩展策略，因为每个专门的收集器池的工作负载变得更可预测。
一旦你达到了这个规模，就没有什么部署的问题了。大规模系统的专门需求往往是独特的，这些需求将驱动你的可观测性管道的拓扑结构。利用收集器提供的灵活性，根据你的需求来定制每一件事情。我建议对每个收集器配置的资源消耗进行基准测试，并使用这些信息来创建弹性的、自动扩展的收集器池。
用收集器管理现有的遥测数据
上面描述的路线图适用于上线 OpenTelemetry。但你应该如何处理现有的遥测？大多数运行中的系统已经有了某种形式的指标、日志和（可能有）追踪。而大型的、长期运行的系统往往最终会有多个遥测解决方案的补丁。不同的组件可能是在不同的时代建立的，有些组件可能是从外部继承的，比如收购。从可观测性的角度来看，这可能会导致混乱的局面。
即使在这样复杂的遗留情况下，仍然有可能过渡到 OpenTelemetry，而不需要停机或一次重写所有的服务。秘诀是首先部署一个收集器，作为一个透明的代理。
在收集器中，为接收你的系统目前产生的每一种类型的遥测设置接收器，并与以完全相同的格式发送遥测的导出器相连。一个 StatsD 接收器连接到一个 StatsD 导出器，一个 Zipkin 接收器连接到一个 Zipkin 导出器，以此类推。这种透明的代理可以逐步推出，而不会造成干扰。一旦所有的远程测量都由这些收集器来调解，就可以引入额外的处理。甚至在你把你的仪表切换到 OpenTelemetry 之前，你可能会发现这些收集器是管理和组织你当前拼凑的遥测系统的一个有用的方法。图 7-3 显示了一个收集器处理来自各种来源的数据。
为了开始将服务切换到 OpenTelemetry，可以在收集器上添加一个 OTLP 接收器，与现有的导出器相连。随着服务转向使用 OpenTelemetry 客户端，它们将 OTLP 发送到收集器，收集器将把 OTLP 翻译成这些系统以前产生的相同数据。这使得 OpenTelemetry 可以由不同的应用团队逐步上线，而不会出现中断。
转移供应商
一旦所有的遥测流量都通过收集器发送，切换到一个新的可观测性后端就变得很容易了：只需在收集器中添加一个导出器，将数据发送到你想尝试的新系统，并将遥测数据同时发送到旧系统和新系统。通过向两个系统发送数据，你创造了一个重叠的覆盖范围。如果你喜欢新系统，你可以在一段时间后让旧系统退役，以避免在可视性方面产生差距。图 7-4 说明了这个过程。
也可以使用 OpenTelemetry 在多个供应商之间进行测验。你可以同时向多个系统发送遥测信息，并直接比较系统，看哪一个最适合你的需要。