21
loading...
Logs y su importancia en las aplicaciones
Basado en mi experiencia en desarrollo de software y últimamente en el área de mantenimiento de software, decidí escribir este artículo en base a las falencias y ventajas que he encontrado en la escritura de logs en las empresas donde he prestado mis servicios; esto con el objetivo de mostrar a toda la comunidad la importancia de una correcta escritura de registros de log.
Cuando desarrollamos sistemas es más que natural que en ciertos puntos de la aplicación debemos dejar rastro de cual “camino” de nuestro sistema se ha ejecutado, con la finalidad de que cuando tengamos que analizar posibles errores de la aplicación, contemos con herramientas que nos faciliten el diagnóstico y solución de los mismos.
En este punto quizá te surja esta pregunta.
Bueno si eres de las personas que esta empezando el mundo de desarrollo de software, es posible que no notes la importancia de este componente esencial de los sistemas; pero a medida que tu carrera avance notarás la importancia de los mismos y porque las empresas invierten mucho dinero en tener estos archivos incluso bajo resguardo policial.
Una aplicación sin logs es como una persona sin memoria
Desde mi experiencia, acá te dejo unos aspectos de porque son importantes estos archivos:
Auditoria informática, considera un sistema bancario en el que por algún motivo se cometió un fraude, sin estos registros de log seria imposible determinar si en realidad se ha cometido un fraude.
Análisis de incidentes, El registro de log se asemejan a pistas de un posible crimen en el que el mismo investigador puede llegar a ser el asesino (tú), considera un error reportado en la aplicación que ha sucedido 1 mes antes de que el ticket de atención te llegue a ti. Sin los registros de log, sería imposible tratar de determinar qué fue lo que sucedió.
Dado el contexto anterior, a continuación te dejo mis consejos para una correcta escritura de logs:
1. Puntos de escritura de logs
Cuando te encuentres desarrollando un sistema, es necesario que identifiques los puntos adecuados donde se debería dejar rastro de log, es probable también que desde el diseño técnico de las funcionalidades no se encuentre detallado donde realizar esta tarea, por lo que es tarea de nosotros los desarrolladores identificar esos puntos.
Considera dentro de tus estimaciones, tiempo de análisis y programación de registros de log.
2. Manejo adecuado de los niveles de log
Creo que es de conocimiento de todo desarrollador que cuando escribimos instrucciones de rastro de logs en las aplicaciones independientemente de la tecnología que manejemos podemos manejar ciertos niveles, entre los mas comunes están:
INFO, WARNING, ERROR. El correcto uso de estos niveles garantizará que cuando nuestra aplicación llegue a producción no saturemos los archivos de log con líneas que no son necesarias en ambiente productivo o con posibles vulnerabilidades como dejar números de tarjetas de crédito en los archivos de log.
Cuando estes apunto de escribir una línea de log en tu programa, lo primero que debes hacer sería responder a estas preguntas:
3. Manejo de salidas estándar
Evita siempre manejar las salidas estándar para dejar rastro de log en tus aplicaciones, la salidas estándar por lo general son mas lentas que los frameworks especializados en logs y también pueden llegar bloquear los hilos de ejecución.
Sin embargo, esta funcionalidad podría servirte en tiempo de desarrollo para una visualización rápida de tus variables en consola, pero siempre recuerda al final de tu desarrollo borrar estas líneas o modificarlas para el uso de un framework de manejo de logs.
En este punto te dejo mi reflexión: “Que lance la primera piedra el que nunca ha usado
System.out.println(“Entro aqui”)".Y es que nadie que ha programado alguna vez en Java podrá decir que nunca ha usado la función println; es muy útil pero no debemos permitir que llegue esta línea a producción.
4. Evita escribir log que no aportará en diagnósticos de incidentes
Durante el desarrollo de software es normal que cuando nos encontramos en un pantano, dejemos ciertos logs para conocer el flujo de ejecución de nuestro programa, por ejemplo el clásico:
LOG.info(“—> entro <—“);Sin embargo, cuando este log llega a producción no tendríamos forma de conocer a que usuario/sesión pertenece esa ejecución o a cual transacción. Por lo que te recomiendo que antes de lanzar nuestro
commit al repositorio remoto de nuestro feature, revisemos que calidad de logs vamos a dejar y de ser el caso eliminar los innecesarios.Esto también aplica para caracteres que no nos aportan nada en diagnósticos, como en el caso de la línea de ejemplo, las flechas de la línea de log no nos ayudarán en nada a diagnósticos y mas bien ocuparán espacio en disco innecesario cuando tu aplicación entre en producción.
5. Log en excepciones
Este punto es muy importante, ya que cuando ocurra alguna excepción esperada o no de nuestra aplicación, es recomendable dejar rastro de la excepción que ocurrió a través de un log; con ello tendrás mas herramientas de diagnóstico de incidentes.
try {
// mi super código
}catch(Exception e) {
LOG.error("Ha ocurrido un error general ", e);
}6. Saltos de línea en logs
Siempre en la medida de lo posible considera que el log debe escribirse en una sola línea, cada línea debe pertenecer a alguna información de ayuda o seguimiento; adicional cuando dejamos log de una sola linea, tenemos la ventaja de realizar búsquedas en los archivos de log fácilmente, te lo explico con un ejemplo:
Considera que tenemos 2 archivos de logs:\
25-feb-2021 19:01:01 enviando transaccion con detalle : {
idTransaccion: 666,
monto: 1,
origen: APP
}25-feb-2021 19:01:01 enviando transaccion con detalle : {idTransaccion: 666, monto: 1,origen: APP}Supongamos que queremos buscar en logs, todo lo relacionado a la transacción 666, entonces si lanzamos un
grep sobre el archivo log1.log en el primer caso nuestra salida seria:grep 666 log1.log
# la salida es:
idTransaccion: 666,Lo cual no nos brinda mucha información, y posteriormente tendríamos que abrir el archivo gigante de log y buscar con un editor de texto el resto del log.
Ahora, si realizamos la búsqueda de esa misma transacción en el log sin salto de línea con
grep, el resultado sería este:grep 666 log2.log
# la salida es
25-feb-2021 19:01:01 enviando transacción con detalle : {idTransaccion: 666, monto: 1,origen: APP}El resultado es la línea entera de log que me brinda toda la información, con lo que podría realizar un seguimiento sin necesidad de abrir el archivo con algún editor y realizar búsquedas "manuales".
7. Manejo de información sensible
Evita dejar en log información sensible de tu aplicación como por ejemplo números de tarjetas de crédito, claves de acceso, keys de acceso a APIS; esto puede convertirse en una vulnerabilidad de riesgo alto y hace que tu sistema sea sensible y genere desconfianza.
Si la escritura de esta información es ineludible, te recomiendo que enmascares la data sensible, así por ejemplo si una key es de valor:
, al enmascarar este dato veríamos en logs de esta forma:
1234567890, al enmascarar este dato veríamos en logs de esta forma:
1xxxx90.Para realizar enmascaramiento de datos, podemos apoyarnos con el uso de expresiones regulares.
8. Rotación de logs
Es importante que como desarrolladores tengamos claro que nuestros sistemas no son mono usuarios y que una vez en producción los archivo de log crecerán exponencialmente, por lo que debemos tener en la mira un o varios procesos de rotación de logs y almacenamiento en un repositorio seguro.
De acuerdo a todo lo mencionado anteriormente, te presento las siguientes conclusiones:
Para finalizar, quiero agradecerte por tomarte tu tiempo para leer este artículo y si tienes alguna inquietud o sugerencia, por favor házmela saber.
También si te sirvió de ayuda y te gusto mi post, cómprame una cerveza 🍺 para poder seguir escribiendo este tipo de entradas.
Happy coding! 🙂
21