【可观测性系列】 OpenTelemetry Collector的部署模式分析

🎬作者简介：大家好，我是蓝胖子🥇

☁️博客首页：主页蓝胖子的编程梦
⭐️热门专题：我的服务监控实践 ，500行代码手写Docker

**🌄每日一句：白日莫闲过，青春不再来

大家好，我是蓝胖子，在前面我介绍了下OpenTelemetry的概念，但是究竟在项目中应该如何来使用OpenTelemetry 来帮助我们完成可观测性的构建？接下来，我将会谈谈有关 OpenTelemetry如何落地的一些问题。

这一节我们来看看OpenTelemetry Collector 的部署模式，OpenTelemetry Collector 是OpenTelemetry 项目中的一个代理软件，作为遥测数据(也就是日志，指标，trace数据)的中转站，能够对遥测数据做一些预处理的逻辑。

不使用OpenTelemetry Collector

OpenTelemetry Collector 并不是必须的，我们可以直接使用OpenTelemetry 客户端SDK发送遥测数据到监控组件中，比如将trace数据发送到jaeger，发送metric数据到prometheus。部署模式如下图所示，

代理模式部署

如果要使用OpenTelemetry Collector 对遥测数据的预处理功能，则需要在应用程序和后端监控组件之间部署上OpenTelemetry Collector，OpenTelemetry Collector和应用程序之间是通过OTLP协议传输遥测数据，这个协议是OpenTelemetry 客户端SDK封装好的。

但这种模式有个问题，如果应用程序产生的遥测数据太多，一个OpenTelemetry Collector 已经不能满足快速处理数据的要求，那应该怎么办呢?

集群网关模式

这就要提到第三种部署模式，集群网关模式部署OpenTelemetry Collector ，如下图所示，通过在多个OpenTelemetry Collector 前面部署一个拥有负载均衡功能的OpenTelemetry Collector 来让分发发往整个集群的遥测数据。

负载均衡的策略一般也是按trace id去划分，这样同一个请求轨迹的trace数据会被同一个OpenTelemetry Collector所处理，这对于某些类型的Collector中的处理器而言非常重要，比如后置采样处理器( Tail Sampling processor) ，它需要分析完整的trace链才能决定该条trace数据是否应该被采样。

从OpenTelemetry Collector导出遥测数据的功能是其组成部分之一exporter完成的，社区目前已经有现成的exporter可以配置在Opentelemetry Collector里，Trace ID/Service-name aware load-balancing exporter ，通过该exporter将遥测数据分发到Opentelemetry Collector集群里，在集群节点中做复杂的过滤清洗遥测数据的工作，在负载均衡网关Collector节点上，只做简单的分发操作。