trace vs log

[Johan Jian An Sim]

This may not be a Go only question. But would like to know what is the appropriate use cases for golang.org/x/net/trace vs log?

[David Symonds]

The trace package groups events for individual requests, bucketing
them by time taken (and active traces and ones that finish with an
error). The log package is a single process-wide stream.

[Johan Sim]

Thanks, David.

That part seems to be pretty clear to me now. So I would say trace is recommended for 'logging' for a single request and logging is for process-wide. However, can we save the trace log to somewhere for achieving purpose as of now?

[David Symonds]

Traces aren't kept, and are really only meant for live-debugging of an
active server. They aren't intended for archival purposes.

[Matthew Sackman]

On Fri, Jan 22, 2016 at 02:15:29AM +0000, Johan Sim wrote:
> That part seems to be pretty clear to me now. So I would say trace is
> recommended for 'logging' for a single request and logging is for
> process-wide.

Apologies for the slight hijacking of this, but I think this is related:

If a request goes through several different go-routines as necessary to
service it, it would be quite neat to group all those actions together.
I have been thinking about creating one logger per request. This would
make it much easier to see the entire path a single request goes through
rather than what I have currently which is that logging is done per
go-routine/service rather than per request. Is this a case where tracing
is better suited?

I'm thinking more of the Erlang tracing stuff where a particular message
gets tagged with a magic value and then any process that creates and
sends a message in response to receiving a tagged message also has that
message tagged. That way you can see the entire rippling chain of events
caused by the first tagged msg.

Matthew

[Brad Fitzpatrick]

This is what we use the Context type for: https://godoc.org/golang.org/x/net/context

It's explicit rather than automatic. That might seem annoying, but in practice we've found that automagic inference of trace contexts using things like thread locals just doesn't really work. It works for the common case and people think it's neat, but then somebody does something tricky and doesn't know how to do the explicit trace wiring (because they've never done it), and then it's broken when they (or worse: another team, or the new maintainer) tries to go debug things months later. I've been guilty of crappy trace wiring in both C++ and Java, falling into the trap of thinking I don't need to think about it.

But if you make it explicit from the beginning, then everybody knows how to do it (the ctx is always there, making itself known) and when somebody does something tricky cross threads, they're very aware of the context.