[golang] 在 golang 项目中如何使用 requestId 来追踪请求的调用栈

@maxwellz 没辙啊，顶多封几个 error util ，go 标准库的 error ，就是会丢上下文。
或者 fmt.Errorf 的时候，打印日志。

@Corrots 这里有两个问题：
一是对实际情况来说采样率开不开到 100%只是采样，和埋点没有啥关，这里和性能应该也扯不上关系。
二是对性能的影响需要有数据来论证，并且是结合楼主实际业务的。比如添加了这些埋点后，性能指标有什么变化？

另外对性能影响的大小是由埋点决定的，那么也就是说具体对性能的影响是可控的，因此楼主使用时根据实际情况埋点即可。

这里衍生出来的问题则是，你的服务真的对性能有那么高的要求吗？如果是，那么你的这个服务的业务逻辑本身就应该是很薄很简单的，而不是柔和了一大坨逻辑在里面。
如果说逻辑本身就很简单很薄，那么埋点数量也必然不需要很多。
如果逻辑本身就很复杂，那么应该讨论的是本身埋点造成的耗时与原本的业务耗时的比例，这个比例我理解也不会高。

最后对于楼主的项目连 OTEL 这类基础设施都没有，要么就是历史久远，要么就是不重要。不重要的概率应该更大，因此这里引入 OTEL 我觉得也不会有什么问题。

一般使用了 opentelemetry 协议+ 实现了协议的框架都可以做到。

目前主流协议： https://opentelemetry.io/
使用的框架，比如： https://github.com/go-eagle/eagle

框架只要把一些常用组件支持 opentelemetry 协议即可，比如
- HTTP Client
- HTTP Server
- 日志
- 数据库
- Redis
- 函数追踪
- gRPC

当前服务和上下游服务都接口后即可追踪到，示例：

更多可以查看： https://go-eagle.org/docs/component/tracing/component

我自己的 gin 框架 https://github.com/fanqingxuan/go-gin 与 3 楼说的一致，但是我没有考虑微服务，毕竟绝大多数没必要使用微服务

func TraceId() gin.HandlerFunc {
return func(ctx *gin.Context) {
ctx.Set(traceid.TraceIdFieldName, traceid.New())
ctx.Next()
}
}

上面的图片没显示出来，补个图

https://imgur.com/CGezrDx

又没出来，继续补，两种，看哪种可以出来：



[img][/img]

@Corrots 也不是这么绝对，看服务的流量大小，如果小可以全开，大的话就像你说的，需要采样了，不然成本太高

之前用了 opentelemetry ，用 jaeger all in 卡的要死，还经常挂然后都丢了，用户量不大的，感觉得正常分组件部署，先不用多服务链路追踪了，手搓了一个简单的日志版链路追踪，不用依赖 jaeger 上报直接写入日志就完事了

服务内就用 context ，然后需要日志自己封装下。我们应用不管什么时候打印日志，默认会打印 traceId ，后续不用手动指定。类似下面这种格式。
time="2025-01-24 19:47:46.670" level=INFO source=xxx.go:36 msg="host[127.0.0.1] GET /ping" trace_id=e6cde54e22f944d8 fullPath=/ping