[HN Gopher] The only two log levels you need are INFO and ERROR
___________________________________________________________________
The only two log levels you need are INFO and ERROR
Author : acossta
Score : 12 points
Date : 2024-04-30 16:29 UTC (6 hours ago)
(HTM) web link (ntietz.com)
(TXT) w3m dump (ntietz.com)
| orf wrote:
| Clearly not, you need at least 3: ERROR, INFO and DEBUG.
|
| There is a big difference between logging "a HTTP request was
| made to x/y" and a stream of super-verbose, protocol-level
| messages.
|
| Both are useful for diagnosing issues. Both don't belong
| together.
| david_allison wrote:
| > And similar for things like DEBUG or TRACE. Usually you reach
| for those log levels when you want to see extremely verbose
| information, but... That's not practical to enable in production
| environments, because the volume of logs you produce would be way
| too high. And if you can't use it in production, you probably
| shouldn't use it elsewhere! That's what your local debugger is
| for.
|
| That's why you want DEBUG and TRACE. I'd rather have useful logs
| as well as a debugger when running locally.
| JohnFen wrote:
| I agree. I found the argument against DEBUG and TRACE to be
| particularly weird, since it's very rare that you enable these
| log levels in production code.
|
| While debugging and testing locally, though? They're extremely
| useful.
|
| I think they're also useful in production code, although much
| more rarely. I've had a few times when a customer is having a
| strange problem that higher log levels helped to quickly
| resolve.
|
| Being able to have them enable the higher log levels, reproduce
| the issue, reduce the log level to normal, and send you the
| logs can occasionally find an issue that would have taken
| forever to track down otherwise.
|
| And that's not even to mention special processing. In the
| unices, anyway, the log daemon can take different actions
| depending on what level the log message was issued at. CRITICAL
| errors can result in automatic notification to a dev, for
| instance.
| rstuart4133 wrote:
| [delayed]
| ziml77 wrote:
| Yep those messages are really handy even if you never enable
| them in production. Being able to scan through log lines can
| get point you to the source of an issue much faster than
| stepping through code can. From there you can set a breakpoint
| and dig deeper.
|
| And while, yes, you can have your debugger stop where
| exceptions are thrown, that's often not very useful because the
| exception happens after the point where you want to start
| seeing what is going on.
| paulddraper wrote:
| > And similar for things like DEBUG or TRACE. Usually you reach
| for those log levels when you want to see extremely verbose
| information, but... That's not practical to enable in production
| environments, because the volume of logs you produce would be way
| too high. And if you can't use it in production, you probably
| shouldn't use it elsewhere! That's what your local debugger is
| for.
|
| Oh boy, where to start....
|
| 1. Staging/pre-prod environments do exist.
|
| 2. Debuggers are nice, but they're not everything. I have a loop
| and want to see the distribution of execution times. Should I
| really use a debugger, writing down the info from each iteration?
| Or maybe something a bit more automated (like a log...)?
|
| 3. Being able to enable debug logs (for a specific part of the
| system) is extremely helpful. Datadog makes this super easy to
| enable finer logging at runtime.*
|
| * More precisely, the application always logs at a fine level. I
| have Datadog drop debug logs, but at any time I can enable them
| to help with a problem.
| https://docs.datadoghq.com/logs/guide/getting-started-lwl/
___________________________________________________________________
(page generated 2024-04-30 23:01 UTC)