Consider using generalized logging solutions (like Log::Any)
ehuelsmann opened this issue · comments
Issue Template
Description
I've switched the libraries I'm developing from no logging at all to Log::Any. There was no logging, because there are too many logging solutions and I didn't want to limit my library to the users of any specific one. With Log::Any, I only define that I would like to do logging, but the application needs to initialize it with a specific logging implementation. If no such initialization happens, logging goes nowhere.
I'm trying to say that these days there are generally accepted mechanisms (like Log::Any and Log::ger) to support logging in a way that's not opinionated.
The suggestion from @oliwel (on Slack) is to use an instance variable or an over writable method so we can add any logger and the logger should loaded runtime instead of compile time.
@oliwel please add any further details if I misinterpreted your statement in the Slack.
I addition, it seems workflow is requiring a logging mechanism, what if this is not the case. Should we support that use-case as well?
Both Log::ger and Log::Any do exactly what @oliwel describes:
use Log::Any qw($log);creates an instance variable which holds a generalized logger. This logger can be initialized using Log4perl or Log::Dispatch or any other logger (even a code reference) at runtime, even with no logger at all to disable all logging.
use Log::Log4perl;
Log::Log4perl::init('/etc/log4perl.conf');
Log::Any::Adapter->set('Log::Log4perl');sets a Log4perl logging target.
In our application we currently drop all logs from Workflow itself as it is to noisy, if we talk about log reorganisation I also want to address / discuss different facilities or loglevels for the different exceptions. We already removed condition errors from the log but I think there should also be a difference between a validation error (caused by improper input so it can be handled by the user) and a workflow error which (from my understanding) is something that went wrong on the server and needs attention.
I'd like to second @oliwel 's request to differentiate various log levels and reserving ERROR for something that needs admin level attention -- which means a validation error is, in terms of logging, at most an information level log entry. I'd prefer debug, though.
As for the condition errors that are currently filtered out: I'd like to propose to add them back, just with a trace level log entry.
@oliwel does the above change suffice to make things sufficiently silent?
Your response times are awesome ;)
I'd opt to have the validation_error on info. When you run this "with users" you sometimes get blamed that "it was not working" and I saved my good reputation more than once as I could prove it was not my fault by showing the user that his input was wrong ;)
That would make it easy to monitor on error and likely warn with "admin alert" and log on info to check for user problems.
I was wondering between INFO and DEBUG indeed. I've changed it to INFO in the PR now.
@jonasbn one of the comments on irc://libera.chat/#perl was that any logging abstraction library was overkill and that some of the participants in the discussion suggested to pass a sub into the library configuration which can be called with a logging level and the log message (or log message producing coderef). Adding that stance to the issue for reference of available options.
Ok. So, after some conversations: Log::Any doesn't have any non-core dependencies (not even Log4perl). By requiring adapters (like Log::Any::Adapter::Log4perl), application developers can select their logging mechanism.
Implemented using #164 .