寻找用于记录的调用或线程ID

fro*_*rik 11 logging go

我正在重新编写用golang编写的小型Web应用程序的日志记录.由于外部要求,日志已被隔离在一个地方,因此我们以后可能会在日志服务器中切换.(不是我的想法 - 我保证......)尽管如此,我们现在能够使用标准库的部分和我们传递的用户/会话结构来记录日期/时间,行号,用户和消息等常见内容.周围.

但是 - 这就是问题 - 在较低级别的方法中,为了记录而传递会话只是为了获取用户名是一种浪费.所以我想找一些其他的东西用来在日志文件中找到一个特定的请求.我确信有一些我没有想到的明显的东西.

目前为止的想法:

  • Java日志记录框架可以打印出线程ID,在这种情况下也是如此.只是它在golang中被称为其他东西?
  • 以某种方式使用户/会话结构事物可以全局访问.(仍然需要传递会话ID,除非有一个线程用作查找键.回到想法编号1.)
  • 无论如何,放弃并传递用户/会话结构.
  • 不要在最低级别上记录错误,但仅在用户/会话结构可用时才记录.但行号不会那么好.

我们使用大猩猩的部分用于网络事物,除了主要是标准库.

关于这个的建议和想法?

rog*_*rog 15

由于滥用的可能性很高,因此无法在Go中访问当前goroutine的标识符.这看起来似乎很严苛,但这实际上保留了Go包生态系统的一个重要特性:如果你开始一个新的goroutine做某事并不重要.

也就是说,对于函数F的任何方法:

F()
Run Code Online (Sandbox Code Playgroud)

几乎完全等同于:

done := make(chan struct{})
go func() {
   defer close(done)
   F()
}
<-done
Run Code Online (Sandbox Code Playgroud)

("差不多"来自这样一个事实:如果F恐慌,恐慌将不会被原始的goroutine捕获).

这也适用于日志记录 - 如果您使用当前goroutine来推断当前用户,那么任何启动上述goroutine的代码都会破坏该假设,并且您的日志记录将不包含预期信息.

你需要传递一些上下文.

  • 恕我直言"滥用的可能性很大"有点可疑.它首先需要枚举Go例程. (7认同)
  • 在查看日志行时有 100% 合理的理由需要了解 go 线程,因为混合的日志行可能会混淆逻辑。大多数人通过在线程中使用的结构上使用某种唯一的 id 来解决这个问题。除非该语言提供完整的线程安全性,否则某些东西是否在线程中运行很重要,并且任何意识形态立场都不会改变这一点。 (3认同)