JaegerOTLP通信故障排查指南

从现在开始，努力学习吧！本文《Jaeger OTLP通信失败排查与解决方法》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

本文详解在Docker自定义网络中，Python应用容器（C）向Jaeger all-in-one容器（J）发送OTLP traces时出现`DEADLINE_EXCEEDED`超时问题的根本原因——意外继承的HTTP/HTTPS代理环境变量，并提供可复现的验证方法与彻底解决方案。

在Docker多容器环境中，即使所有服务（如客户端C、SQL Server S、Jaeger J）共处于同一用户定义桥接网络（如 docker network create mynet），且IP可达性已通过 telnet 172.19.0.3 4317 验证成功，仍可能遭遇OTLP gRPC调用持续超时（StatusCode.DEADLINE_EXCEEDED）。这种“能连通但无法通信”的现象极具迷惑性，其根源往往不在网络配置本身，而在于容器运行时环境变量的隐式干扰。

关键线索在于：问题仅出现在容器内部（C → J），宿主机（VM）直连Jaeger完全正常；更反常的是，容器内DNS解析异常指向DigitalOcean公网IP段——这强烈暗示存在上游代理劫持行为。经排查确认，根本原因是构建C容器所用的Dockerfile中预设了如下环境变量：

ENV HTTP_PROXY=http://corporate-proxy:8080
ENV HTTPS_PROXY=http://corporate-proxy:8080
ENV NO_PROXY="localhost,127.0.0.1,172.16.0.0/12,192.168.0.0/16"

⚠️ 注意：NO_PROXY 虽已包含私有网段，但gRPC Python客户端（如 opentelemetry-exporter-otlp-proto-grpc）默认不遵循 NO_PROXY 环境变量（该行为由底层 grpcio 库决定，而非标准HTTP库）。因此，即使目标地址 172.19.0.3:4317 属于Docker内部子网，gRPC仍会尝试通过代理转发请求，而企业代理服务器拒绝处理非公网流量，最终导致连接挂起并超时。

✅ 正确解决方案分两步：

1. 构建阶段清除代理变量（推荐）：
   在Dockerfile中显式取消设置（注意顺序，需在RUN或CMD前生效）：

   # 移除代理变量（即使基础镜像已设置）
   ENV HTTP_PROXY=""
   ENV HTTPS_PROXY=""
   ENV NO_PROXY=""

2. 运行时强制覆盖（临时验证）：
   启动容器时通过 -e 参数覆盖：

   docker run -e HTTP_PROXY= -e HTTPS_PROXY= -e NO_PROXY= \
     --network mynet \
     your-python-app

? 进阶建议：

• 使用 opentelemetry-exporter-otlp-proto-http（基于HTTP/1.1）替代gRPC导出器时，NO_PROXY 将生效，可作为快速验证手段；
• 在Python代码中显式禁用代理（适用于无法修改Dockerfile的场景）：

  import os
  os.environ.pop("HTTP_PROXY", None)
  os.environ.pop("HTTPS_PROXY", None)
  os.environ.pop("NO_PROXY", None)
  # ⚠️ 必须在导入 opentelemetry.* 之前执行！

总结：Docker容器间通信故障不应先怀疑网络配置，而应优先检查环境变量污染。企业环境中预置的代理设置极易被忽视，却会静默破坏gRPC等非HTTP协议的本地通信。通过清除无关代理变量，并理解不同SDK对NO_PROXY的支持差异，即可快速恢复Jaeger分布式追踪链路。

终于介绍完啦！小伙伴们，这篇关于《JaegerOTLP通信故障排查指南》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！