<p><a href="https://github.com/thockin/logr" rel="nofollow">https://github.com/thockin/logr</a></p>
<p>Just what you need, ANOTHER logging API for go.</p>
<p>After reading <a href="http://dave.cheney.net/2015/11/05/lets-talk-about-logging" rel="nofollow">http://dave.cheney.net/2015/11/05/lets-talk-about-logging</a>, I wanted to try out a simpler logging API, to see if I could actually make it work. Here's my first sketch of an API.</p>
<p>An implementation in terms of glog is at <a href="https://github.com/thockin/glogr" rel="nofollow">https://github.com/thockin/glogr</a></p>
<hr/>**评论：**<br/><br/>tscs37: <pre><p>I personally like my logging levels, especially for debugging.</p>
<p>Of course, the warning level is basically useless; I follow the example of the go compiler, it's either an error or it's not.</p>
<p>But otherwise I like to have the log levels <code>Debug</code>, <code>Info</code>, <code>Error</code> and <code>Fatal</code>. (And please don't os.Exit on Fatal, I want my cleanup pls, that's my task, not the logger's)</p>
<p>It's certainly not a bad start, tho I'll probably just <code>fmt.Printf</code> in my libraries like always...</p></pre>jiminythinksjohnny: <pre><p>It's useful to reserve the <code>warning</code> level for notable events that aren't actually errors in the program, but that might relate to problems external to it—events such as bad input or failed login attempts. They're <em>forensically interesting</em>, but not individually actionable. Unlike errors, alerting on warnings isn't typically worthwhile, because no conceivable change to the program could completely avoid them. But warnings are distinct from the <code>info</code> level, which covers the unremarkable majority of events, such as successful logins. You might review warnings in bulk from time to time, and that's only practical if they aren't mixed with the noise of the <code>info</code> entries. When troubleshooting a larger system, you'd look at the warnings immediately after the errors.</p>
<p>Example:</p>
<ul>
<li><code>info</code>: Successful login for user "xyz"</li>
<li><code>warning</code>: Login failed due to incorrect password entry for user "xyz"</li>
<li><code>error</code>: Login failed because authentication server returned unrecognized account status for user "xyz"</li>
<li><code>critical</code>: could not connect to authentication server</li>
</ul></pre>PaluMacil: <pre><p>I use warn for documenting method executions that are successful and "correct" but are deprecated or risky. I have a security flaw, for instance, that I cannot remove due to a legacy requirement pressed upon me. It's better than an error / fatal, and it's "bad" and needs observation, so it isn't just info, and debug fits worst of all.</p></pre>tscs37: <pre><p>my approach to legacy is: "don't"</p>
<p>Though I guess if there is no choice in that department there is no way around warnings or maintaining legacy branches.</p></pre>Barrucadu: <pre><p>Doesn't having verbosity levels just mean, in practice, you have more log levels anyway? In order for the levels to mean anything, you'd need to adopt a convention about their use, which will probably just result in things like "INFO level 3+ is a DEBUG message".</p>
<p>Not that I think there should be only two log levels with no verbosity levels. That's crazy. But I feel like, at a minimum, there should be "debug", "info", and "error".</p></pre>thockin: <pre><p>Being numeric means you can define it yourself, and it doesn't limit you to just one trace level. I frequently want to enable increasing levels of verbosity when tracing something hard. The loss of semantic meaning is what I find interesting</p></pre>neoasterisk: <pre><p>I could never understand the purpose of different logging levels. You either log or you do not. A well-written command produces no logging on success. "No news is good news". </p>
<p>I believe that the design of the standard <code>log</code> package emphasizes that idea but still allows for flexibility via <code>log.New</code> which should be sufficient for the majority of cases.</p></pre>wlll: <pre><p>As a sysadmin logs are fundamental. Logs telling you what a process was doing when it was working as expected in the lead-up to a failure can be invaluable.</p>
<p>If a process is mis-behaving, enabling more verbose logging to get more diagnostic information is valuable. It can always be turned down when the process is operating normally.</p></pre>: <pre><p>[deleted]</p></pre>neoasterisk: <pre><blockquote>
<p>You don't want to get a notification each time there an "info" level log, but you might want to get a notification each time there is a "error" level log in your system.</p>
</blockquote>
<p>This is what I meant by "you either log or you do not". If something is so serious or important that it has to be logged then you log it. Otherwise it's just noise or metrics.</p>
<blockquote>
<p>You should log ALL requests in a web app. If you don't do that, then you're not doing your job.</p>
</blockquote>
<p>I agree but I personally believe that this goes a bit out of the scope of logging. This is more like statistics/metrics and although logging can help with it, I think that we better use tools more appropriate for the job like <code>expvar</code>. I read that this is considered a <a href="https://peter.bourgon.org/go-in-production/#logging-and-telemetry" rel="nofollow">best practice</a>.</p>
<blockquote>
<p>The standard log packages serves very little purpose. as it is half baked.</p>
<p>I baffled that anyone would claim the log package is enough for serious logging.</p>
</blockquote>
<p>I think it all depends on how your think about software. If you only log things that truly matter, then I don't see why <code>log</code> is insufficient. Yet even if you want to do more intricate stuff you can easily create your custom loggers e.g. <code>Info = log.New(...)</code> and <code>Error = log.New(...)</code>. The standard <code>log</code> package while simple, it still allows for that flexibility.</p></pre>thockin: <pre><p>Not everything is a simple command. The main project I work on (Kubernetes) is large and complex, and it is frequently necessary to ask a user to increase logging to get sufficient info to diagnose a problem, but leaving that enabled all the time would be too noisy.</p></pre>neoasterisk: <pre><p>For special cases like Kubernetes, using a more powerful 3rd party logging package might pay off. Even better if you write your own and avoid an extra dependency. </p>
<p>But for the majority of cases I truly believe that the standard <code>log</code> package is more than sufficient and flexible enough. Yet somehow I see people easily dismissing it as worthless and "half-baked" which is something I cannot understand.</p></pre>
