Hacker News Reader

Comment by ordiel | Hacker News Reader

People and, many companies seem to forget that such software comes "AS IS" and it means, AS IS, I would be glad to see fortune 500 companies try to put together a team providing flawless logging capabilites. In reality I know they would not be able to get to be half as good as an open source library, fist of all drowning developers in unnecessary administrative tasks, imposing stupidly unreasonable deadlines and fully ignoring engineering advice from... well the engineering team. It's an insult that those companies profiting masively from so many open source projects still have the audacity to put blame on (again) software whose premise is "AS IS" specially when if you look at their projects (even the ones they sell to their customers) are basically bullshit put thogether with spit and boogers (and I've work in more than one FAANG to know this is truth by experience)

View on HN

Yes, log4j is garbage "as is" and should be avoided.

Console.log("my message")

Job done.

Logging libraries are unnecessarily complicated.

Cool, now make it so that only high-severity logs from a particular set of subroutines get sent to a particular subset of employees, grouped into a daily email.

And make it possible to change any of those knobs at runtime, without touching the code (minimum severity, set of subroutines, set of recipients, delivery method).

There is an argument to be made that all those actions should be done by an external log parsing tool.

As with many things there is no easy right or wrong. For example, I want to be able to set log-level on different classes dynamically but where to draw the line?

> There is an argument to be made that all those actions should be done by an external log parsing tool.

Yes, keeping them separate is typically good, especially if you have multiple applications. There are also some instances where doing so leads to duplicate configurations that need to be kept in sync, and so you might want to have that logic bundled in the application itself.

In my workplace we have two options for sending Slack alerts - one from our NewRelic cloud account alerts, one built-int in the logging framework. We use either for different purposes.

> As with many things there is no easy right or wrong. For example, I want to be able to set log-level on different classes dynamically but where to draw the line?

Exactly. My point wasn't that everybody needs a Swiss Army Knife structured logging framework, it was that OP's glib dismissal that 'console.log(), job done, why are you making this so complicated?' was naïve and obtuse.

Log parsing service filters and alerts (data dog, newrelic, splunk etc..)

Now add a date/time stamp. And thread name, current class/method, request trace ID, severity level, etc., to every log line in your app. Or just grab your favorite logging lib from Maven Central and call it a day.

Reply on news.ycombinator.com