OTEL Collector使用OTLP/HTTP Exporter报400错误求助

核心矛盾点梳理 #

当前问题存在几个关键矛盾：curl请求能正常访问自定义exporter，但OTEL Collector导出持续报400；已设置compression: none，但exporter仍收到编码格式请求体，触发SerdeError解析失败。以下是针对性排查步骤：

1. 校验OTLP Exporter协议配置 #

OTEL Collector的OTLP exporter默认使用gRPC协议发送二进制数据，如果你的自定义exporter仅支持HTTP/JSON或HTTP/Protobuf格式，就会出现解析失败。而curl请求通常用的是HTTP协议，这就解释了两者的差异。

• 检查配置是否显式指定协议：

exporters:
  otlp/custom:
    endpoint: "你的自定义exporter地址"
    protocol: http/json  # 或http/protobuf，需匹配自定义exporter支持的格式
    compression: none
    headers:
      # 你的请求头配置

• 若自定义exporter仅接受JSON格式，必须指定protocol: http/json，否则gRPC的二进制数据会被误判为编码请求体，触发Serde解析错误。

2. 确认压缩配置的全局生效性 #

部分OTEL Collector版本中，全局配置会覆盖exporter级别的压缩设置，需检查两处：

• 全局telemetry配置：

service:
  telemetry:
    metrics:
      compression: none  # 避免全局强制压缩

• Batch处理器配置：如果使用了batch处理器，其压缩设置也会影响最终请求：

processors:
  batch:
    send_batch_max_size: 1024
    send_batch_size: 512
    compression: none  # 此处需同步设为none

3. 捕获并对比请求细节 #

通过抓包或开启Collector debug日志，对比curl和Collector发送的请求差异：

• 开启Collector debug日志：

service:
  telemetry:
    logs:
      level: debug

从日志中重点查看：

• 请求的Content-Type是否匹配自定义exporter要求（比如application/json或application/x-protobuf）
• 请求体的实际格式，确认是否为OTLP标准格式
• 请求头是否与curl一致，是否存在Collector自动添加的额外头（如Accept-Encoding）导致解析异常

4. 验证自定义Exporter的解析逻辑 #

若以上配置均无问题，需检查自定义exporter本身：

• 确认exporter是否正确处理Content-Length头，避免因请求体截断触发SerdeError
• 检查exporter是否兼容OTLP标准数据结构，如果自定义exporter期望非标准格式，需用Collector的transform处理器修改数据：

processors:
  transform:
    logs:
      statements:
        - context: log
          statements:
            - set(body.attributes.custom_key, body.attributes.otel_key)  # 按需调整字段映射

内容的提问来源于stack exchange，提问作者SRJ