What you are describing sounds to me more fitting for distributed tracing
rather than logging, but I will skip that discussion for now.
Rather than "hacking" a Log4j component to deliver this functionality, I'd
simply implement a custom Filter keeping a cache of user IDs to be
inspected. This cache could be populated from SCC or some database where
your operators have write access by means of a dashboard, web UI, or
something. Since this custom filter implementation totally belongs to you,
you can even go wild and implement instantaneous updates via long-polling
or publishing IDs-to-be-inspected snapshots to an event queue.
I think every moderately sized company (incl. yours, I presume) has a
handful of libraries shared by all its applications. You can leverage these
to take care of making sure your custom filter lands into their classpaths.
On Wed, Apr 6, 2022 at 9:14 AM Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> I’m looking for some inspiration.
>
> At work we use Spring Cloud Config and host our logging configuration
> there. It is shared by something like 150 services, which comes out to
> hundreds of service instances. We have a standard of including the user’s
> id and the customer’s account number in the ThreadContext and passing those
> automatically from one service to another. Operationally, went to normally
> log at WARN or INFO. But when a customer calls with a problem we want to be
> able to enable debug logging for that user or account. I know I could use
> either the DynamicThresholdFilter or the ContextMapFilter to do this.
>
> So here are the issues.
> 1. We don’t really want operations folks editing the log4j configuration
> file directly.
> 2. Our SCC uses a Git repo hosted by a third party. We don’t really want
> to open access to allow Git to call SCCs endpoint to notify it of changes.
> 3. Without the Git notification we will have to poll for changes in SCC.
> This means it could be a few minutes before SCC notices changes and then
> another few minutes before Log4j notices changes.
>
>
> I’m considering doing something like:
>
> <DynamicThresholdFilter key=“accountNumber" defaultThreshold=“ERROR"
> onMatch="ACCEPT" onMismatch="NEUTRAL">
> <KeyValuePair key=“${scc:accountNumber}" value="DEBUG"/>
> </DynamicThresholdFilter>
>
> Where scc represents a new SpringCloudConfigLookup. This would have to
> represent a file in SCC that contains a mapping for accountNumber to
> something.
>
> There are a number of issues with this.
> 1. This still requires editing and committing a file.
> 2. It has the polling delay.
> 3. Log4j-Spring-Cloud-Config would have to cause the file to be monitored
> just as the config file is.
> 4. The syntax of the existing Filters requires that when looking for
> multiple users each must be specified in its own key. That would mean the
> filter would have to be preconfigured with the maximum number of accounts
> it can look for. It would also mean the syntax for specifying the account
> numbers could get messy. However, it could register a Watcher for the
> external file and force a reconfiguration when it does.
>
> An alternative to reconfiguring could be to specify the variable as
> $${src:accountNumber) and resolve the lookup for every log event.
> Presumably it would use a cached value and cause the value to change when
> the file is changed.
>
> These are just the first few things I thought of to do this. Does anyone
> else have any ideas?
>
> Ralph
