En el entorno acelerado del desarrollo de software moderno, el registro efectivo es crucial para una depuración y un monitoreo del sistema eficientes. Sin embargo, los números de línea inconsistentes o inexactos en las salidas de los registros pueden hacer que la resolución de problemas lleve mucho tiempo. Recientemente, identifiqué que nuestra utilidad de registro interno se informaba a sí misma como la fuente de los registros. Esto debía solucionarse para mejorar la precisión del registro.

El problema

Cuando se utiliza una clase de utilidad personalizada para manejar registros, comenzará a informarse a sí misma como la fuente del registro, ya que la clase de utilidad es la que finalmente llama al marco de registro real (en mi caso, fue SLF4J , con Log4J2 como backend).

Entonces, si la clase de utilidad se llama InternalLogger, el registro se verá así:

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

Aquí, el archivo fuente informado y el número de línea apuntan a una ubicación dentro de la propia utilidad de registro, en lugar de donde realmente se realizó la llamada de registro en el código de la aplicación. Este comportamiento mitiga la eficacia de los registros a la hora de depurar y detectar problemas rápidamente.

La solución

Primero pensé en recorrer manualmente el seguimiento de la pila y filtrar algunos elementos antes de informar el número de línea. Este enfoque sería muy costoso y no quería ralentizar nuestro proceso de registro.

Afortunadamente, encontré en esta respuesta de StackOverflow que SLF4J proporciona una interfaz llamada LocationAwareLogger, que admite Log4J2, por lo que podemos filtrar la clase de utilidad simplemente pasando el FQCN (nombre de clase completo) de la clase de utilidad de registro.

Mi clase de utilidad original se veía así:

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 solución, declaré la clase Logger FQCN y agregué una función auxiliar privada para iniciar sesión con 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);
  }

Y cambié mi código antiguo para llamarlo si es compatible:

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

Desafortunadamente, SLF4J no proporciona una forma de proporcionar el nivel como argumento (es decir, LOG.log(nivel, mensaje)). Si así fuera, el código sería un poco menos detallado.

Después de implementar este cambio, los registros ahora informan con precisión el número de línea de la persona que llama, lo que mejora significativamente la trazabilidad:

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

Observe la diferencia: InternalLogger.java:34 versus ActualLogic.java:1059, que indica una ubicación más precisa del origen del registro dentro del código de la aplicación.

Conclusión

Al incorporar LocationAwareLogger de SLF4J, he transformado nuestro sistema de registro de una fuente de confusión a una herramienta de diagnóstico precisa. Este cambio permite generar informes precisos del número de línea de la persona que llama en lugar del de la utilidad de registro, lo que mejora en gran medida nuestra capacidad para diagnosticar problemas de forma rápida y precisa.

Esta mejora no solo agiliza la depuración sino que también reduce los tiempos de respuesta al abordar problemas de software.

Los desarrolladores que enfrentan desafíos similares deberían considerar este enfoque para elevar la efectividad de sus sistemas de registro. Con registros más claros y precisos, pueden convertir lo que antes eran datos ambiguos en conocimientos prácticos, mejorando tanto la eficiencia operativa como la confiabilidad del software. El registro optimizado es crucial para enfrentar los desafíos del acelerado panorama de desarrollo actual y garantizar resultados de software de alta calidad.