Mi reino por un "LOG"

Nunca hay que subestimar el poder de un buen Log, tampoco el de uno malo, pero puestos a elegir. Si Hansel y Gretel hubiesen tenido a su alcance un buena traza se hubiesen ahorrado mucho pan en forma de miguitas.

¿Que son los Logs?, pues a mi modo de ver son de forma simultánea la constatación del resultado de un hecho y el principio de una decisión. El resultado de un hecho porque siempre que se sea realista notifican algo que ha sucedido o está sucediendo, el resultado de una acción. Y el principio de una decisión porque en base a la información obtenida se puede decidir el siguiente paso de forma informada. Estas “trazas textuales” se ocultan a la vista del común de los mortales, todo en pro de un satisfactorio Customer Journey, no es necesario torturar de esta forma tan inhumana.

La historia no se debería reescribir. El transcurso de un suceso, la situación de un estado puede ser alterado de forma ventajista por el relator de la misma. Siempre ha sucedido a través de los tiempos que todo aquello no escrito negro sobre blanco puede terminar siendo alterado, en ocasiones de forma interesada y en otras simplemente ocurre, por cómo se interpretan los acontecimientos o simplemente porque el teléfono está "escacharrao". Blancos, negros y grises tiene mucho que aportar cuando el sesgo irrumpe en escena.

Los hechos son únicos y como afectan pervierten la forma en que son expuestos. Sucede en política, en los evangelios, en las guerras, en las familias, en resumen en todos los ámbitos de nuestra existencia. Los libros de historia, informáticamente hablando serían nuestros amigos los "Logs", ya sean el resultado de procesos de debbuging, o para constatar el resultado de un proceso. Los hay de muchos tipos; verbosos, vagos, simples marcas de "estuve aquí", absolutos -si/no bien/mal-. Son los notarios del reino tecnológico, dando fe de lo acontecido.

¿Traza y Log, son lo mismo?, pues depende que diría un gallego. Sin ánimo de polemizar en exceso, se podrían denominar sinónimos y no estaría mal, pero si se realiza un ejercicio más pormenorizado, quizás se llegase a la conclusión de que el segundo forma parte de la primera.

Los Logs son una de las piedras angulares de la mejora continua, en su vertiente tecnológica, son el arma secreta para saber que hizo quien, cuando y porque, cuanto se tardó y su resultado, todos estos datos bien cocinados pueden desencadenar decisiones que mejoren procesos, los optimicen y los vuelvan más fiables., pero para ello es preciso tener constancia de lo ocurrido, y esa es justo la parte habilitadora de los Logs.

Son casi como el "libro gordo de Petete", y antepongo el casi, porque son información no conocimiento, son un pozo inmenso de información mediante la cual forjar el conocimiento

Todo buen Log que se precie debe cumplir una serie de requisitos mínimos como son la marca de tiempo, que o quien lo género y si no es mucho pedir cierta normalización. Con estos requisitos mínimos ya se puede lubricar un poco la vida a los “Indiana Jones” de los problemas, optimizadores de procesos y en última instancia a los analistas, entre otros.

Merece mucho la pena dedicar un poco de tiempo y esfuerzo a formatear correctamente los mensajes para que sean homogéneos y realmente ayuden a conocer lo que está sucediendo y no se conviertan también en parte de un problema. Todo tiempo dedicado a esta labor redundará en un beneficioso ahorro para un futuro más que probablemente inmediato. Si se dedica demasiado esfuerzo a “entender” el contenido de un Log, algo no marcha bien. De hecho si no se encuentra entre uno de nuestros fuertes la normalización, no hay excusa posible, ya que como muchos antes ya han pasado por ahí y se disponen de estándares dependiendo del contexto, pueden ser más o menos de nuestro agrado, pero siempre quedara la aportación del granito de arena propio. El influjo de la comunidad.

Parece de sentido común que cuanta más información se facilite mejor, eso sí, es necesario hacer una buena definición de los niveles de granularidad para no enterrar a los interesados, esto nos lleva a incluir al menos un cuarto requisito, la pertenencia del nivel al que pertenece el mensaje. Digamos:

