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
