一般的基础框架会封装的，实际是在 context 透传下去的。

@kingcanfish 打堆栈在生产环境可能会影响性能

现在不应该是 OpenTelemetry 了吗，Opentracing 前两年就被废弃了 ;-) 仅供参考： https://github.com/go-kod/kod/blob/main/interceptor/ktrace/trace.go https://github.com/go-kod/kod-ext/blob/main/core/otel/otel.go

刚好写了个插件，可以参考一下 https://github.com/simonlu9/log-alarm-spring-boot

一个服务内的多个实例的调用逻辑不也是走网络吗？我们这边是自己定义的网络协议，协议内部就预留请求 id 部分，没有则生成，有就直接使用，在日志打印出来，采集起来，就完事了。

说白了就是在请求链路记录 requestId,可以封装下日志,打印的时候带 requestId,这样排查问题就简单了,现在 go 的日志框架例如 zap 支持结构化日志,直接扔到 es 或者其他存储里也省事,省的解析了

@Ayanokouji #9 我也在用这个，但是有一个问题，有时候会忘，直接用 fmt.Errorf 或者 err 在某一层被设置为了其他类型的 err ，这种情况你是咋解决的，提供一个封装好的 error 模块嘛

现在肯定用 opentelemetry ，Opentracing 已经被废弃了

@FarmerChillax #17 正解，用 OTEL 才是对的，OpenTracing 和 OpenCensus 已经 Archived 了。

@Charlie17Li #2 OpenTracing 已经没了，用 OpenTelemetry 。