[info] [warning] [error] [debug]

Y ya puestos a pedir, la experiencia pide también identificar desde donde, sobre todo por aquello de los entornos distribuidos, para prever la integración necesaria ante el análisis de problemas. Esto ya hace que aumenten hasta cinco el número de requisitos. Es un error muy común cuando se trabaja en un contexto muy concreto olvidar incluir esta información, ya que cuando se debuguea se afronta el problema concreto en cuestión pero en un entorno productivo compuesto de múltiples contextos, determinar el dominio puede ser una tarea titánica e incluso imposible.

Los Logs, son un arma de doble filo, una ínfima cantidad de información, de poco sirve, y un exceso complicará discernir el grano de la paja. Además no sé puede obviar su coste, la tentación del “más madera” que diría Groucho Marx, la generación e ingesta de este dato consume y consume mucho; ciclos de reloj, memoria, acceso a disco, ancho de banda, espacio en disco y quizás lo más importante en su postprocesamiento, tiempo y esfuerzo. Quien haya tenido que parsear Logs a pelo, sabrá a lo que me refiero. El equilibrio entre lo relevante y lo menos relevante es de vital importancia. Ya hay unas cuantas decenas de herramientas que simplifican la tarea, pero por el mero hecho de la simplificación ocurre lo inevitable, simplemente nos venimos arriba con el RAW. Es tan simple como aplicar el sentido común, si tenemos “cosas” muchas “cosas” que carretear entre un punto A y otro B, pero entre ellas hay algunas inservibles y desechables, no sería más eficiente deshacerse de ellas en origen en vez de portearlas y tirarlas en destino. Pues eso, sentido común; que en ocasiones es el menos común de los sentidos.

Que nadie subestime el poder de un Log, aunque tiendan a ser extremadamente aburridos, aunque algunas compañías últimamente se han decantado por incluir mensajes motivadores y bromas en los mismos, en un intento de gamificar y hacer más gratificante -si es que eso es posible- la labor de revisar Logs. Desde el B2B pasando por el B2C para llegar al B2B2C, sin olvidar el C2C, y porque no nombrar el P2P, que por acrónimos no sea, tan solo son un pretexto para llegar al M2M, de qué forma se puede conocer, validar, verificar que está sucediendo o ha sucedido en una interacción entre entes no mortales y autónomos. La respuesta es simple al convertirnos en meros observadores de un sistema de referencia inercial, Logs, Logs, y por si fuera poco más Logs; con la esperanza de que todo vaya bien y no haya que echar mano de ellos. La esperanza es lo ultimo que se pierde, o al menos eso dicen.

Los obsesivos compulsivos, pueden pretender la locura de que absolutamente todo debe ser trazado, y en un mundo ideal así debería ser, pero si se deja la fantasía a un lado, lo que no es menos cierto es que se obtendría un estruendoso griterío, lleno de ruido y redundancias. Ni mucho ni poco es la justa medida, y esto sí que es complemente subjetivo. Hacer un LOG de todo es “materialmente” imposible o más bien innecesario, salvo que el objetivo sea ese; hacer Logs, pero como herramienta hay que vigilar que no se conviertan en un agujero negro de gasto; ley de Pareto de libro, donde el 80 es para entradas aburridas y poco interesantes; tendencia suicida hacia el error; y causa que la buena gente tienda desesperadamente hacia malas ideas como hacer uso de la IA.

Los Logs son el arma secreta de las estadísticas, de los cuadros de mando, de los análisis de comportamiento, de los automatismos, de los tests desatendidos, de la optimización. Depende de quien los precise, la información a perseguir en ellos puede diferir, un operador de sistemas, un administrador de negocio, un responsable de calidad, un operador de tests. La información a inferir es tan diversa como problemas se puedan presentar. E informáticamente hablando el trabajo consiste en resolver problemas constantemente, uno tras otro y sin descanso. Si se parte de la base de que el objetivo fundamental de un Log es resolver problemas, parece claro que la información que se debe incluir en él es aquella de la que gustaría disponer cuando ocurra un problema. El Log debe contener información relevante, que permita saber qué está ocurriendo en todo momento y a ser posible en el mejor HRF que se sea capaz de crear.

