Logging de una aplicación en Java

El logging de una aplicación consiste en registrar (logs) información relevante del comportamiento de la ejecución de nuestra aplicación. Contiene datos de variables, entidades, cambios de estado,  componentes de software involucradas en dicha ejecución y la llamada de los métodos. Su principal funcionalidad es facilitar el seguimiento o análisis de la ejecución de la aplicación:

• Analizar el comportamiento de la aplicación durante la fase de desarrollo y depuración (pruebas de caja blanca)
• Analizar los bugs o errores de ejecución detectados, sus causas y consecuencias
• Servir de registro de auditoría cuando la información contenida y el modo en que se ha procesado cumpla los criterios requeridos
• Medir el rendimiento o carga de los sistemas o aplicaciones
• Revertir el estado del aplicativo siguiendo en orden inverso el log

Aunque depende de las circunstancias en las que nos encontremos, el segundo de los usos suele ser el más relevante. Un buen log desarrollado correctamente en el código y mantenido o configurado en explotación es una garantía de respuesta rápida para análisis de errores; que incluso podrían hacerse sin necesidad de parar el aplicativo, reconfigurarlo o aplicarle ningún cambio.

El log o registro de la aplicación suele formarse por un conjunto de eventos que se almacenan secuencialmente, por lo general en el orden en que suceden, de manera persistente o recuperable. Se pueden almacenar en ficheros, en BBDD, en componentes distribuidos a tal efecto. Se pueden habilitar mecanismos de rotación o históricos de estos logs, se pueden utilizar por monitores para lanzar alertas, se pueden integrar y fusionar para hacer análisis más exhaustivos. Lo relevante es que la información registrada y la forma en que se gestiona sea útil.

Existen numerosas soluciones y propuestas de software, tanto libres como propietarias, más o menos estandarizadas, más sencillas o más completas, de mil tipos y formas. Lo importante es buscar aquella se ajusta a nuestras necesidades y entornos, para olvidarnos de la implementación del mecanismo por completo; y ceñirnos a los dos aspectos más importantes:

• El contenido de cada registro o evento, principal preocupación del desarrollador
• El modo en que se procesa, persiste y gestiona, principal preocupación de la explotación del sistema o aplicativo

El coste de implementación del logging se encuentra en el ir, mientras se desarrolla, dejando registros (logs) en los diferentes puntos del código. Esta actividad debe hacerse durante el desarrollo, siguiendo patrones, criterios y procedimientos preestablecidos. De esta manera los desarrolladores tendrán criterios comunes y los logs serán coherentes entre las diferentes partes del código.

La información registrada en el log debe ser relevante y completa. Se pueden considerar los siguientes aspectos a la hora de decidir qué información incluir:

Qué:

Qué evento o acción ha ocurrido.

Qué entidades han estado involucradas.

Si hay un cambio de estado, ¿Cuál era el anterior? ¿Cuál es el nuevo estado?.

Dónde:

En qué punto del código ha ocurrido: componente, clase, fichero de código, método o bloque de ejecución, línea de código… Cuanto más detallada sea esta información mejor para localizar el lugar del posible error o por donde ha pasado la ejecución, por un lado; pero más puede afectar el logging al rendimiento.

Cuándo:

Registrando el momento temporal, bien absoluto o bien relativo al comienzo de ejecución o cualquier otro evento.

Generando los logs secuencial o causal, en la que los eventos que ocurren antes en el tiempo o que ocasionan otros, aparezcan antes.

En qué contexto:

Registrando estados o variables: propios de la ejecución (parámetros), de personalización o específicos de usuario, referentes a la sesión o transacción en ejecución…

Indicando hilos, transacciones o peticiones relacionadas cuando estemos en entornos concurrentes.

Para que la información de los logs sea más detallada en momento de análisis y más manejable durante la explotación de la misma, se establecen niveles de filtrado. De tal manera que solo se muestra o almacenan aquellos eventos con un nivel mayor o igual al del nivel de log establecido. Las librerías de logging permiten filtrar los eventos por otros criterios como son la clase o contexto del evento, también.

Los niveles más comunes son DEBUG, INFO, WARNING y ERROR. La clasificación de los diferentes eventos en cada nivel es parte del ejercicio de análisis, y deben orientarse a que la traza sea legible y útil en los diferentes contextos del aplicativo, desde el desarrollo hasta la explotación.

