Los logs son información provista por un sistema operativo o aplicación que ayuda a identificar qué se está haciendo, esto incluye errores, problemas o advertencias menores.
Si bien se definió un formato para los logs, conocido como syslog, la mayoría de las aplicaciones cuentan con su propio formato.
Independientemente del formato que utilicemos, los logs que nosotros diseñamos tienen que ser lo suficientemente claros y concisos para poder transmitir con claridad lo que queremos informar. Esto es inclusive más importante si se trata de loggear un error o una excepción, ya que por definición son anomalías en la ejecución de nuestro programa. Si algo falló, es necesario saber qué y dónde. Por ejemplo, supongamos que realizamos un llamado a un servicio, en el caso de no obtener la respuesta esperada, la excepción que lancemos debería indicarnos el nombre del servicio y cualquier información presente que hayamos enviado, como lo puede ser un id. Por ende, si este servicio provee un endpoint para buscar usuarios por id, cuando lo llamemos desde otro servicio y no logremos obtener el usuario esperado, el mensaje a mostrar debería ser del estilo “Ocurrió un error en la comunicación con {{nombre de la api}} al buscar al usuario de id {{id}}”. Por supuesto que cómo se pasa el valor del id dependerá del lenguaje con el que estemos trabajando.
Si buscas más información sobre la estructura y el propósito de los logs, te recomiendo leer este árticulo https://somospnt.com/blog/246-que-es-un-log-como-esta-formado
Estrechamente ligado a los logs está el stack trace, el cual es una lista de los métodos que fueron llamados hasta el punto en el que el programa falló. Su propósito es ayudar a identificar el lugar en el que algo salió mal. Visto de otra manera, si no tuviésemos a disposición el Stack Trace, nuestro programa sería como una caja negra en la que no sabemos qué salió mal, ni dónde pasó ni qué buscar.
Ahora bien, si bien contamos con el Stack Trace, por sí solo no nos va a solucionar nada, va a depender de la correcta utilización que le demos. Lo que normalmente se recomienda es empezar buscando referencias a nuestro propio código, ya que si bien podemos estar trabajando con diferentes librerías de terceros, lo mejor es asegurarnos que lo que hayamos hecho nosotros esté bien. Siguiendo este razonamiento, debemos buscar en el Stack Trace la primera referencia a nuestro código. Si por ejemplo detectamos una referencia a un método que hicimos, lo que se aconseja es empezar por ahí y seguir con los pasos previos a la invocación de ese método para detectar ese error.
Como programadores, tener que recurrir al Stack Trace y la consecuente lectura de logs no es una tarea feliz ya que implica que algo salió (o hicimos) mal. Puede resultar frustrante tener que afrontar la situación de buscar el motivo por el cual nuestro programa no funciona, pero evidentemente lo mejor es mantener la calma y utilizar estás herramientas para poder encontrar y corregir el error.