[
https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15309903#comment-15309903
]
Remko Popma commented on LOG4J2-1401:
-------------------------------------
Ralph, I think you are referring to LOG4J2-1137. I like that idea a lot, by the
way.
Your idea is to keep a history in memory that can be flushed on some trigger
(usually when something bad happens). The technical problems to solve here seem
to be in the area of what data structure to use and how/when to switch between
different "modes".
The goal of this ticket is to "filter in" some subset of the total stream of
log events that the operator is particularly interested in. Sub-problems to
solve here are efficient tagging of the events, dynamic filtering that can be
enabled/disabled on the fly by operators, and optionally some convenience
features for automatic enabling/disabling the filtering.
Both tickets are aiming to improve system operations and monitoring, so there
is definitely a common theme here.
> 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
> *How to identify which log messages to log at more verbose level*
> * Marker
> * ThreadContext map
> * Other?
> Markers are cached forever, which may not be desirable if we need to tag
> every log message with the order ID, user ID and/or product ID.
> ThreadContext 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. Also, ideally this should be garbage-free (LOG4J2-1349).
> *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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
