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.