<p>I came from Java and fell in love with log4j.</p>
<p>i.e the class names and levels in the log entries etc</p>
<p>Now I'm looking for a nice go library, any suggestions?</p>
<p>If you are going to say standard logger please include examples of how you use it please</p>
<p>Edit: So it looks like logrus has the biggest following here,</p>
<p>followed closely by log15</p>
<hr/>**评论：**<br/><br/>tjholowaychuk: <pre><p><a href="https://github.com/Sirupsen/logrus">https://github.com/Sirupsen/logrus</a> is pretty nice, I'd certainly recommend sticking with structured logging personally. I dislike the "hooks", just because I think it's much more elegant write to stdio and ship the logs outside of the application, but whatever works :)</p></pre>diegobernardes: <pre><p>using logrus too, very good.</p></pre>ihsw: <pre><p>Another advocacy for logrus, it is excellent.</p></pre>nerr: <pre><p>logrus is great. The internal logging library at my workplace wraps it and removes all of the "-f" and "-ln" family of methods, so your only option is to add values to your logs as fields. We also made some small changes to reduce the verbosity of the logging calls:</p>
<pre><code>log.Ctx(ctx).Err(err).KVs(log.F{
"foo.id": 10,
"foo.name": "bar",
}).Error("error occurred while doing X")
</code></pre>
<p>The above adds information from a context and an error in predefined fields that we use throughout our codebase. Our logs are aggregated using rsyslog into ElasticSearch and Kibana.</p></pre>gmccue: <pre><p>+1 for logrus. I'm a big fan. Hooks abound as well, so you can hook-in loads of services.</p></pre>naturalselection: <pre><p>glog</p></pre>nohoudini: <pre><p>glog too</p></pre>nilium: <pre><p>glog as well. Otherwise I just use the standard log package and point it at syslog.</p></pre>iyee: <pre><p>glog doesn't support rotating files by time, pity.</p></pre>tehbilly: <pre><p>I wish it let you set an io.Writer as the output, then you could just use lumberjack or whatever you'd like.</p></pre>inconshreveable: <pre><p>I'm biased, of course, but I'm partial to <a href="https://github.com/inconshreveable/log15">https://github.com/inconshreveable/log15</a> and a number of other like it as well</p></pre>stuffsnout: <pre><p>by far my favorite library for logging</p></pre>inconshreveable: <pre><p>thank you! i'd like to get back to improving it soon =)</p>
<p>huge props go to cs-guy who was instrumental in making it even better</p></pre>shazow: <pre><p>I'm a fan of <a href="https://github.com/alexcesaro/log" rel="nofollow">github.com/alexcesaro/log</a>.</p>
<p>It's really simple and does exactly what I need. I've used it for several projects with no disappointments and the author is very responsive. </p>
<p>I wouldn't say it's strictly <em>better</em> than any other logging library; to me, I like that it doesn't do a lot more than what I need it to do.</p></pre>cs-guy: <pre><p>As one of the authors I am biased to <a href="https://godoc.org/github.com/go-kit/kit/log">github.com/go-kit/kit/log</a>. I have also made significant contributions to log15 (mentioned below) and recommend it as well. The Go kit log package was strongly influenced by log15. Go kit log takes a less is more philosophy.</p></pre>GoTheFuckToBed: <pre><p>pipe</p></pre>MrGossett: <pre><p>A coworker of mine wrote <a href="https://github.com/phemmer/sawmill" rel="nofollow">https://github.com/phemmer/sawmill</a>. I couldn't imagine using anything else. It providers handlers to integrate with Splunk, Sentry, syslog, and standard streams (STDOUT/STDERR), as well as Capture (to slice) and Channel handlers that are nice for testing. It also has a pluggable handler system that makes it extensible. It spins off a goroutine for each write, so it's super quick and doesn't get in the way if the log handler is slow.</p></pre>quiI: <pre><p>stdout</p></pre>tcrypt: <pre><p>At work we use (and built) <a href="https://github.com/gocraft/health" rel="nofollow">gocraft/health</a> which provides tagged logging and metrics. Out of the box it can optionally send data to statsd, Bugsnag, or be polled via a JSON API. This makes it super easy to have constant metrics about your running code and alerts when there are issues.</p>
<p>We use a <a href="https://github.com/gocraft/web#middleware" rel="nofollow">middleware</a> so every web request or background job is counted, timed, and sent to statsd/Librato so we get automatic charts. It also has a tool, healthtop, which is a <a href="https://camo.githubusercontent.com/0984d0789a901aab0edd5257fa06bc19666363f8/68747470733a2f2f676f63726166742e6769746875622e696f2f6865616c74682f696d616765732f6865616c7468746f702e706e67" rel="nofollow">New Relic type breakdown of your instrumented code.</a></p>
<p>It also compliments our other project, <a href="https://github.com/gocraft/dbr" rel="nofollow">dbr</a>, which will automatically log and time executed queries to a given health stream which makes tracking down inefficient queries quick and painless.</p></pre>apgwoz: <pre><p>We typically use logrus, but also attach some custom hooks to report to Rollbar. In addition we utilize go-metrics for publishing metrics to Librato. Other folks in the company utilize l2met, which just pulls metrics data out of the logs -- this is a service run by Librato.</p>
<p>Recently, I've been thinking about how to make this all better, and started a new lib to hopefully simplify this workflow. The basic idea is that you log key-value pairs (though anything else is supported as well) only, and attach filters to the logger, which can do things like print to standard out, or report to rollbar, or stop the filter chain and post l2met style metrics directly to Librato (instead of doing the l2met thing).</p>
<p>I think the same thing could probably be done in logrus, but there are other little things that bug me about that library, so YOLO: <a href="https://github.com/apg/ln" rel="nofollow">https://github.com/apg/ln</a>. Keep in mind that I've put like 2 hours into this so far and have a long way to go, and may just abandon it if it doesn't seem like it's any better than what we have...</p></pre>Have_No_Name: <pre><p>If you are moving from log4j, would you find log4go easy?
<a href="https://github.com/alecthomas/log4go/" rel="nofollow">https://github.com/alecthomas/log4go/</a></p></pre>henrikbjorn: <pre><p>We use Logrus. But we "hide" the usage of Logrus behind interfaces so we dont have to rely directly on logrus and have pointers in our method signatures.</p></pre>Yojihito: <pre><blockquote>
<p>standard logger</p>
</blockquote>
<p>This piece of shit is useless and should get deleted asap.</p>
<p>Used it, tried to change date format to ISO 8601 norm, the standard date norm, LOL NOPE HARDCODED.</p>
<p>Delete, next.</p></pre>GoGoGadgetGopher: <pre><p>:o</p>
<p>u mad bro?</p></pre>Yojihito: <pre><p>Yes. A logging mechanism with hardcoded date format is shit. If that date format isn't even ISO compatible is a piece of useless shit.</p></pre>
