Docker 容器 OTLP 追踪数据失败排查

本文揭示了在 Docker 自定义网络中，Python 应用（客户端容器）向 Jaeger all-in-one 容器发送 OTLP traces 时出现 `DEADLINE_EXCEEDED` 超时的根本原因——并非网络配置或 DNS 解析问题，而是被意外继承的代理环境变量干扰了本地容器通信。

在典型的多容器可观测性部署中，开发者常假设：只要容器共处同一自定义 Docker 网络（如 docker network create mynet），并使用固定 IP 或服务名（如 jaeger:4317）通信，OTLP gRPC 流量就应畅通无阻。然而，如案例所示，即使 telnet jaeger 4317 成功（证明 TCP 连通性正常）、宿主机可直连 Jaeger、且所有容器位于同一子网（如 172.19.0.0/16），Python 客户端仍可能持续报出：

Transient error StatusCode.DEADLINE_EXCEEDED encountered while exporting traces to 172.19.0.3:4317, retrying in 1s.

这一现象极具迷惑性——因为 TCP 层已通，但应用层（gRPC）却无法建立稳定连接。关键线索在于：该问题仅发生在容器内，宿主机和外部环境均无异常；且容器内域名解析意外指向 DigitalOcean 的公网 IP（而非预期的 172.19.x.x）。

根本原因并非网络策略或 DNS 配置，而是 代理环境变量（HTTP_PROXY、HTTPS_PROXY、NO_PROXY）的隐式生效。当 Dockerfile 中预设了全局代理（例如企业镜像构建时为拉取依赖而添加）：

ENV HTTP_PROXY=http://proxy.corp:8080
ENV HTTPS_PROXY=http://proxy.corp:8080
# ❌ 缺少或错误配置 NO_PROXY！

这些变量会被 Python 的 httpx、grpcio 等库默认读取。即使目标地址是私有 CIDR（如 172.19.0.3），若 NO_PROXY 未显式包含该网段或通配符（如 NO_PROXY="172.19.0.0/16,127.0.0.1,localhost"），gRPC 客户端仍会尝试通过代理转发请求——而代理服务器无法路由或响应本地 Docker 网络流量，最终导致连接挂起、超时重试，表现为 DEADLINE_EXCEEDED。

✅ 正确解决方案是在客户端容器启动时显式清除或修正代理变量：

# 推荐：在客户端 Dockerfile 末尾覆盖
ENV HTTP_PROXY=""
ENV HTTPS_PROXY=""
ENV NO_PROXY="127.0.0.1,localhost,172.16.0.0/12,192.168.0.0/16,10.0.0.0/8"

或在 docker run 时覆盖：

docker run --network mynet \
  -e HTTP_PROXY= \
  -e HTTPS_PROXY= \
  -e NO_PROXY="127.0.0.1,localhost,172.19.0.0/16" \
  my-python-app

⚠️ 注意事项：

• 不要依赖 telnet 成功即断定应用层可用——它仅验证 TCP 握手，不模拟 gRPC 协议栈行为；
• NO_PROXY 值必须使用逗号分隔，不支持空格，且需包含完整 CIDR 或具体 IP；
• 在 Python 应用中，也可通过代码强制禁用代理（适用于无法修改容器环境的场景）：

  import os
  os.environ.pop("HTTP_PROXY", None)
  os.environ.pop("HTTPS_PROXY", None)
  os.environ["NO_PROXY"] = "172.19.0.0/16,localhost,127.0.0.1"

总结：Docker 容器内跨网络通信失败，首要排查点不应是网络驱动或 iptables，而应检查 env | grep -i proxy 输出。企业环境中预置的代理配置极易“越界”影响本地流量，显式声明 NO_PROXY 是保障可观测性链路可靠的关键实践。