> All of these things have been solved already. I mean...yes, that's how I was able to highlight the benefits of having a single log message per request. > Ju

> All of these things have been solved already. I mean...yes, that's how I was able to highlight the benefits of having a single log message per request. > Just look into log4j: mdc/ndc to include context (user/session), include the thread name in your pattern and use an async appender to take care of performance. At a glance this looks like it will still produce 1 log line per logging call, versus buffering with the request. adding the thread id just helps stitch them together after the fact. This doesn't get rid of any performance overhead -- it may get it out of the way of a user request, but it's still there under the hood. In the go case, using the runtime/trace library as an example[0], a `context.Context` is passed down the call stack which gets decorated with trace spans/regions/log messages on the way down. At the end of a task, all of the collected context gets written to the active trace log. [0] https://pkg.go.dev/runtime/trace https://pkg.go.dev/runtime/trace