Este puede ser un ejemplo de semántica de niveles de logging:

DEBUG: para información de muy bajo nivel solo útil para el debug de la aplicación, tanto en el desarrollo como en el análisis de incidencias

Llamadas a funciones y procedimientos y otros componentes, con parámetros y respuestas

Flujos de ejecución

Desarrollo de algoritmos y procedimientos que permitan identificar y seguir su ejecución en desarrollo

INFO: información de más alto nivel que permita hacer un seguimiento de la ejecución normal

Paradas y arranques de servicios y sistemas

Parámetros críticos o relevantes de configuración

Comienzo y fin de transacciones y operaciones completas

Cambios de estado de operaciones

WARN: información de situaciones, que aún sin ser de error, si son anómalas o no previstas, aunque el aplicativo tiene alternativas para solventarlas

Parámetros no definidos, y cuyo valor se toma por defecto

Situaciones anómalas, pero que son resueltas por el aplicativo, dejando la operación en un estado correcto

Funcionalidades no primordiales o imprescindibles, que no pueden resolverse, pero que dejan la operación en un estado correcto

ERROR: información de situaciones que son de error y que impiden la ejecución correcta de una operación o transacción, pero sin afectar a otras operaciones o transacciones (error aislado o contenido)

No se pudo realizar una operación o transacción, pero no afecta a otras

Peticiones o consultas erróneas (almacenando los parámetros de entrada)

Funcionalidades generales del aplicativo, que aún afectando al funcionamiento general del aplicativo, no se consideran primordiales o imprescindibles

FATAL: información de situaciones de error que afectan al funcionamiento general del aplicativo (errores no aislados o contenidos en alcance)

Parámetros no definidos o configuraciones erróneas

Falta de conexión o comunicación con otros componentes

Errores de ejecución que pueden afectar a operaciones o transacciones independientes, o que afectan al funcionamiento general de la aplicación

Tanto el contenido y forma de cada evento de log, como la semántica de los niveles son parte del diseño del aplicativo. Estos criterios deben definirse y ser comunicados al equipo de desarrollo para que se apliquen de manera homogénea y coherente en todo el desarrollo. Si estos criterios son consensuados con el equipo se puede sacar mucho provecho de la experiencia de los desarrolladores.

Otras recomendaciones a tener en cuenta son:

Registrar los eventos de manera atómica, que toda la información referente a un evento se almacene en un registro o línea.

Orientar el formato de la información mostrada a poder ser usado de manera informatizada o automática con herramientas específicas.

En lo referente a excepciones:

Mostrar siempre la traza (trace o llamada secuencial de los métodos) completa de la excepción con su mensaje y todo el stacktrace.

Si la excepción es capturada, tratada y luego lanzada de nuevo (bien la misma u otra) no dejar traza de la excepción hasta que se capture y se trate en última instancia. De esta manera cada excepción solo se mostrará una vez. Si no lo hacemos así y registramos cada captura y relanzamiento aparecerá en la traza varias veces y no sabremos si es la misma o son varias. (Antipatrón catch-log-throw).

Hacer uso de la propiedad de excepción causante o interna cuando capturemos y relancemos la excepción. En Java es el método getCause(), en .NET la propiedad InnerException.

Implementar el método toString() de todas las clases de negocio o POJOs para facilitar su traceado.

Hay que tener en cuenta las diferencias y zonas horarias a la hora de trabajar con logs de varias máquinas o componentes.

El logging no puede tener efectos laterales, no puede modificar el estado de ningún parámetro, variable o procedimiento. Solo muestra información. Debe ser ligero, el propio logging no puede requerir de procesamientos largos o costosos.

Las llamadas a métodos, componentes y componentes distribuidos externos, deberían registrarse tras la llamada incluyendo los parámetros de entrada y la respuesta, así como clase/componente y método, a nivel de DEBUG. Y a nivel de ERROR y FATAL cuando ocurra un error en la llamada (si fuese una excepción se debe tracear parámetros de entrada y excepción)

En Java tenemos varias API's o librerías para llevar a cabo el logging de nuestra aplicación, siendo las mas comunes:

• Log4j2 antes Log4j
• Loogback
• JUL (Java Util Logging)

