Haz un análisis de sangre a tu software

Me gusta pensar que el software es un ser vivo que, tiene síntomas antes de enfermar, se puede curar, y por supuesto, tiene un ciclo de vida, nace, crece, se reproduce (copia y pega) y muere. Tampoco hace falta llegar al extremo de asegurar que tenga sentimientos pero un algoritmo de orden N siempre será más feliz que uno de orden N^2.

Siguiendo con la analogía con los seres vivos, necesitamos establecer qué podemos considerar que es la savia del software, la sangre, su fluido vital, y para mí son sin duda los logs de las aplicaciones. Si, sé que mucha gente los considerará más un fluido de desecho, del que también se saca información para curar al enfermo, pero sea de uno u otro modo, conviene hacerse un análisis de vez en cuando para controlar la salud general del software.

El software parte con una ventaja inmensa frente a los seres vivos, somos capaces de mantener su sangre analizada constantemente, pero otra cosa es que especialistas miren los análisis, y en eso acabamos por igualarnos. Imagina que pudieses tener monitorizado el contenido de tu sangre de forma constante, podrías saber de manera inmediata qué hábitos te provocan reacciones en tu salud, ¿acaso dejarías de pasar una oportunidad como esa para estar sano?. Seguramente no, por lo que deberías aplicar el mismo criterio a tus aplicaciones.

Si no tienes un sistema de correlación o agregación de logs, hazte con uno de inmediato. Hay multitud de ellos en el mercado y muchos de ellos de software libre:

• ELK: ElasticSearch, Logstash y Kibana es quizá el más conocido, quizá un poco más complejo para empezar pero muy potente cuando se acaba por dominar. (https://www.elastic.co/elk-stack)

• Graylog: Con componentes comunes con el anterior (ElasticSearch) pero que usa MongoDB y una interfaz gráfica más sencilla para empezar. (https://www.graylog.org/)

• Splunk: Una solución en la nube por si no quieres complicarte la vida montando infraestructura.  (https://www.splunk.com/)

Por supuesto que hay muchos más, pensados para todo tipo de software porque no es lo mismo analizar sangre de una aplicación web que de un router o un firewall donde buscas prevenir no tanto la salud del enfermo sino la dieta de lo que entra al sistema, y claro está, cuanto más enfocado esté el análisis mejor podrás diagnosticar al paciente o evitar que se infecte.

Este artículo no viene a darte una recomendación de cuál es el mejor para ti, dependerá de muchos factores, lo que si que trato es de animarte a que si no tienes ninguno de estos sistemas trates de ponerlo como prioridad, no te será tan complejo como pueda parecer, y que si lo tienes mires los resultados del análisis, aprenderás a sacarle partido. Para terminar de convencerte te contaré un par de casos con los que estoy seguro que te encontrarás la primera vez que empieces a utilizar este tipo de análisis sobre tu sistema, por muy buena salud que creas que tiene:

• Error esporádico: Antes de disponer de uno de estos sistemas es posible que hayas mirado los logs más de una vez, generalmente para resolver problemas y que te hayas encontrado con un error, que nada tenía que ver y que en el momento de crisis simplemente ignoras. Pues bien, llegará este implacable análisis para cuantificar este tipo de errores y hacerte ver que probablemente no era tan esporádico como creías e incluso que tiene un patrón y se debe a algo concreto, puede que poco importante, pero serás capaz de depurarlo. 

• Falso positivo: Este caso también es muy común, se trata de el típico mensaje de error que se emite para indicar que todo es correcto, bazinga !! Si, es cierto que en los entornos de producción los niveles de log son más restringidos por lo que en ocasiones en estos entornos sólo se deja constancia de los problemas en el log, y debes suponer que “no news good news”, pero a veces te ves tentado a dejar constancia explícita del éxito, pero claro cambiar el nivel de log puede provocar que se deje constancia de muchas más cosas que no te interesan. En ese momento el diablillo de la mala práctica te susurra al oído que emita tu mensaje de confirmación como un error para poder así verlo en producción, pero ahora en tu análisis te dirá que tienes un error, cuando en realidad no lo es. 

Se que ahora mismo piensas que Google Analytics te está ayudando en parte a hacer esto, y lo cierto es que, siguiendo con la analogía, podemos decir que es el amigo fiel que cada día al verte te dice si tienes buena cara o no, y te invita a visitar al doctor, pero difícilmente va a poder dar un diagnóstico del motivo por el cuál tienes tan mala cara. Una cosa a la que si te puede ayudar es Google Tag Manager, que te puede dar log de errores de los clientes. Tu aplicación falla en los clientes, los contagias a través de tu javascript, y en ese caso, puedes recopilar muestras de sangre de tus usuarios para diagnosticar la enfermedad que les estás contagiando y a la que tú eres inmune.

Sea como sea, una vez que empieces no podrás parar, la sangre que corre por las venas de tu software no va a parar de darte información sobre lo que pasa de forma constante, y querrás más. ¿Es posible saber la cantidad de errores 500, las peticiones POST, los logins por minuto,…? La respuesta es clara, podrás saber todo lo que quieras, basta con que hagas que fluya por la sangre de tu software.