Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log4j2Metrics inaccurate with async appender #3980

Closed
ksambhav opened this issue Jul 12, 2023 · 2 comments
Closed

Log4j2Metrics inaccurate with async appender #3980

ksambhav opened this issue Jul 12, 2023 · 2 comments
Labels
duplicate A duplicate of another issue

Comments

@ksambhav
Copy link

ksambhav commented Jul 12, 2023

io.micrometer.core.instrument.binder.logging.Log4j2Metrics reports inaccurate metrics in case of async appender.
The decision to increment the counter is done by method :-

        @Override
        public Result filter(LogEvent event) {

            if (!isAsyncLogger || isAsyncLoggerAndEndOfBatch(event)) {
                incrementCounter(event); // always increments the counter by 1
            }

            return Result.NEUTRAL;
        }

When isAsyncLoggerAndEndOfBatch(event) is true, counter should get incremented by "batch" size. (Not sure if its possible to get it from LogEvent parameter.

Environment
PROD

  • Micrometer version : 1.11.1
  • Micrometer registry : Any. I tried with AzureMetricRegistry and SimpleRegistry
  • OS: Linux
  • Java version: 17

To Reproduce
How to reproduce the bug:
Unzip and run attached Spring Boot application. It prints 2000 error level logs in burst every 30 secs.
Counter can be accessed using http://localhost:8080/actuator/metrics/log4j2.events

Repeat again with sync appender by change <AsyncRoot> to simply <Root> in log4j2.xml. This time counter value will be correct this time.

Expected behavior
Counter should report accurate metrics in case of async appender

Additional context
https://stackoverflow.com/questions/76660558/log4j2-metrics-with-micrometer
Archive.zip

@shakuzen
Copy link
Member

It sounds like this is a duplicate of #2176. Let me know if you disagree and why. We can reopen if it is a separate issue.

@shakuzen shakuzen closed this as not planned Won't fix, can't repro, duplicate, stale Jul 27, 2023
@shakuzen shakuzen added duplicate A duplicate of another issue and removed waiting-for-triage labels Jul 27, 2023
@ksambhav
Copy link
Author

If the fix for #2176 will also cover case when counter is increment by the "batch size" instead just 1, we can keep this one closed. In the end we just want accurate count anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

2 participants