Ralph, I do not believe that there exists a "one size fits it all"
solution. Yes, running in debug log has drawbacks and should not be
necessary. And yet I learned that only debug logs may provide enough
insights. The cause for this is simple: developers test code at "debug"
level and when time is short, may not add enough log statements on info.
My intention was to push the horizon and I wanted to share this idea only
because I read "hundreds of applications are configured from a single
configuration file that should be modified only by qualified personnel". To
me this single configuration file sounds like a single point of failure
where even only a small typo can have devastative effect. Looking for a
solution that goes beyond the logging configuration may be a good idea in
such a case.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sun, Apr 10, 2022, 07:21 Ralph Goers <ralph.go...@dslextreme.com> wrote:
> What you propose below is exactly what I described in my previous post.
> Whether it makes its way into Log4J will depend on how generally useful it
> ends up being.
>
> As for distributed tracing, yes, of course it is, it is the collection of
> logs for a single user or account across all the components involved in
> processing a request. But while the problem may occur in component B it may
> be caused by something that happened in component A, so you need all the
> logs as if they came from a single application to diagnose the problem. Of
> course, all the logs need correlation data to be able to do this.
>
> Ralph
>
> > On Apr 8, 2022, at 4:32 PM, Volkan Yazıcı <vol...@yazi.ci> wrote:
> >
> > 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
>
>
