OpenTelemetry的序列化器如何与现有的监控系统集成

OpenTelemetry（OTel）是一个开源的可观测性框架，旨在提供跨分布式系统的标准化遥测数据收集和传输。它的序列化器在与现有监控系统集成时发挥着关键作用，确保数据能够以兼容的格式被发送和接收。以下是关于OpenTelemetry序列化器如何与现有监控系统集成的详细分析。

一、OpenTelemetry序列化器概述

OpenTelemetry的序列化器负责将遥测数据转换为适合传输和存储的格式。它支持多种数据格式，包括JSON、Protocol Buffers等，这些格式在可观测性领域中被广泛使用。序列化器的选择会影响数据的传输效率、存储需求以及与现有监控系统的兼容性。

二、与现有监控系统集成的方式

1. 使用导出器

OpenTelemetry提供了一系列导出器，支持导出遥测数据的不同协议和格式，这允许用户将OpenTelemetry与其首选的监控和分析工具无缝集成。例如，OpenTelemetry协议(OTLP)导出器专为OpenTelemetry数据模型设计，能够无损地发出OTel数据，并且许多处理遥测数据的工具都支持OTLP（如Prometheus、Jaeger以及大多数供应商），这在需要时为用户提供高度的灵活性。

2. 支持多种数据类型

OpenTelemetry的数据类型包括指标（Metrics）、日志（Logs）和追踪（Traces）。这些数据类型可以帮助理解问题是什么以及在哪里发生，而追踪数据（Traces）则有助于关联这些事件，以识别它们何时以及按什么顺序发生。这种数据类型的多样性使得OpenTelemetry能够与不同类型的监控系统集成，无论是侧重于指标监控的系统（如Prometheus），还是专注于日志分析的系统（如Elasticsearch），或者是擅长分布式追踪的系统（如Jaeger、Zipkin）等。

3. 兼容多种后端监控系统

OpenTelemetry支持广泛的后端和可视化工具，方便与现有的监控生态系统集成。例如，使用Prometheus进行监控的组织可以合并OpenTelemetry来获取额外的可观测性数据；EMQX通过设置OpenTelemetry Collector并在EMQX中启用和配置OpenTelemetry追踪集成，实现了与OpenTelemetry追踪的集成，使得系统管理员或开发人员可以实时监测和分析物联网应用的性能和行为，并在出现故障时快速定位并排除故障。

4. 无侵入注入（部分场景）

如果适用，OpenTelemetry特定语言的实现提供了一种无需修改源代码即可监测应用程序的方法。虽然底层机制取决于所使用的语言，但零代码监测会为应用程序添加OpenTelemetry API和SDK的功能。它还可能添加一套监测库和导出器依赖项。这种方式使得在不改变现有监控系统架构和应用程序代码的基础上，能够轻松集成OpenTelemetry的功能。

三、集成实例

以EMQX与OpenTelemetry追踪集成为例，其步骤如下：

1. 设置OpenTelemetry Collector

创建OpenTelemetry Collector配置文件`otel

trace – collector – config.yaml`：

yaml

receivers:

otlp:

protocols:

grpc:

exporters:

otlp:

endpoint: jaeger:4317

tls:

insecure: true

processors:

batch:

extensions:

health_check:

service:

extensions: [health_check]

pipelines:

traces:

receivers: [otlp]

processors: [batch]

exporters: [otlp]

在相同目录下创建Docker Compose文件`docker

compose – otel – trace.yaml`：

yaml

version: ‘3.9’

services:

jaeger:

image: jaegertracing/all

in

one:1.51.0

restart: always

ports:

“16686:16686”

otel

collector:

image: otel/opentelemetry

collector:0.90.0

restart: always

command: [“–config=/etc/otel

collector

config.yaml”, “${OTELCOL_ARGS}”]

volumes:

-./otel

trace

collector – config.yaml:/etc/otel – collector – config.yaml

ports:

“13133:13133” 健康检查扩展

“4317:4317” OTLP gRPC接收器

depends_on:

jaeger

使用Docker Compose启动服务：

bash

docker compose

f docker

compose – otel – trace.yaml up

启动后，OpenTelemetry Collector将在主机的默认gRPC端口（4317）上监听，Jaeger WEB UI可以在`

2. 在EMQX中启用OpenTelemetry追踪

将以下配置添加到EMQX `cluster.hocon`文件中（假设EMQX在本地机器上运行）：

bash

opentelemetry {

exporter { endpoint = ” }

traces {

enable = true

是否追踪全部消息

如果无法从消息中提取追踪ID，则会生成一个新的追踪ID。

filter.trace_all = true

启动EMQX节点，例如，以节点名`.0.1`和`.0.1`启动一个有两个节点的集群，以展示分布式追踪功能。

使用MQTTX CLI作为客户端在不同节点和端口上订阅相同主题。

在`.0.1`节点上（默认MQTT监听器在端口1883）：

bash

mqttx sub

t t/trace/test

h localhost – p 1883

在`.0.1`节点上（监听器在端口1884）：

bash

mqttx sub

t t/trace/test

h localhost – p 1884

发布带有追踪上下文的消息，向主题发送包含有效`traceparent`用户属性的消息：

bash

mqttx pub

t t/trace/test

h localhost – p 1883 – up “traceparent: 00 – cce3a024ca134a7cb4b41e048e8d98de – cef47eaa4ebc3fae – 01”

大约5秒后（EMQX导出追踪数据的默认间隔），导航到` WEB UI观察追踪数据：

选择`emqx`服务并点击查找追踪。如果`emqx`服务没有立即出现，请稍等片刻后刷新页面。您应该看到消息追踪。

点击追踪查看详细的跨度信息和追踪时间线。

3. 管理追踪跨度过载（可选）

EMQX会积累追踪跨度，并定期批量导出它们。导出间隔由`opentelemetry.trace.scheduled_delay`参数控制，默认为5秒。批处理追踪跨度处理器包含过载保护机制，允许只积累到一定限制的跨度，该限制默认为2048个跨度。您可以使用以下配置设置此限制：

yaml

opentelemetry {

traces { max_queue_size = 2048 }

一旦达到`max_queue_size`限制，新的追踪跨度将被丢弃，直到当前队列被导出。

OpenTelemetry的序列化器通过多种方式与现有的监控系统集成，包括使用导出器、支持多种数据类型、兼容多种后端监控系统以及在部分场景下的无侵入注入等。这些集成方式使得OpenTelemetry能够在不破坏现有监控系统架构的前提下，为系统提供更全面、标准化的可观测性数据收集和传输能力，有助于提升系统的监控和分析能力，特别是在分布式系统中具有重要意义。随着技术的不断发展，未来OpenTelemetry可能会在与更多类型监控系统的集成上进行优化，并且可能会出现更多针对特定监控系统的集成方案和最佳实践。