ES 超时未生效

OpenTelemetry Collector 的 Elasticsearch exporter 已设置 timeout，HTTP 请求却超过这个时间还在等待。使用 contrib 0.158.0 或 0.159.0 时，要核对一次已确认的客户端超时回归，而不是继续增加超时值。

参数设在了未使用的客户端上

受影响实现会按配置创建一个 http.Client，随后只把它的 Transport 交给 Elasticsearch 客户端。http.Client.Timeout 是客户端的请求期限，不是 Transport 自带的属性；只转交 Transport，原期限没有随之生效。

因此配置能被解析，文件里的 timeout 也不是零，却仍可能没有给实际 HTTP 请求设置这份期限。队列等待、batch 的 flush 时间和 HTTP 请求时间应分别观察，不能把从入队到导出的全部耗时都当成一次网络请求。

采用完整修复

正式 contrib 0.160.0 已包含该项修复，核对的 0.162.0 也有相同实现。升级时使用项目相容、包含 Elasticsearch exporter 的完整发行版，保留原 endpoint、TLS、认证、pipeline 及队列配置。

修复会为每次实际 HTTP 请求设置独立的超时上下文，并让它覆盖响应正文的读取。早期未发布的修复曾在收到响应头后就取消上下文，导致随后读取正文出现 EOF；不要只移植“增加 context 超时”的前半段改动。

如果沿用五秒的项目期限，已有 exporter 中的字段形式是：

timeout: 5s

这是局部字段示例，不是完整 exporter 配置，也不是所有项目的推荐值。数值应按真实服务与网络需求选定；零表示不设置这份请求期限，不能用零来解决“配置被忽略”。

分别检查慢头和慢正文

在隔离的接收端验证两种情况：迟迟不返回响应头，以及迅速返回头部、但缓慢发送正文。前者应受期限约束，后者在期限以内仍应读完，不能因头部已经返回就被提前取消。

同时检查正常 bulk 写入、失败记录及队列状态。修复后真正的超时会开始到达原有错误处理路径，重试与队列策略需要能处理它；整个导出过程还可能包含排队、退避和其他可重试结果，不保证总耗时等于一个 timeout。

客户端超时也不证明服务端没有写入。需要重送日志或数据时，沿用文档 ID、幂等与重复处理约定，不能因为得到超时错误就无条件重放所有批次。已经采用修复版本仍有等待问题，再依据实际网络请求、队列和服务端响应定位。