Tenemos dos fachadas las cuales permitirán que nuestra aplicación funcione con cualquiera las tres API's mencionadas, estas fachadas son:

• Commons Logging
• SLF4J

Continua con una guía practica para la API Log4j  Log4j ofrece control sobre el logging

Deja de ser un hombre débil

Recuerdo que ella me dijo -"Ya no quiero estar contigo, quiero a un hombre a mi lado, no a un niño, no quiero un hombre débil como tu, quiero con carácter, un hombre de mundo, un hombre ambicioso,. Un hombre que tenga objetivos en la vida y que sepa lo que quiere". Yo tenía en ese entonces unos 19 años, y no comprendí lo de ser un hombre débil.

La vida se encargó de hacerme fuerte a golpes, me hubiese gustado haber tenido una charla con mi padre y que me dijese lo peligroso y  hostil que es el mundo. Un mundo en el que si no tienes carácter los demás te pisotearan.

No es mi culpa no haber forjado mi carácter, la ausencia de mi padre y el entorno donde crecí me convirtieron en un hombre débil, pero tenemos el poder de cambiar, de crecer y desarrollarnos, de forjar nuestro carácter para ser un hombre fuerte.

En esta entrada voy a compartir una lista de principios y hábitos que he desarrollado para dejar de ser ese hombre débil y forjar mi carácter.

Primero estás TU, segundo tu Familia luego el resto

No tengas miedo a decir lo que piensas

Si no estás cómodo con tu situación, cámbiala.

Aprende a decir NO con criterio

Practica artes marciales

Levanta pesas, cuida tu salud, haz deporte

Desarrolla tu filosofía de Vida

Ten metas y objetivos en tu Vida

Desarrolla tu auto critica sana

No te quejes, mejor actúa

Se agradecido de la vida, de lo que tienes

Aplica la Persistencia, Disciplina, Orden y Estructura en tu Vida

Consejos para ser un mejor programador

En mi trayecto como desarrollador de software he ido mejorando, aprendiendo de mis errores, aprendiendo de otros programadores. Cuando vivo una experiencia que me marca, lo anoto para después repasarlo. Siempre con el espíritu de crecer profesionalmente.

Tengo tantas ideas, principios y hábitos, algunos en mi mente, otros escrito en alguna hoja guardada entre las paginas de algún libro. En esta entrada pretendo ir organizando estas ideas para compartirlas, recibir retro alimentación o consejos adicionales.

Esta entrada complementa a la entrada ¿Como ser el mejor programador?

1.- Aprende a leer la documentación

Si eres programador del lenguaje Java, generalmente las clases de las APIs más usadas están documentadas en Javadoc, Javadoc es un estandard de Java para documentar. Lo mas relevante de Javadoc es comprender como usar una clase. Cada método tiene una breve descripción, los parámetros que recibe, el objeto que retorna, las posibles excepciones y las reglas más relevantes de uso. Muchas veces usamos una clase sin leer su documentación, violamos algunas reglas de uso y esto genera errores en tiempo de ejecución. Corregir los errores en tiempo de ejecución es muy costoso por eso es mejor invertir un poco de tiempo en leer la documentación de las clases.

2.- Conoce tu herramienta

¿Netbeans o Eclipse? No importa cual sea tu IDE favorito, invierte tiempo en conocer tu IDE. Siempre pregúntate ¿Como puedo optimizar esta tarea?

3.- TDD y depuración de código

Aplica TDD cuando consideres necesario y depura tu código fuente. Aplicar TDD me permite recibir retroalimentación de como trabajaría mi clase en tiempo de ejecución, que tan fácil y cómodo será su uso o integración y validar que la clase o clases cumplan con la funcionalidad esperada. Mas sobre TDD en esta entrada Usar TDD con Criterio

4.- Enfoque, que tu mente esté en el presente.

Es común programar en automático, muchas veces no estamos enfocados al 100% en el código que estamos escribiendo. ¿Te imaginas lo que pasaría si un cirujano está distraído mientras realiza una operación? Bueno... pues hay similitud con nuestro trabajo, una condición o validación errónea puede llevar a que nuestro sistema tenga comportamientos no esperados. (complementar con el punto anterior)

5.- Prudencia y Comunicación

