调试OpenTelemetry Collector的thrift_http以接收Tekton链路追踪

一、调试步骤 #

1. 抓取请求包分析细节 #

直接捕获Tekton发送到Collector的HTTP请求，确认请求格式是否符合Jaeger Thrift HTTP规范：

• 在K8s集群内用tcpdump抓包：

  kubectl exec -n otel <collector-pod-name> -- tcpdump -i any port 14268 -w /tmp/trace.pcap
  

  导出pcap文件后用Wireshark分析，重点检查：
  • 请求路径是否匹配Collector配置的接收器路径
  • 请求头Content-Type是否为application/x-thrift
  • 请求体是否为合法的Thrift二进制格式

2. 开启Collector调试日志 #

修改Collector配置，将日志级别设为debug，获取请求解析的详细错误：

service:
  pipelines:
    traces:
      receivers: [jaeger]
      processors: [batch]
      exporters: [your-exporter]
  logs:
    level: debug

重启Collector后，查看日志中关于jaeger.thrift_http接收器的请求处理日志，通常能找到400错误的具体原因（如格式解析失败、路径不匹配等）。

3. 用标准Jaeger客户端模拟请求验证 #

使用Jaeger官方的Thrift HTTP客户端发送测试请求，验证Collector接收器是否正常工作：

• 编写简单的测试代码或构造符合格式的curl请求，对比Tekton的请求差异，定位是否是Tekton的请求格式问题。

二、版本兼容排查 #

1. 检查Thrift协议路径兼容性 #

部分旧版本Jaeger客户端（对应Tekton使用的旧版依赖）会使用/v1/traces作为请求路径，而OpenTelemetry Collector的Jaeger接收器默认路径为/api/traces，这会导致400错误。

• 解决方案：
  要么修改Collector的Jaeger接收器配置，指定匹配的路径：

  receivers:
    jaeger:
      protocols:
        thrift_http:
          endpoint: 0.0.0.0:14268
          path: /v1/traces
  

  要么调整Tekton的追踪配置，将JAEGER_ENDPOINT环境变量改为http://app-to-kafka-collector.otel.svc.cluster.local:14268/api/traces（如果之前路径配置错误）。

2. 确认Thrift格式版本 #

Tekton可能使用了较旧的Jaeger Thrift IDL版本，与OpenTelemetry Collector的Jaeger接收器存在兼容问题：

• 检查Tekton的版本，查看其依赖的Jaeger客户端版本，对比OpenTelemetry Collector支持的Jaeger版本范围（Collector通常支持Jaeger v1.x及以上版本）。
• 如果Tekton使用的是非常老旧的Jaeger客户端，可能需要升级Tekton或添加中间适配层（如Jaeger Collector作为代理，先接收Tekton的请求再转发给OTel Collector）。

三、额外检查点 #

• 确认Collector的Jaeger接收器是否正确启用：检查Collector启动日志，确认jaeger.thrift_http接收器已成功加载并监听14268端口。
• 检查网络连通性：在Tekton的Pod内执行curl -v http://app-to-kafka-collector.otel.svc.cluster.local:14268/api/traces，确认能正常连接，排除网络或DNS问题。

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