<p>I've been investigating using a 3rd party logging framework rather than the stdlib, because what i have is getting quite convoluted. I need the capability to have the logs be a standard size on disk, to be able to print go objects in a human-readable way and have a way to automatically annotate where the message was created.</p>
<p>I've already seen:
<a href="https://github.com/Sirupsen/logrus">https://github.com/Sirupsen/logrus</a>
<a href="https://github.com/natefinch/lumberjack">https://github.com/natefinch/lumberjack</a>
<a href="https://github.com/op/go-logging">https://github.com/op/go-logging</a></p>
<p>is there anything else anyone here would suggest?</p>
<hr/>**评论：**<br/><br/>natefinch: <pre><p>I use stdlib + lumberjack (naturally ;).</p>
<p>log.Printf with %v or %#v works well enough to print out human-readable objects for the most part. Check out <a href="https://github.com/davecgh/go-spew" rel="nofollow">https://github.com/davecgh/go-spew</a> if you want a more complete pretty-printer (navigates through pointers etc).</p>
<p><a href="https://github.com/inconshreveable/log15" rel="nofollow">https://github.com/inconshreveable/log15</a> is a pretty good structured logger if that's the way you roll.</p>
<p>I find that one toggle-able log channel for debug messages and one channel for always-on messages is all I really need... we use a levelled logger at work, and I really find I only use two levels, debug+ or info+</p>
<p>I also really liked this post about how to make packages that accept almost any generic logging package: <a href="https://0value.com/about-Go-logging" rel="nofollow">https://0value.com/about-Go-logging</a></p></pre>graham_king: <pre><p>I have found it very useful to differentiate between two types of logs: support logs and diagnostic logs.</p>
<p>Support logging is the stuff that the ops team needs to know, it's "error" or "critical"
log level, it is a notification rather than a log. It is part of the
user interface of the application. There should be unit tests to ensure
these notifications happen. These are the (very few) things that are important enough to get you out of bed. For these logs I have a Reporter interface, with a mock for testing, and an EmailReporter for production.</p>
<p>Diagnostic logging is printf debugging, for which the stdlib is perfectly fine, and which you remove before committing anyway.</p>
<p>They are different animals, not just different severity levels. I learnt all this from the excellent "Growing Object-Oriented Software, Guided By Tests".</p>
<p>Anything that isn't important enough to get you out of bed, and isn't debugging, is a metric. We have metrics for HTTP errors, handler speed, you name it. Metrics are often far more useful than logs. Prometheus rocks.</p>
<p>If you really do need a fancy log package, I like <a href="https://github.com/inconshreveable/log15" rel="nofollow">https://github.com/inconshreveable/log15</a>. </p>
<blockquote>
<p>logs be a standard size on disk</p>
</blockquote>
<p>That's not up to your program, that's up to the environment. Log to stdout, always and only.</p>
<blockquote>
<p>automatically annotate where the message was created</p>
</blockquote>
<p>log.SetFlags(log.LstdFlags | log.Lshortfile) will prepend file name & line number to all your log.Println(..)</p></pre>natefinch: <pre><p>FWIW, logging to stdout is a nice standard for big deployments on linux with expert devops setting up the environment. If you don't fall into that very specific category (such as if you're running on windows, or you don't have spare cycles to worry about fiddling with logrotate).. then sometimes it's nice to have something incredibly simple that just works to handle simple logging.</p></pre>graham_king: <pre><p>Fair point. I'm so used to having <code>systemd</code> or <code>upstart</code> manage all this for me, sometimes I forget how nice it is to be working on Linux.</p>
<p>You don't need "expert devops". With upstart you add the single line <code>console log</code> in your /etc/init/<job>.conf file. With systemd you don't need anything at all, by default stdout goes into the journal, which is compressed, rotated, size-limited and searchable.</p>
<ul>
<li><a href="https://lincolnloop.com/blog/2013/jun/20/joy-upstart/" rel="nofollow">https://lincolnloop.com/blog/2013/jun/20/joy-upstart/</a></li>
<li><a href="http://www.darkcoding.net/software/the-joy-of-systemd/" rel="nofollow">http://www.darkcoding.net/software/the-joy-of-systemd/</a></li>
</ul></pre>natefinch: <pre><p>Also a fair point :) I didn't realize it was so easy.... other people had wrestled with it at work, so I figured it was more complicated than that (I hadn't messed with it myself).</p></pre>karnd01: <pre><p>The stdlib log is very good, once getting into larger projects though, I find a logging library for logging to multiple sources and adding notifications for different severity levels helps greatly.</p>
<p>I created <a href="https://github.com/go-playground/log" rel="nofollow">https://github.com/go-playground/log</a> for easy log handler creation, easy log level specification per log handler, concurrent logging and low overhead if it can help.</p>
<p>I can also recommend <a href="https://github.com/Sirupsen/logrus" rel="nofollow">https://github.com/Sirupsen/logrus</a> in the end there are dozens out there though, try a few and pick what works best for you.</p></pre>1Gijs: <pre><p>I use Multiwriter() to log one output to several tatgets (file, online service and such). For example one target is a writer that watches every string being passed. If it contains 'error' then i get an email.</p></pre>karnd01: <pre><p>That is a great approach, there are 2 reasons I didn't use MultiWriter().</p>
<ol>
<li><p>If you look at the MultiWriter source it writes out to each writer synchronously and I wanted to concurrently write out to all sources at once.</p></li>
<li><p>For structured logging and implementing centralized logging a simple string writer is limiting <a href="https://github.com/go-playground/log/blob/master/log.go#L233" rel="nofollow">https://github.com/go-playground/log/blob/master/log.go#L233</a></p></li>
</ol></pre>chewxy: <pre><p>I use this:</p>
<pre><code>// +build debug
func logf(format string, stuff ...interface{}){
log.Printf(format, stuff...)
}
func condlogf(cond bool, format string, stuff ...interface{}) {...}
</code></pre>
<p>and in the release.go file:</p>
<pre><code>// +build !debug
func logf(format string, stuff ...interface){}
func condlogf(cond bool, format string, stuff ...interface{}){}
</code></pre>
<p>There are of course various helper functions, but that's fairly straightforwards. If I really need to log outside a debug mode, I just use log.Print... (which is rarely the case)
As for setting up times etc, I use log.SetFlags</p></pre>muffinz0: <pre><p>This doesn't meet your requirements, but you can take a look at this: <a href="https://github.com/iamthemuffinman/logsip" rel="nofollow">https://github.com/iamthemuffinman/logsip</a></p></pre>
