Deno中OpenTelemetry自动插桩连接OTEL Collector遭拒绝问题排查

针对你遇到的Deno OpenTelemetry自动插桩连接拒绝问题，结合你的配置和测试情况，以下是可能的原因及对应的解决步骤：

1. 协议不匹配：Deno默认使用gRPC，Collector仅开启HTTP协议 #

Deno的--unstable-otel自动插桩默认采用gRPC协议与OTLP端点通信（默认端口4317），但你的Collector配置仅开启了OTLP HTTP协议（端口4318），且Cloudflare Tunnel仅转发到4318端口。当Deno尝试通过gRPC连接时，隧道无对应端口转发，直接触发连接拒绝错误。

解决步骤：
添加环境变量指定使用HTTP/Protobuf协议：

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

此配置会让Deno以HTTP协议发送OTLP数据，匹配Collector的HTTP端点配置。

2. Collector未配置Trace/Metric处理流水线 #

你的Collector配置仅定义了logs流水线，但Deno自动插桩默认会发送**链路追踪（Traces）和指标（Metrics）**数据。虽然这不会直接导致连接拒绝，但会造成数据丢失，同时建议补全流水线以支持全量数据：
修改otel-connector-config.yaml的service.pipelines部分：

service:
  telemetry:
    logs:
      level: "debug" 
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

3. Docker容器端口映射缺失 #

Collector运行在Docker容器中，需确保容器的4318端口已映射到宿主机，否则Cloudflare Tunnel无法访问容器内部端口。启动Collector容器时需添加端口映射参数：

docker run -p 4318:4318 -v ./otel-connector-config.yaml:/etc/otelcol-contrib/config.yaml otel/opentelemetry-collector-contrib

同时确认Cloudflare Tunnel的目标地址为宿主机的4318端口（而非容器内部的otel-connector:4318，除非Tunnel与Collector容器在同一Docker网络且能解析容器名）。

4. Deno网络权限限制 #

Deno默认限制外部网络访问，需确保启动命令中允许访问otel.mydomain.com：

deno run --unstable-otel --allow-net=otel.mydomain.com your-server.ts

若未指定网络权限，Deno会阻止外部请求（虽错误信息通常为权限错误，但仍需排查）。

额外验证步骤 #

• 用curl测试OTLP HTTP端点的具体路径，确认数据能正常提交：

  curl -X POST https://otel.mydomain.com/v1/traces \
    -H "Content-Type: application/x-protobuf" \
    -H "X-OTel-Export-Protocol: http/protobuf" \
    --data-binary @trace-data.proto
  

  （此测试需准备符合OTLP格式的Protobuf数据，若返回200/202则说明端点正常）
• 查看Collector的debug日志，确认是否有连接请求到达：

  docker logs <collector-container-id>
  

  若日志中无Deno的连接记录，说明请求未到达Collector，需重点排查Cloudflare Tunnel或Deno的网络配置。

内容的提问来源于stack exchange，提问作者andreas.teich