4. OTLP 协议详解：gRPC 与 HTTP 传输方式、Protobuf 序列化、批处理与压缩机制

OTLP（OpenTelemetry Protocol）是 OpenTelemetry 项目定义的规范，用于在 Collector 与 SDK、Collector 与 Collector 之间传输遥测数据。本章深入剖析 OTLP 的传输层协议、序列化方式以及性能优化机制，帮助你在实际部署中做出正确的协议选择与配置决策。

4.1 OTLP 协议概览

OTLP 支持两种传输协议：gRPC 和 HTTP。两者均使用 Protobuf 作为序列化格式，但在传输模型、流控机制和适用场景上存在显著差异。

4.2 gRPC 传输方式

gRPC 是 OTLP 的首选传输协议，也是 OpenTelemetry 社区推荐的生产环境方案。它基于 HTTP/2 构建，天然支持双向流、多路复用和头部压缩。

4.2.1 gRPC 的核心优势

• 双向流（Bidirectional Streaming）：客户端与服务端可以同时发送和接收数据，适合大规模遥测数据的持续上报。
• 协议缓冲区（Protobuf）原生支持：gRPC 与 Protobuf 深度集成，序列化/反序列化零额外开销。
• 内置流控（Flow Control）：HTTP/2 的流控机制防止接收端被淹没，保障背压（Backpressure）能力。
• 元数据传递：支持通过 gRPC metadata 传递认证令牌、租户 ID 等上下文信息。

4.2.2 gRPC 服务定义

OTLP gRPC 服务定义在 opentelemetry-proto 仓库中，核心 RPC 方法如下：

service TraceService {
  rpc Export(ExportTraceServiceRequest) returns (ExportTraceServiceResponse) {}
}

service MetricsService {
  rpc Export(ExportMetricsServiceRequest) returns (ExportMetricsServiceResponse) {}
}

service LogsService {
  rpc Export(ExportLogsServiceRequest) returns (ExportLogsServiceResponse) {}
}

每个 Export RPC 均支持 Unary（单次请求-响应）和 Client Streaming（客户端流）两种模式。生产环境中通常使用 Client Streaming 模式，将多个批次的数据合并到一个流中发送。

4.3 HTTP 传输方式

OTLP/HTTP 是 gRPC 的轻量级替代方案，适用于无法使用 gRPC 的环境（如浏览器端、受限网络环境）。它使用标准的 HTTP POST 请求，请求体为 Protobuf 编码的二进制数据。

4.3.1 HTTP 传输特点

4.3.2 HTTP 请求格式

OTLP/HTTP 使用 Content-Type: application/x-protobuf 或 application/json。请求路径固定为：

POST /v1/traces
POST /v1/metrics
POST /v1/logs

请求体为 Protobuf 序列化的 ExportRequest 消息。响应体为 ExportResponse，包含 partial_success 字段用于部分失败处理。

4.4 Protobuf 序列化机制

Protobuf（Protocol Buffers）是 Google 开发的二进制序列化格式，OTLP 选择它作为数据序列化层。理解 Protobuf 的编码原理对性能调优至关重要。

4.4.1 Protobuf 编码核心特性

• Varint 编码：整数使用变长编码，小数值占用更少字节。例如，值 1 仅占 1 字节，值 300 占 2 字节。
• 字段编号（Field Number）：每个字段使用 1-15 编号时仅占 1 字节 tag，16-2047 占 2 字节。将高频字段放在 1-15 可减少序列化体积。
• 默认值省略：字段值为默认值时（如 int32 的 0、string 的 ""），序列化时完全省略该字段。
• 嵌套消息：支持消息嵌套，但嵌套层级过深会增加解析开销。

4.4.2 OTLP 数据模型中的 Protobuf 优化

OpenTelemetry 的 Protobuf 定义针对遥测数据做了专门优化：

// 示例：Span 的简化定义
message Span {
  // 高频字段使用 1-15 编号
  bytes trace_id = 1;
  bytes span_id = 2;
  string name = 4;
  int32 kind = 14;  // 使用 varint 编码

  // 低频字段使用 16+ 编号
  repeated KeyValue attributes = 17;
  repeated SpanEvent events = 18;
  repeated SpanLink links = 19;

  // 时间戳使用固定64位，避免浮点误差
  fixed64 start_time_unix_nano = 15;
  fixed64 end_time_unix_nano = 16;
}

4.5 批处理机制

批处理（Batching）是 OTLP 性能优化的第一杠杆。将多个 Span/Metric/Log 合并到一个 ExportRequest 中，可以显著减少网络往返次数和协议开销。

4.5.1 批处理参数

4.5.2 批处理流程

下图展示了 OTLP 导出器内部的批处理工作流：

4.6 压缩机制

压缩是 OTLP 性能优化的第二杠杆。Protobuf 序列化后的数据已经比 JSON 小很多，但通过压缩可以进一步减少网络传输量。

4.6.1 支持的压缩算法

4.6.2 压缩配置示例

在 OpenTelemetry Collector 的导出器配置中启用压缩：

exporters:
  otlp:
    endpoint: "collector.example.com:4317"
    compression: "zstd"  # 可选: gzip, zstd, snappy, none
    tls:
      insecure: false
    sending_queue:
      queue_size: 5000
    retry_on_failure:
      enabled: true
      max_elapsed_time: 60s

在 SDK 导出器配置中：

// Go SDK 示例
exporter, err := otlptracegrpc.New(
    ctx,
    otlptracegrpc.WithEndpoint("collector.example.com:4317"),
    otlptracegrpc.WithCompressor("gzip"),  // 启用 gzip 压缩
)

4.7 传输方式选择决策树

以下决策树帮助你根据实际场景选择最合适的传输方式：

4.8 性能对比与调优总结

以下表格汇总了不同传输方式与压缩组合在典型场景下的性能表现：