Search for a call or thread id for logging

Question

I am re-registering our small web application written in golang. Due to external requirements, logging was isolated in one place, so we can turn on the log later. (Not my idea - I promise ....) Nevertheless, we can now register common things, such as date / time, line number, user and message, mainly using parts of the standard library and user / session structure that we pass around.

But - and here the question arises - in lower-level methods, wasting time on a session just to get a username for the sake of logging. So I would like to find something else to use one specific query in the log files. I am sure there is something obvious that I have not thought about.

Ideas so far:

• Java registration frameworks can print a stream identifier, and that would also be nice in this case. Just what is it called something else in golang?
• make the struct user / session structure accessible globally as soon as possible. (You also need to pass the session identifier if there is no stream as the search key. Return to idea number 1.)
• In any case, refuse and pass the user / session structure.
• Do not log errors at the lowest level, but only when the user / session structure is available. The line number will not be good though.

We use gorilla parts for websites and, in addition, it is mainly a standard library.

Suggestions and ideas about this?

Answer 1

Due to the high potential for abuse, there is no way to access the id for the current goroutine in Go. It may seem draconian, but it actually preserves an important property of the Go package ecosystem: it doesn't matter if you start a new goroutine to do something .

That is, for any method of the function F:

F() 

almost exactly equivalent:

 done := make(chan struct{}) go func() { defer close(done) F() } <-done 

(“Almost” assumes that if F is panic, the panic will not be captured by the original mount).

This also applies to logging - if you used the current version of goroutine to log out the current user, any code that launched the new goroutine as above will violate this assumption, and your log will not contain the expected information.

You will need to convey some kind of context.