Hello Adam, I am very sorry for the frustrating experience. I can certainly see you do an excellent job in getting engaged with the project to get this feature request rolling. Thank you so much for that.
I read your conversation with Piotr and I get your point – yes, neither migration to Log4j 3 (which still has an unknown release date), nor augmenting the configuration is an option for you. I agree with your assessments there. Thinking naively: Assuming you already thought about it, why doesn't the following work for you? 1. Cast the `LoggerContext` to `AsyncLoggerContext` 2. Reflectively extract the `AsyncLoggerContext#loggerDisruptor` 3. Reflectively extract the `AsyncLoggerDisruptor#asyncQueueFullPolicy` 4. Call `DiscardingAsyncQueueFullPolicy.getDiscardCount()` on the policy instance Kind regards. On Wed, Apr 10, 2024 at 12:11 AM Thomas, Adam <adamt...@amazon.com.invalid> wrote: > I created a pull request[1] late last year for this, and was encouraged to > start a discussion on the dev list at the time. > > We run log4j2 on a lot of hosts that are operated by different teams. By > default, our users use async logging and use the Discard > asyncQueueFullPolicy. As far as I can tell, the status logger gets one WARN > message the first time an event is discarded, and during shutdown a TRACE > message is emitted if any discards happened. This leaves us with > essentially no insight as to whether or not events are actually being > discarded, when they are being discarded, or how many we are discarding. > > My pull request is pretty simple; the discarding policy already tracks > discards, and I expose a getter for this counter from > LoggerContext/AsyncLoggerContext. Polling the counter and pushing It to our > telemetry system is an exercise left up to the user (me). I don’t have any > real concerns about the safety of the change, but I have no idea how > acceptable it is as a change to the API surface. > > This also spawned a metrics proof-of-concept that was recently closed [2]. > I’m fine with a more complete metrics solution, but I’m not sure of the > timeline of such a solution, if any. > > How can I move forward on this pull request to make it acceptable, or is > there another way to accomplish this that would be more palatable? > > -Adam > > [1] https://github.com/apache/logging-log4j2/pull/1927 > [2] https://github.com/apache/logging-log4j2/pull/1943 >
