[
https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1401:
--------------------------------
Description:
During system operations, it is commonly desirable to temporarily make logging
for a certain domain object more verbose. For example, all log messages related
to processing a certain order, or for a certain user, or for a certain product.
In addition to manually increasing/decreasing verbosity, it would be nice if we
can restore the original verbosity if some condition no longer holds. For
example, log at some verbose level
* for some period of time (5 minutes)
* for some fixed number of events (10,000 log messages)
* any other user-specified condition
*Problem 1: Log Event "Tagging"*
How to efficiently "tag" log messages to select only _some_ log events to be
output at a more verbose level but don't show _all_ log events? Current methods
available for "tagging" a log event are:
* *Markers*: String-based, name attribute only (no key-value), hierarchical
(may have parents). Current implementation caches all Markers forever, with an
option to clear the whole cache. Unclear how to use this mechanism to tag a log
event with things like order ID, user ID and/or product ID.
* *ThreadContext map*: the content of this map is merged into a properties map
for each Log Event. This may be a good place to start since values can be
replaced and/or cleared so we don't use up increasingly more memory. The
drawback of the ThreadContext API is that values must be Strings. We would like
the ability to specify arbitrary Object values, or even primitive values. We
can also take this opportunity to provide a garbage-free version of the
ThreadContext (LOG4J2-1349) and the LogEvent properties map.
* *Direct user access to the LogEvent properties map*. LOG4J2-1010 suggests
changing the Logger API to accomplish this, but there may be alternatives
(needs more thought). Similar to the above, ideally we would like the ability
to specify arbitrary Object values, or even primitive values, not just Strings.
* Other possibilities are *a new MessageFactory or a new LogEventFactory*.
These would require invasive changes in the Log4j design across the board. It
is not clear what the interfaces would look like for both upstream and
downstream components. Improving the other mechanisms seems
*Problem 2: Dynamic filtering*
* What mechanism to use for increasing verbosity of events matching some
condition? Global filters (on LogEvent properties or markers) may be a good
candidate.
* How can operators enable/disable this on the fly?
* How can we provide convenience features for automatically reverting to the
previous level of verbosity when some condition is met (e.g. after 10,000
events or after 5 minutes etc)
was:
During system operations, it is commonly desirable to temporarily make logging
for a certain domain object more verbose. For example, all log messages related
to processing a certain order, or for a certain user, or for a certain product.
In addition to manually increasing/decreasing verbosity, it would be nice if we
can restore the original verbosity if some condition no longer holds. For
example, log at some verbose level
* for some period of time (5 minutes)
* for some fixed number of events (10,000 log messages)
* any other user-specified condition
*Problem: How to efficiently "tag" log messages to allow more verbose logging
only for relevant log events*
Current methods available for "tagging" a log event are:
* *Markers*: String-based, name attribute only (no key-value), hierarchical
(may have parents). Current implementation caches all Markers forever, with an
option to clear the whole cache. Unclear how to use this mechanism to tag a log
event with things like order ID, user ID and/or product ID.
* *ThreadContext map*: the content of this map is put into a properties map for
each Log Event. This is a good option since values can be replaced and/or
cleared so we don't use up increasingly more memory. The drawback of the
ThreadContext API is that values must be Strings. We would like the ability to
specify arbitrary Object values, or even primitive values. We can also take
this opportunity to provide a garbage-free version of the ThreadContext
(LOG4J2-1349).
* *Additional API* for direct user access to the Log Event properties map. (See
also
* Other possibilities are *a new MessageFactory or a new LogEventFactory*.
These would require invasive changes in the Log4j design across the board. It
is not clear what the interfaces would look like for both upstream and
downstream components. Improving the other mechanisms seems
Also, ideally this should be garbage-free
*Considerations for a new or extended ThreadContext*
* Adding or setting values: what should the user-facing API look like?
* Merging the snapshot of the current ThreadContext map with the Configuration
Properties into the LogEvent map
* Getting values out of the LogEvent for use by Filters and/or Layouts. This
may be by a specified key or by iterating over the keys.
> Support changing the log level for all messages related to some domain object
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-1401
> URL: https://issues.apache.org/jira/browse/LOG4J2-1401
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core, Filters
> Affects Versions: 2.6
> Reporter: Remko Popma
>
> During system operations, it is commonly desirable to temporarily make
> logging for a certain domain object more verbose. For example, all log
> messages related to processing a certain order, or for a certain user, or for
> a certain product.
> In addition to manually increasing/decreasing verbosity, it would be nice if
> we can restore the original verbosity if some condition no longer holds. For
> example, log at some verbose level
> * for some period of time (5 minutes)
> * for some fixed number of events (10,000 log messages)
> * any other user-specified condition
> *Problem 1: Log Event "Tagging"*
> How to efficiently "tag" log messages to select only _some_ log events to be
> output at a more verbose level but don't show _all_ log events? Current
> methods available for "tagging" a log event are:
> * *Markers*: String-based, name attribute only (no key-value), hierarchical
> (may have parents). Current implementation caches all Markers forever, with
> an option to clear the whole cache. Unclear how to use this mechanism to tag
> a log event with things like order ID, user ID and/or product ID.
> * *ThreadContext map*: the content of this map is merged into a properties
> map for each Log Event. This may be a good place to start since values can be
> replaced and/or cleared so we don't use up increasingly more memory. The
> drawback of the ThreadContext API is that values must be Strings. We would
> like the ability to specify arbitrary Object values, or even primitive
> values. We can also take this opportunity to provide a garbage-free version
> of the ThreadContext (LOG4J2-1349) and the LogEvent properties map.
> * *Direct user access to the LogEvent properties map*. LOG4J2-1010 suggests
> changing the Logger API to accomplish this, but there may be alternatives
> (needs more thought). Similar to the above, ideally we would like the ability
> to specify arbitrary Object values, or even primitive values, not just
> Strings.
> * Other possibilities are *a new MessageFactory or a new LogEventFactory*.
> These would require invasive changes in the Log4j design across the board. It
> is not clear what the interfaces would look like for both upstream and
> downstream components. Improving the other mechanisms seems
> *Problem 2: Dynamic filtering*
> * What mechanism to use for increasing verbosity of events matching some
> condition? Global filters (on LogEvent properties or markers) may be a good
> candidate.
> * How can operators enable/disable this on the fly?
> * How can we provide convenience features for automatically reverting to the
> previous level of verbosity when some condition is met (e.g. after 10,000
> events or after 5 minutes etc)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
