OpenTelemetry接入代理后最容易出现的误判，是应用日志显示“导出成功”，但观测后端没有数据。实际链路可能有两跳：应用SDK先把Trace、Metric和Log发给Collector，Collector再导出到托管平台。第一跳在内网直连，第二跳才经过代理；也有应用绕过Collector直接访问后端。排查前必须先画清路径。
一、常见的两种部署方式
| 方式 | 数据路径 | 代理重点 |
|---|---|---|
| SDK直发 | 应用到观测后端 | 应用进程、SDK导出器和TLS |
| 经Collector | 应用到Collector，再到后端 | Collector导出器、队列与后端认证 |
Collector模式便于集中处理、批量与凭据管理，但也增加一个需要监控的队列和网络边界。
二、OTLP HTTP与gRPC不能混为一谈
OTLP可以通过HTTP或gRPC传输。HTTP导出器更容易与普通HTTP代理配合；gRPC通常运行在HTTP/2上，代理需要正确支持CONNECT、TLS、长连接和HTTP/2行为。相同端点主机不代表两个协议使用相同端口和路径。
gRPC代理的协议检查可参考gRPC、HTTP/2与CONNECT排查。
三、先确认是谁读取代理配置
不同语言SDK、自动探针和Collector发行版对代理环境变量的支持可能不同。应用使用Java、Go或Node时，底层网络库也不同。不能把一个语言的配置复制给另一个运行时后默认生效；应结合版本文档，并从代理日志或授权测试端点验证实际连接。
四、端点配置错误常见在哪
- 把gRPC端口当作OTLP HTTP端口；
- 遗漏HTTP协议要求的路径；
- Collector监听回环地址，容器或Pod无法访问；
- 使用HTTPS端点却没有正确CA；
- 环境变量被服务管理器或容器覆盖；
- 租户请求头只配置在SDK，没有配置在Collector导出器。
五、407、401与UNAVAILABLE分别看哪里
407通常来自正向代理认证；401或403多半来自遥测后端的API Key、租户或权限；gRPC的UNAVAILABLE则还可能由DNS、CONNECT、TLS、后端不可用或连接重置引起。应记录协议、目标主机和发生时间，不要只保留最终一行错误。
六、Collector队列为什么很关键
后端短时不可用时，Collector可借助批处理、内存队列或受支持的持久队列缓冲。队列并非无限容量：若失败持续，数据会积压并消耗内存或磁盘。应监控接收、导出、失败、重试、队列长度和丢弃指标，而不是只看Collector进程存活。
七、重试要避免放大故障
连接超时、429和部分5xx适合按导出器规则退避重试；认证错误、证书错误和配置错误持续重试没有意义。应用SDK与Collector若同时高频重试，还会形成双层放大。应让Collector承担集中退避，并为应用端设置合理批处理和截止时间。
八、TLS错误应该从哪一跳查
应用到Collector可以是明文内网或TLS，Collector到外部后端通常应使用TLS。两跳证书链分别检查。Collector容器未安装企业CA时，宿主机浏览器正常也无效。不要通过长期跳过证书验证解决问题。
证书检查顺序见HTTPS代理证书错误排查。
九、遥测数据本身也有合规风险
Span属性、日志正文和资源标签可能包含用户标识、URL参数、数据库语句或内部主机名。代理只负责路径，不会自动完成数据最小化。应在SDK或Collector处理器中删除不需要的敏感字段，并限制调试导出器的使用时间。
十、一次可靠的验证怎么做
- 记录SDK、导出器和Collector版本；
- 确认OTLP协议、端点、端口与路径；
- 分别验证应用到Collector、Collector到后端；
- 区分407、后端认证、TLS与429；
- 制造少量测试Span并用唯一标识查询；
- 短时阻断后端，观察队列与恢复；
- 检查日志没有令牌和敏感属性。
十一、结论
OpenTelemetry代理问题应按数据跳数和协议排查。先确认OTLP HTTP还是gRPC，再观察Collector导出队列、重试和后端响应，才能判断遥测究竟卡在应用侧、Collector还是代理之后。