Cuando modificamos código existente debemos tener mucho cuidado con los cambios que introducimos, si dudamos de los cambios que deseamos aplicar es mejor consultar con el resto del equipo. No hay que guardarnos nada, conocer la opinión de otros nos ayuda a corregir o justificar nuestras decisiones.

6.- Buscar la solución más simple

Resolver un problema es un arte, es muy buena practica tener más de una solución y buscar la solución más simple. No porque sea la más simple será la menos eficiente, de hecho, encontrar la solución más simple requiere ingenio, destreza y esfuerzo mental. El tiempo usado en encontrar la solución más simple es una inversión, la solución será menos propensa a errores, fácil de modificar y fácil de depurar.

7.- Pedir Ayuda y saber pedir ayuda
Trabajamos en equipo, tenemos compañeros, apoyémonos en ellos. Muchas veces no preguntamos por no quedar como tontos y esto lo único que hace es afectar nuestra paz mental. Nadie debería juzgarte o criticarte por preguntar. Sin embargo, debes saber pedir ayuda, ordena tus ideas, usa herramientas de comunicación para expresar tus dudas, herramientas como diagramas, dibujos, tablas etc,. Debes ayudar a que los demás comprendan tus dudas para que así puedan ayudarte. Tampoco es que los demás sean más inteligentes o quizás... muchas veces es porque tienen más experiencia, llevan mas tiempo en este arte del desarrollo de software y tu debes aprovechar estos conocimientos.

8.- No Re Inventes la Rueda, Re usa código

Está bien que para practicar programes cosas 

¿Como ser un mejor Líder?

Nunca fue mi intención asumir el rol de Líder Técnico, las responsabilidades de este rol son complejas y a mi me gusta la calma, la paz. Si he de enfrentar la adversidad quiero hacerlo solo, porque me conozco, se como motivarme, se como llevarme al limite, de hecho he sido mi propio líder.

Como cualquier otro apasionado por el Desarrollo de Software, tengo una visión, y quizás mi mayor anhelo es poder transmitir está visión al resto de mi equipo.

He aprendido que un líder se hace a través de sus acciones, de hechos y no de palabras, para mi en estos meses ha sido fundamental reconocer cuales son esas acciones, para redoblar esfuerzos, mejorar mi capacidad y motivar a mi equipo de trabajo.

Como siempre, escribo estás lineas, primeramente para organizar mis ideas, y para cumplir con una promesa que me hice años atrás: la de compartir mis experiencias con la nueva generación.

Mantener motivados a tu equipo de trabajo es un gran desafío, hacer que se pongan la camiseta de la empresa, que sientan cariño por la empresa y por el producto. Pero para lograrlo es necesario primeramente, ser un líder ejemplar, predicar con el ejemplo. En momentos de crisis la empresa tiene que ser guiada de forma correcta para mantener la esperanza y confianza en que tarde o temprano se logrará salir de este bache.

Un líder tiene que ser un referente para el resto del equipo, dirigir, motivar y exigir de la mejor manera para lograr un ambiente grato y alcanzar los objetivos propuestos.

Sin embargo, ocupar este puesto no es fácil, no ha sido fácil para mi, porque ante la adversidad la mayoría o todos se darán por vencidos, dirán que es muy difícil e incluso imposible y se quedarán de brazos cruzados, pero tu no, tu tienes que resolver, tu tienes que buscar la solución, tienes que confiar en ti, en tus capacidades y habilidades. Algunos días tendrás que quedarte hasta tarde, porque los problemas se tienen que solucionar, para el líder no existe la palabra imposible, ser líder requiere un enorme compromiso.

El bienestar laboral y emocional de tu equipo es una gran responsabilidad, debes cuidar que tu equipo te vea como un aliado que confíe en ti  y no como el malo del cuento, pero no debes ser tan suave como para que pasen encima de ti. Debes saber cuando ejercer presión, pero también conocer el limite de la presión que puedes ejercer.

En estos meses he aprendido mucho y puedo escribir los siguientes consejos, los escribo con el fin de no olvidarlos y echar mano de ellos cuando los necesite.

Poner el Ejemplo

