sábado, 26 de septiembre de 2015

"IMPORTANCIA DE 'LOG' EN LOS SERVICIOS"


El manejo de LOGs a nivel de servicios es muy importante, ya que en el refleja la traza de cómo el flujo de los mensajes se va transmitiendo entre servicio y servicio. Este manejo de LOGs debe ser realizado de la mano con un mecanismo estandarizado de auditoría en donde el 'idTransaccion' refleje la relación que existe de las trazas generadas en los servidores distribuidos, a nivel de servicios. Esto permitirá a los administradores de servidores y/o operadores de estos poder identificar, ante alguna caída de un servicio embebido dentro del servicio compuesto, la causa exacta del problema.

En lo relacionado a ¿Que debemos imprimir en los LOGs?, esto es muy importante ya que recordemos que los LOGs no deben ser gigantes, ya que estos se almacenan en disco. Debido a ello, se debe estandarizar que es lo que debemos imprimir en ellos. Una recomendación para esta tarea de manejo de LOG es la siguiente:

  • Cada línea de LOG generada, debe indicar: "Fecha, Hora y idTransaccion", muy a parte del mensaje que se desea imprimir.
  • Se debe imprimir todo mensaje REQUEST y RESPONSE de cada servicio compuesto.
  • Se debe de imprimir el tiempo de duración en segundos y/o milisegundos, al final de cada servicio compuesto.
  • Se debe imprimir todo mensaje REQUEST y RESPONSE de cada servicio ‘proxy client’ que se consume en el flujo.
  • Se debe de imprimir datos importantes de los servicios o BD como: "URL endPoint, nombre PACKAGE/OWNER/PROCEDURE, nombre JNDI, etc"
  • No se deben imprimir datos como passwords (si lo hacen deben figurar como encriptados).
  • No se deben imprimir un llamado a LOG dentro de un bucle (dentro de una lógica), que podría generar, en algún posible escenario, infinita generación de LOG.   

Estas son algunas de las recomendaciones para la aplicación de LOGs respectivamente. Por otro lado, es muy importante que los servicios no manejen 'System.out' embebidos (si es que están desarrollado en JAVA), ya que estos escriben directamente en la consola del server. Debido a este problema, en algunos proyectos SOA se acostumbra destinar un servicio de tipo 'Util' a este trabajo de Loggin (siguiendo la orientación de servicios), para que ante cada necesidad de impresión de LOG se invoque a dicho servicio. Desde mi punto de vista, por un lado está bien la lógica según la orientación respectiva, pero analizando este servicio por cada Request y Response que se realice ¿cuantas veces será invocado?, debido a ello en otros proyectos para este tipo de tareas se elimina el manejo de este servicio como utilitario y se reemplaza por el manejo de un ‘Framework de loggin’, Debido a ello en la actualidad hay varios opciones entre las que resalta la 'LO4J', que permite la realización de este labor de manera rápida, configurable por niveles (INFO, DEBUG, ERROR, etc) y fácilmente integrable a servidores de aplicaciones como Weblogic, WAS, etc, de manera externa a la aplicación.

Esto quiere decir que los administradores de servidores, mediante su manejo pueden definir una ruta absoluta fija en los servidores, destinada a la generación de archivos logs de todas las aplicaciones corriendo en los servidores, para que antes cualquier necesidad de búsqueda en dicha ruta encontraran el archivo "NombreServicio.log" por fecha automáticamente ordenado.

No hay comentarios: