In the fast-paced environment of modern software development, effective logging is crucial for efficient debugging and system monitoring. However, inconsistent or inaccurate line numbers in log outputs can make troubleshooting time-consuming. Recently, I identified that our internal logging utility was reporting itself as the source of the logs. This needed to be addressed to enhance the log precision.

The Problem

When using a custom utility class to handle logs, it will start reporting itself as the source of the log, as the utility class is the one that finally calls the actual log framework (in my case, it was SLF4J, with Log4J2 as the backend).

So, if the utility class is called InternalLogger, the log will look something like:

2024-10-11T18:10:57,345 [finagle/netty4-6] (InternalLogger.java:34) INFO ...  

Here, the reported source file and line number points to a location within the logging utility itself, rather than where the log call was actually made in the application code. This behavior mitigates the effectiveness of logs in debugging and pinpointing issues quickly.

The Solution

First I thought of manually walking down the stack trace and filtering out some elements before reporting the line number. This approach would be very costly, and I didn’t want to slow down our logging process.

Luckily, I found in this StackOverflow answer that SLF4J provides an interface called LocationAwareLogger, which Log4J2 supports, so, we can filter the utility class by simply passing the Log Utility Class' FQCN (Fully Qualified Class Name).

My original utility class looked something like this:

public class InternalLogger {



  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);



  public void log(EventLog eventLog) {

    //... get message and logLevel from eventLog

    switch (logLevel) {

      case DEBUG:

        LOG.debug(message);

        break;

      case WARN:

        LOG.warn(message);

For this solution, I declared the Logger class FQCN and added a private helper function to log with a LocationAwareLogger:

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();



  private void locationAwareLog(int level, String message) {

    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);

  }

And changed my old code to call it if supported:

switch (logLevel) {

  case DEBUG:

    if (LOG instanceof LocationAwareLogger) {

      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);

    } else {

      LOG.debug(message);

    }

    break;

  case WARN:

    if (LOG instanceof LocationAwareLogger) {

      locationAwareLog(LocationAwareLogger.WARN_INT, message);

    } else {

      LOG.warn(message);

    }

//...

Unluckily, SLF4J doesn't provide a way to provide the level as an argument (i.e. LOG.log(level, message)). If it did, the code would be a little less verbose.

After implementing this change, logs now accurately report the caller’s line number, significantly improving traceability:

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

Notice the difference: InternalLogger.java:34 versus ActualLogic.java:1059, which indicates a more precise location of the log origin within the application code.

Conclusion

By incorporating SLF4J's LocationAwareLogger, I have transformed our logging system from a source of confusion into a precise diagnostic tool. This change enables accurate reporting of the caller's line number instead of that of the logging utility, greatly enhancing our ability to diagnose issues swiftly and accurately.

This improvement not only streamlines debugging but also reduces response times when addressing software issues.

Developers facing similar challenges should consider this approach to elevate the effectiveness of their logging systems. With clearer and more accurate logs, they can turn what was once ambiguous data into actionable insights, improving both operational efficiency and software reliability. Optimized logging is crucial for meeting the challenges of today’s fast-paced development landscape and ensuring high-quality software outcomes.