创建网格为什么会自动创建一个otel-collector工作负载？

问题描述

创建网格会自动创建一个otel-collector工作负载。

原因分析

ASM服务网格对接至集群后，会在命名空间monitoring下创建一个otel-collector工作负载。创建这个工作负载的原因是需要利用其对envoy收集遥测数据（trace、log、metric），并进行处理，导出到相应的后端，实现网格的可观测性。

otel-collector架构简介

图1 otel-collector架构图

如上图的架构图所示，otel-collector包含了四个模块：

• Receivers

  接收器Receivers是遥测数据进入otel-collector的方式，可以是推送或拉取。Receivers可以以多种格式接收遥测数据，例如上图中的OTLP、Jaeger、Prometheus格式。

• Processors

  处理器Processors用于处理Receivers收集到的数据，例如常用的batch处理器，用于对遥测数据进行批处理。

• Exporters

  导出器Exporters是将遥测数据发送到指定后端的方式，它帮助我们更好地可视化和分析遥测数据。

• Extensions

  扩展主要适用于不涉及处理遥测数据的任务。扩展是可选的，比如可以增加一个health_check的健康检查功能，获取有关Collector健康状况的信息。

otel-collector在ASM基础版网格中的使用

可通过以下命令获取otel-collector工作负载的配置信息：

以在基础版网格获取到的配置文件为例：

• receivers配置项定义了可以选择以zipkin、prometheus两种协议从envoy获取遥测数据，其中prometheus定义了以每15s的间隔从/stats/prometheus路径下抓取数据。

• processors配置项定义了batch、memory_limiter两种对数据处理的方式，分别是批处理和内存限制。

• exporters配置项定义了将处理过的遥测数据导出至apm服务器。

• extensions配置项定义了health_check扩展，其用于获取有关otel-collector健康状况的信息。

• service部分用于配置otel-collector实际会采用哪些上述定义好的配置项。

比如上述配置文件中service项，其配置了两个pipeline分别用于处理metrics数据和traces数据（注：一个pipeline是一组receivers, processors, 和exporters的集合），以及配置了logs输出级别为info及以上。其处理架构如下图所示。

图2 metrics、traces处理架构图

解决方法

无需处理。