garydgregory commented on issue #3100:
URL:
https://github.com/apache/logging-log4j2/issues/3100#issuecomment-2895669528
This is a classic and recurring issue in logging. The POVs to consider are:
- The library developers (in this case, us, Log4j)
- The application developers using that library (I'll include libraries
reusing Log4j here)
- The users of the applications
Each is a different audience with varying and at times different needs.
Since we are talking about the status logger and not logging in general, we
are further constrained by the configuration of this type of logging being
limited to choosing a level, and that's it, no markers, no logger hierarchies.
If I enable Log4j's status logging, I must be aware that this is different
from any other kind of logging. _This is logging about logging_.
If status logging output is mixed in with normal library and application
logging, then the output can be confusing. A log's audience must be aware of
this difference.
For me, WARN and ERROR events should contain actionable information. If a
file is locked, I probably need to close an app. Once I am here, all behavior
may be broken or unpredictable.
INFO tells me events are proceeding normally and gives me confidence the
system is alive and well.
I need DEBUG if I am trying to solve a problem or am curious to see why a
task is time or resource consuming.
I need TRACE to see what is being read or written on the wire or to a file.
Coming back to Log4j status logging, I think we need to consider what is
informative vs. what is only needed when trying to solve an issue. We might
find that we can move more events from INFO to DEBUG using this POV.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
