En un post anterior comenté sobre lo que es la: Importancia de los LOGs en los Servicios, en esta oportunidad hablaré y mostraré sobre algo importante que está de la mano con este tema, en si es posterior a dicho tema, este es la 'Centralización de Logs'.
La 'Centralización de Logs' como su nombre lo dice es muy importante, ya que si analizamos en un ambiente Prod, existen una gran cantidad de archivos Log que a diario se van generando y creciendo con los procesamientos de los sistemas. Para ello anteriormente también se recomendó una serie de consideraciones a tener en cuenta, sobre lo que debería contener cada Log. Adicionalmente a ello, es recomendable, pensando en proyectos relacionados de SOA, definir por servidor una Ruta Absoluta Fija (por ejemplo: /home/tdp/soa/logs), que contendrá en su interior los directorios con los nombres de los proyectos trabajados (servicios) y dentro de estos directorios se generen Logs de cada servicio. Así mismo, definir a un Operador/Administrador de servidores que sea el encargado de la revisión y mantenimiento de los Logs (ya que estos, dependiendo de los mecanismos que se utilicen para su generación, van creciendo por día considerablemente), debido a ellos dichos Operadores deben velar por el bienestar de los servidores, eliminando Logs de fechas anteriores (por ejemplo cuatro semanas de antigüedad, dependiendo del negocio) a nivel del Servidor y de los Nodos que existan (Cluster), por medio de Script por ejemplo. Esta es una tarea que si no se realiza ordenadamente, definiendo rutas absolutas fijas donde ir a buscar directamente, ante una falla del servicio, puede llevar al caos el identificar problemas existentes.
Justamente, pensando en aligerar un poco esta tarea de identificación de fallas en los servicios, nace el concepto de 'Centralización de Logs', esto consiste en que los sistemas y/o aplicaciones generadoras de Logs, por medio de un mecanismo, lancen sus Logs a un Servidor Central de Logs, estos servidores (Virtuales/Físicos), deberá tener la capacidad de recepcionar los mensajes de Logs enviados y por medio de una consola de administración, el Operador/Administrador será alertado vía emails, así como poder visualizar listado en pantalla los problemas, etc.
En esta oportunidad mostraré una solución para realizar dicha tarea de: 'Centralización de Logs', por medio de 'Log4j Syslog' y 'Kiwi Syslog Server'. Ahora explicando un poco sobre: 'Kiwi Syslog Server', es una solución de pago que trabaja como servidor syslog, brindando características de administración de archivos de registro, fácil de usar para los Operadores/Administradores y los equipos de red, de instalar y configurar, este trabaja con alertas, SNMP, eventos, etc, sobre las plataformas Windows, Linux. Para más detalles del producto visualizar el Video.
I. SYSLOG SERVER (Kiwi):
Lo bueno para el tema de pruebas es que este Syslog Server, maneja su versión Free, que se puede descargar de aquí.
Un vez descargado se debe de instalar el software que trabajará fijo con Evento permanente instalado en la máquina y que escuchará los mensajes Syslog: SolarWinds_Event_LogForwarder_Setup, luego se debe instalar el Syslog Server como tal: Kiwi_Syslog_Server_9.5.0.Freeware.setup.
Terminada la instalación así se visualizará el: Kiwi Syslog Server:
II. LOG4J (Syslog):
Por medio de Log4j y su integración con Servidores de Aplicaciones como Weblogic ó WAS, uno puede configurar la autogeneración de Logs, en Rutas Absolutas Fijas por Servicio (Justo la primera parte que anteriormente ya se había mencionado y recomendado).
He creado un proyecto JAVA para simular el manejo, configuración y envío de los Logs (mensajes) al Servidor Central por medio de Syslog.
Todo debende de manejar una buena configuración de los Appender de Log4j, mi caso tengo configurado dos Appender, para que tabajen de la mano:
- org.apache.log4j.net.SyslogAppender: Para la comunicación con el Servidor Central Syslog.
- org.apache.log4j.DailyRollingFileAppender: Para la generación de los Log en las rutas absolutas fijas definidas.
III. TESTING:
El dummy preparado inicia desde Eclipse que mandará el Log a generarse, tanto en la Ruta Absoluta Fija definida, como en el Servidor Central Syslog:
El mensaje será registrado en el archivo Log, del directorio fijo definido.
Así mismo, se registrará el mensaje en el Servidor Central Syslog, tal como se muestra en imagen.
Esto ayudará el Operador/Administrador, a que tenga más visión de los problemas existentes a nivel de los servicios y aplicaciones desplegadas en el Server.
Una segunda prueba, ya simulando un escenario real a nivel de servicios sería la siguiente:
Se debe configurar de manera similar el archivo log4j.xml que se tiene integrado con Weblogic Server, definiendo el Appender adicional que se deberá manejar para la comunicacion con el Servidor Centra Syslog, posteriormente reiniciamos (Asuminemos que el servicio para pruebas, ya está desplegado).
Desde SOAPUI ejecutamos la prueba del servicio respectivo y configurado:
Este lanzamiento registrará, la traza real del servicio en el archivo Log del servicio, generado en la Ruta Fija absoluta.
Así mismo, el mismo mensaje se registrará en el Servidor Central Syslog (Kiwi) de Logs.
Finalmente, solo que me queda mencionar que se ha tratado de mostrar uno de las tantas maneras y mecanismos que existen para la 'Centralizacion de Log', un poco más orientado a entornos SOA.
Para los interesados pueden descargar el Dummy del proyecto Log4jSyslog desde aquí: http://www.mediafire.com/download/ysjeyglklk8sa89/LoggerSyslog.zip
No hay comentarios:
Publicar un comentario