Cuando nos enfrentamos a la disyuntiva de dedicar esfuerzos a la generación de un Log, no hay que olvidar que la última línea de soporte podríamos ser nosotros, y cuando llegue -que llegará- el momento de solucionar un problema, pueden marcar la diferencia entre resolver un problema en un tiempo razonable o quizás no tanto.

Los logs son una gran herramienta informacional en el desarrollo de software, sobre todo cuando el resultado no es el esperado. La creatividad está mucho más “restringida” en los ámbitos de sistemas y servidores de aplicaciones donde más allá de la configuración verborreica, escasa manipulación más está permitida. Pero, pero, que seria actualmente sistemas sin IaaC, no es que esto haya venido solo a fomentar la creatividad “logera” en sistemas, pero equipara el enfoque a las necesidades del desarrollo de software. La generación de estas trazas no debe incurrir en que el esfuerzo de este suministro sea mayor que el objeto para el que fue creado en cuestión el artefacto, esto podría ser un indicador de que quizás haya que revisar el conocimiento del lenguaje o del negocio -lo que se indicaba de la mejora continua en diferido-.

La ingesta y almacenamiento se pueden volver el talón de Aquiles, hay que evitar a toda costa sufrir el cotidiano problema del trastero, disponer de una estrategia clara de archivado y limpieza, siempre y cuando la ley no obligue, es una buena anticipación para no disipar la utilidad de estos instrumentos. La omnipresencia provoca que la cantidad de información se vuelva ingobernable.

Out-of-Topic. Que sería de una auditoria sin un suculento menú de Logs , sin su acta bien aderezada, sin su parte de horas gustosamente escabechado, sin su planificación bien deconstruida, sin su análisis de riesgos cocinado al vacío, sin sus resultados cocidos a baja temperatura y no puede faltar su buena espuma de protocolos de seguridad. Si, todos esos pantagruélicos platos que degustan los glotones auditores, y por supuesto que no dejan de ser Logs, con guía de estilo, pero Logs.

Es un escenario habitual, ejecutar multitud de aplicaciones al mismo tiempo y es muy común que su trazabilidad se reduzca, en el mejor de los casos, a Logs amontonados en el disco duro, y en el peor, a simples trazas de texto por pantalla tipo “print” que pestañeas y te las pierdes. Las implicaciones de esto son claras, no ya solo para el ecosistema sino para el negocio:

• Visibilidad nula de errores para los equipos de desarrollo y/o sistemas. En otras palabras, será difícil detectar problemas y solucionarlos con rapidez.
• Metodología de trabajo no estandarizada, es decir, cada usuario aplicará su propia forma basada en su experiencia.
• Accesos e información descentralizada que causará dificultades para trabajar con estos datos.
• Incremento del tiempo de respuesta ante una incidencia que afectará a niveles de servicio.

Casi siempre pasa lo mismo, se comienza con gran ímpetu y en la medida que se avanza el fuelle pierde recorrido. Sucede algo similar con los comentarios descriptivos en el código, la calidad del detalle al comienzo es exquisita, 2000 líneas después no tanto. Y algún visionario inventó el concepto de Clean Code, ahora sin comentarios, sin Logs y encima razonado.

“Ahora vas y lo kaskas”

El único inconveniente es que en algunos casos se ha malinterpretado el principio YAGNI. 

Hay otro apartado para lo que sirven los Logs, y es para detectar conocimiento, si alguien ante un problema una de las primeras tareas que acomete es pedir o buscar un Log, sabe lo que se hace; tío listo.

No es una exageración, en absoluto, pensar que en estos tiempos donde da la impresión de que los cinco 9’s deben ser dogma, alguien en algún lugar en algún momento se encuentra desbrozando un Log.

2022-04-22 22:13:26 ssmmss brain:storming EOF