El buen juez por su casa empieza, un buen líder es aquel que pone el ejemplo, un líder se compromete y cumple con sus compromisos en tiempo y forma. No se puede esperar que tu equipo sea comprometido si tu no lo eres. No se puede esperar que tu equipo aplique las buenas practicas y/o metodologías si tu no lo haces. No se puede esperar que tu equipo aplique Testing Unitario si tu no lo haces. No se puede esperar que tu equipo use las herramientas si tu las ignoras. Un primer paso es poner el ejemplo de estas y otras actividades.

El equipo tiene verte fuerte y seguro de ti mismo en aquellos momentos de adversidades, tienen que ver como tu estás seguro de que encontrarás la solución, que no hay imposibles para ti. Tienen que verte calmado y relajado aun en esas adversidades. ¿Como se consigue esto? Con experiencia y conocimientos.

Establecer Limites

Un líder tiene que reunirse periódicamente con su equipo para dejar claras las responsabilidades de cada uno y al mismo tiempo para conocer las capacidades de su equipo. Y aquí hay que ser bien detallado y preciso. ¿Cuantas horas le toma hacer cierta actividad?, ¿Que tan complejo era la tarea? ¿Que tecnologías se involucraron? ¿Que metodologías? ¿Qué se obtuvo como resultado?, etc,.  Hay que determinar de forma objetiva y verdadera la capacidad que tiene cada uno para poder alcanzar sus metas. Con esta información podrás organizarte mejor y asumir los compromisos en tiempo y forma.

Delegar Tareas

Desde luego, mas de una ocasión he pensado, mejor lo hago yo, porque me gusta que las cosas se hagan bien o un poco mejor que bien y en un dos por tres. Lo cierto es que el tiempo es escaso para nosotros los lideres. Delegar es una de las tareas más importantes, delegar implica confiar en tu equipo, pero la confianza se tiene que ir ganando, de a poco, y tu tienes que delegar paso a paso, primero tareas simples, para que tu equipo vaya cogiendo confianza y experiencia en ellos mismos, y así ir incrementando gradualmente la complejidad. Eso es lo ideal, pero sabemos que en la practica no todos es lineal, a veces hay calma y a veces hay tormentas.

Un líder que no delega no trabaja en equipo, trabajar en equipo es esencial para lograr el bienestar emocional y laboral del equipo, porque haces que se sientan parte de "algo", que sientan que también están contribuyendo en "algo".

Se un mentor
Tienes que ser alguien cercano a tu equipo, ayudarles a crecer, conocer sus fortalezas y debilidades. Poder detectar las fortalezas y debilidades de tu equipo requiere que desarrolles tu capacidad de observación. Sin embargo, si tu has crecido (profesionalmente) desde muy abajo, eso es muy bueno porque te permitirá conectar de una forma más real y sincera, tu pasaste por ahí y sabes lo que tu equipo piensa y siente.

Pida Ayuda

El desarrollo de software es complejo, no podemos abarcar todas las áreas, "nadie nace sabiendo todo " -decía mi abuela. Pedir ayuda no es malo, mostrar un poco de vulnerabilidad es bueno, así tu equipo sabrá que eres tan humano como ellos, que tienes debilidades técnicas pero que las compensas pidiendo ayuda. En ocasiones nos aturdimos y no logramos ver todo el panorama, siempre ayuda pedir la visión y/o percepción de otra persona, porque puede que ella vea ese pequeño detalle que tu estás pasando por alto.

También es bueno pedir ayuda a tu equipo cuando por falta de tiempo tu no puedes cumplir con tus compromisos, eso ayuda a fortalecer la confianza.

Seguiré escribiendo mas sobre estos temas a medida que vaya aprendiendo.

Hello World

Tengo que admitirlo, mantener al día este blog supondrá un esfuerzo adicional para mi. Es complicado escribir, aunque no lo creas, ademas tengo un chingo de cosas por hacer. Aun así, poder expresar lo que siento es algo muy importante para mi.

Espero poder usar este espacio para compartir con ustedes mis pensamientos y conocimiento, más importante aun, espero recibir retro alimentación. Así que siéntete libre de comentar todos mis post.

I have to recognize keeping a blog updated will be a very important effort to me. It's complicated to write for me and I have a ton of things on my to do list. However, I thing spreading the word is an important  task for me.

I hope I can use this space to share my thoughts with you and, most importantly, be able to get your beedback firsthand. Please, feel free to comment my posts.

Anyway, here we go. Let's see what happens.