loading...

Discussion on: Go Logger - Why we wrote our own

Collapse
csgeek profile image
csgeek

I agree with most of your needs but the lack of log levels just feels wrong. Actually that's the biggest issue I have with the default logging library that comes with go, the lack of logging levels. You also didn't mention debug level which I think is equally important when trying to trace what went wrong.

you can also perform analysis on your application logs especially in streaming pipelines to detect patterns. Not everything has to be either critical or a normal log message to be something to be acted upon.

Though I do agree the majority of the time most logs are never looked at and that needs to be improved.

Collapse
dglsparsons profile image
Douglas Parsons Author

Hi, thanks for reading. Hope you enjoyed the article. I've a couple of counterarguments to your points:

Actually that's the biggest issue I have with the default logging library that comes with go, the lack of logging levels.

I think the lack of structured logging is a far bigger issue there - because it prefixes timestamps to messages it basically destroys the ability to search through log lines efficiently in any tool (Splunk, Kibana, CloudWatch insights..)

You also didn't mention debug level which I think is equally important when trying to trace what went wrong.

It's almost a separate point. Most applications don't use debug, so I intentionally left it out. You could also argue i've missed Fatal. Debug is one i'd disagree with again though. Again, they fall into one of two categories:

  • You need them to tell you what your application is doing
  • You don't need them to tell you what your application is doing.

If you do need them then you're going to have a really hard time diagnosing and fixing issues that occur in production where they are usually turned off... basically, they are better suited as Info level logs.
If you don't need them, delete them. Problem solved.

Not everything has to be either critical or a normal log message to be something to be acted upon.

Again, this would be better determined by the contents of the log message (or maybe a metric instead!?), rather than what log-level something is.