

Tagged Logging in Go - GarethX
http://blog.fogcreek.com/there-are-gophers-with-gifts-at-fog-creek/

======
tveita
SLF4J has two ways to do "tagged logging": markers that are passed per-call,
and a thread-local mapped diagnostic context (MDC). The latter is useful
because you can set it for an entire request and have it included even for
code that isn't explicitly aware of e.g. accounts.

Unfortunately Go doesn't have thread-local storage, so that feature may not be
feasable. (Except through ugly hacks:
[https://github.com/jtolds/gls](https://github.com/jtolds/gls))

------
jzelinskie
Wouldn't the signature of the tagged logging function be better if it was
something like:

    
    
         DebugWithTags(message string, tags ...string)
    

This way you could easily add tags without having to explicitly allocate a
[]string whenever you wanted to change them.

~~~
fizzbatter
Perhaps it depends on how much content you're putting into the message,
normally? Eg, big multi-line strings, followed by more args at the end, is not
a syntax i personally prefer.

With that said, i really do wish Go supported `DebugWithTags(tags ...string,
message string)` syntax. I've had so many cases where i wanted to use
something similar.

~~~
kornish
For the record, if the last argument of a Golang function is variadic, you can
still pass an array to it - you just have to transform the array into variadic
args by appending `...` to it. So adopting the type signature above could give
you the best of both worlds - the ability to use one-off tag combinations
inline, but also the ability to pass predefined arrays of tags.

------
radimm
similar structured logger
[https://github.com/Sirupsen/logrus](https://github.com/Sirupsen/logrus)

~~~
pquerna
I've used `logrus` in a couple projects and been pretty happy with it.

Easy to get rolling, easy to make chained loggers, and can do JSON in
production or pretty colors when in dev environment.

~~~
girishso
Ditto for me.

I have created a desktop app and use 'logrus' for logging locally and have
created a 'hook' to send logs to the server. Works pretty neat!

------
Omie6541
Please correct me if I have got this wrong or missed some code piece but you
are pushing log records to a buffered channel (incomingChannel) without making
sure that it has some space left. When that buffer of 2048 gets full, all the
next requests are going to get blocked. Even if you call .log() in the
background, there will be number of goroutines waiting to get their turn which
will lead the system to a state where you have no idea what is pending and
where.

here's a smaller version of the problem, notice how fillFoo() will have to
wait to push to the buffer.
[https://gist.github.com/Omie/52add99f6685dcb340a1](https://gist.github.com/Omie/52add99f6685dcb340a1)

there's also a similar problem (how they solved it) described here:
[http://pivotallabs.com/a-concurrent-ring-buffer-for-
go/](http://pivotallabs.com/a-concurrent-ring-buffer-for-go/)

------
inconshreveable
Did you evaluate log15? And if so, what did you find lacking about it?

[https://godoc.org/gopkg.in/inconshreveable/log15.v2](https://godoc.org/gopkg.in/inconshreveable/log15.v2)
[https://github.com/inconshreveable/log15](https://github.com/inconshreveable/log15)

