logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-1401) Support changing the log level for all messages related to some domain object
Date Thu, 02 Jun 2016 07:55:59 GMT

     [ 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.
** Update: one way to address these issues is to create a KeyValueMarker implementation of
the Marker interface. A single instance could contain multiple tags (key-value pairs of arbitrary
type).  Instances cannot be cached by name in the MarkerManager, but instead I imagine we
can use a pool of KeyValueMarkers to reuse (so we would need to call release() or something
when the log event is fully processed).
* *ThreadContext map*: the content of this map is merged into a properties map for each Log
Event. 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 a better option.

*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 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)


> 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.
> ** Update: one way to address these issues is to create a KeyValueMarker implementation
of the Marker interface. A single instance could contain multiple tags (key-value pairs of
arbitrary type).  Instances cannot be cached by name in the MarkerManager, but instead I imagine
we can use a pool of KeyValueMarkers to reuse (so we would need to call release() or something
when the log event is fully processed).
> * *ThreadContext map*: the content of this map is merged into a properties map for each
Log Event. 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 a better option.
> *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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message