Revisar logs nos pone en una posición particular, una suerte de escena del crimen, donde nosotros somos simultáneamente no solo el investigador, sino que también los perpetradores. A continuación, veremos cómo podemos dejar evidencia que pueda ayudar a que nuestra tarea detectivesca sea más sencilla.

Empecemos repasando que son las excepciones. Estas ocurren ante eventos inesperados dentro de la ejecución de nuestra aplicación, un método queriendo realizar una operación sobre un objeto nulo, un servicio nos respondió un error o incluso que se acabe la memoria de nuestra aplicación.

Normalmente las excepciones se reflejan automáticamente en los logs sin mayor inconveniente, el problema es cuando nosotros mismos sin notarlo, nos ocultamos la información. Una forma bastante común en la que podemos hacer estos es cuando usando un bloque try-catch.

Imaginemos el siguiente escenario, nuestra aplicación debe buscar a una persona por su nombre, pero nuestra base de datos no está funcionando correctamente y se produce un error.

Try{

UsuarioService.buscar("Carlos”);

} catch(Exception e){

throw new customException(“Se produjo un error”);

}

Dejando de lado lo poco esclarecedor que es este mensaje, estamos perdiendo que ocasionó la excepción original y lanzando nuestra excepción personalizada. Y si a eso le añadimos que este catch captura cualquier tipo de excepción, nos estamos asegurando un dolor de cabeza en el futuro. Podemos solucionar esto incluyendo en la excepción que creamos nosotros, pero hay otra forma en la que podemos llegar a perjudicarnos y es la siguiente:

Usuario usuario;

Try{

Usuario =UsuarioService.buscar("Carlos”);

} catch(Exception e){

}

Return usuario;

 

Estos errores son conocidos como fallos silenciosos  y probablemente sea lo que mas dolor de cabeza nos genere, estamos recibiendo un usuario nulo, pero no hay registro de que pasará nada, podemos estar horas y horas, pero hasta que no revisemos el código, nada nos dará una pista de que falló o si hubo un falló o no.

Ahora veamos veamos como mejorar la calidad de lo que loggeamos

Ahora bien, manejamos nuestras excepciones adecuadamente, pero eso no evitará que surja un error en producción, ¿Como podemos asegurarnos para que nuestros logs nos brinden la información necesaria cuando esto eventualmente ocurra? 

• Usar el nivel adecuado: los archivos de logs cuentan con distintos niveles debido a su severidad, usarlos correctamente permite que la búsqueda de los errores se pueda realizar de manera más rápida.

 

• DEBUG: principalmente para la etapa de desarrollo, mostrará todo lo que ocurra en la aplicación. Útil para quitar entradas innecesarias que no sean relevantes en un ambiente productivo.
• INFO: todas las acciones realizadas por el usuario o por la aplicación.
• WARN: advertencias que pueden representar un problema, pero que no afectan el funcionamiento del programa. Ej.: el servidor está quedándose sin memoria o la base de datos está tardando mucho tiempo para realizar operación.
• ERROR: Todos los errores que impidan la ejecución de una operación deberían loggearse en este nivel.
• FATAL: Este nivel solo debería ser utilizado lo mínimo indispensable, estos errores en general implican que la aplicación.

• Que sí y que no: no siempre es sencillo identificar qué información incluir, pero como regla general es buena práctica incluir:

• Todas las excepciones, con los parámetros de invocación con los que se produjo el error
• Procesos automáticos del sistema (comienzo y fin)
• Comunicación con otros servicios/aplicaciones.
• Fallos de autenticación
• Comienzo y fin de procesos largos o complejos

Y también como regla general, por razones de seguridad se debe mantener fuera de los logs: contraseñas, información personal y/o cualquier tipo de información que pertenezca a un usuario.

• Evitar la ambigüedad: ser claros con lo que ocurre y evitar loggear mensajes genéricos nos ahorrará dolores de cabeza. Encontrar en los logs “Ha ocurrido un error” ayuda poco y nada para conocer que ocurrió.