No ambiente acelerado do desenvolvimento de software moderno, o registro eficaz é crucial para depuração eficiente e monitoramento do sistema. No entanto, números de linha inconsistentes ou imprecisos nas saídas de log podem tornar a solução de problemas demorada. Recentemente, identifiquei que nosso utilitário de registro interno estava se reportando como a origem dos registros. Isso precisava ser resolvido para melhorar a precisão do log.

O problema

Ao usar uma classe de utilitário personalizada para lidar com logs, ela começará a se reportar como a origem do log, já que a classe de utilitário é aquela que finalmente chama a estrutura de log real (no meu caso, foi SLF4J , com Log4J2 como backend).

Então, se a classe do utilitário for chamada InternalLogger, o log será parecido com:

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

Aqui, o arquivo de origem relatado e o número da linha apontam para um local dentro do próprio utilitário de registro, em vez de onde a chamada de registro foi realmente feita no código do aplicativo. Esse comportamento mitiga a eficácia dos logs na depuração e na identificação rápida de problemas.

A solução

Primeiro pensei em percorrer manualmente o rastreamento de pilha e filtrar alguns elementos antes de relatar o número da linha. Essa abordagem seria muito cara e eu não queria retardar nosso processo de registro.

Felizmente, descobri nesta resposta do StackOverflow que o SLF4J fornece uma interface chamada LocationAwareLogger, que o Log4J2 suporta, portanto, podemos filtrar a classe do utilitário simplesmente passando o FQCN (nome de classe totalmente qualificado) da classe de utilitário de log.

Minha classe de utilitário original era mais ou menos assim:

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);

Para esta solução, declarei a classe Logger FQCN e adicionei uma função auxiliar privada para registrar com um 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);
  }

E mudei meu código antigo para chamá-lo, se houver suporte:

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);
    }
//...

Infelizmente, o SLF4J não fornece uma maneira de fornecer o nível como argumento (ou seja, LOG.log(nível, mensagem)). Se assim fosse, o código seria um pouco menos detalhado.

Depois de implementar essa mudança, os registros agora informam com precisão o número da linha do chamador, melhorando significativamente a rastreabilidade:

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

Observe a diferença: InternalLogger.java:34 versus ActualLogic.java:1059, que indica uma localização mais precisa da origem do log dentro do código da aplicação.

Conclusão

Ao incorporar o LocationAwareLogger do SLF4J, transformei nosso sistema de registro de uma fonte de confusão em uma ferramenta de diagnóstico precisa. Essa alteração permite relatórios precisos do número da linha do chamador, em vez do utilitário de registro, melhorando significativamente nossa capacidade de diagnosticar problemas com rapidez e precisão.

Essa melhoria não apenas simplifica a depuração, mas também reduz os tempos de resposta ao resolver problemas de software.

Os desenvolvedores que enfrentam desafios semelhantes devem considerar esta abordagem para aumentar a eficácia de seus sistemas de registro. Com registros mais claros e precisos, eles podem transformar dados antes ambíguos em insights acionáveis, melhorando a eficiência operacional e a confiabilidade do software. O registro otimizado é crucial para enfrentar os desafios do cenário de desenvolvimento acelerado atual e garantir resultados de software de alta qualidade.