mochengqian opened a new issue, #1077: URL: https://github.com/apache/dubbo-go-samples/issues/1077
## 问题描述 使用 `dubbo-go-samples` 验证 `dubbo.apache.org/dubbo-go/[email protected]` 时，`otel/tracing` 相关 sample 存在两个可复现问题： 1. Jaeger / OTLP HTTP tracing sample 中，RPC 调用成功，server span 可以被收集，但 client 进程退出前如果没有显式 `ForceFlush` / `Shutdown` tracer provider，client span 不会稳定导出。 2. `otel/tracing/otlp_http_exporter` README 指向的 integration 测试路径不存在；直接启动 server 时会等待预期 trace 数，最终 timeout / panic。 这会导致 samples 不能完整证明 client/server 双向 tracing 链路，也会让用户按 README 无法完成验收。 ## 环境与配置 - 代码库：`apache/dubbo-go-samples` - dubbo-go 依赖：`dubbo.apache.org/dubbo-go/[email protected]` - Go 版本：`go1.26.1 darwin/arm64` - 项目 `go.mod`：`go 1.25.0` - 操作系统：macOS 26.4.1 darwin/arm64 - samples： - `otel/tracing/jaeger` - `otel/tracing/otlp_http_exporter` - tracing backend： - Jaeger all-in-one - OTLP HTTP mock receiver - 协议覆盖： - Triple - Dubbo - JSONRPC ## 复现步骤 Jaeger 场景： 1. 启动 Jaeger all-in-one。 2. 启动 `otel/tracing/jaeger` server。 3. 多次运行 client。 4. 等待一段时间后查询 Jaeger service / trace。 5. 给 client 临时补充 tracer provider `ForceFlush` / `Shutdown` 后再次运行，对比 client trace 是否出现。 OTLP HTTP 场景： 1. 按 README 查找并运行 `otel/tracing/otlp_http_exporter/tests/integration`。 2. 发现 README 指向的 integration 路径不存在。 3. 直接运行 OTLP HTTP sample server。 4. 使用临时 client driver 分别调用 Triple / Dubbo / JSONRPC。 5. 对比 client shutdown 前后 OTLP mock receiver 收到的 span 数量。 ## 实际结果 Jaeger 场景中，RPC 调用成功，server trace 可以看到，但 client trace 为 0。给 client 临时加入 `ForceFlush` / `Shutdown` 后，client trace 可以出现。 OTLP HTTP 场景中，README 指向的 integration 路径不存在。补充临时 driver 验证后，观察到类似结果： ```text without client shutdown: dubbo_otel_server=4, dubbo_otel_client=0 with client shutdown: dubbo_otel_server=4, dubbo_otel_client=3 ``` 这说明协议调用本身可以成功，但 client span 依赖进程退出前的 flush/shutdown。与此同时，OTLP HTTP sample / mock count 逻辑仍可能因为等待固定 trace 数而 timeout / panic。 ## 预期结果 1. tracing sample 的 client 进程退出前应可靠 flush/shutdown，确保 client span 被导出。 2. Jaeger / stdout / OTLP HTTP sample 应能验证： - client span - server span - trace propagation - service.name - instrumentation metadata 3. `otel/tracing/otlp_http_exporter` README 中的 integration 路径应真实存在，用户可以按文档直接运行。 4. OTLP mock count 逻辑应与实际协议调用数量一致，不应在 RPC 成功后因为计数不匹配 timeout / panic。 ## 可能的原因 client 进程生命周期很短，如果 exporter 使用 batch processor 或异步导出，RPC 返回后立即退出可能丢失尚未 flush 的 client span。server 进程持续运行，因此 server span 更容易被观察到。 OTLP HTTP sample 还存在 README 与测试代码不一致的问题：README 期望 integration 测试存在，但实际路径缺失；mock trace 计数与多协议调用实际导出数量也没有对齐。 ## 可能的修复方法 1. 在 tracing client sample 中显式调用 tracer provider `ForceFlush` / `Shutdown`，或提供统一 helper。 2. 为 Jaeger / stdout / OTLP HTTP 增加集成断言： - client/server span count - trace id propagation - parent-child 或链路关联 - service.name - instrumentation metadata 3. 补齐 `otel/tracing/otlp_http_exporter` integration driver，覆盖 Triple / Dubbo / JSONRPC。 4. 修正 README 路径和 mock count 逻辑，使用户按文档执行不会 timeout / panic。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
