4 Descripción de la solución propuesta 15
4.4 Monitorización reactiva 51
En la monitorización reactiva, se diseña una o más acciones que deben ser ejecutadas en caso de producirse cierto tipo de eventos o fallos. Las notificaciones mediante la monitorización reactiva se realizan mediante el envío de mensajes de Syslog y Traps SNMP a ZenOSS. 4.4.1 Diseño de la monitorización de logs
La monitorización de patrones en ficheros de log se realiza mediante la instalación en los servidores de un agente de monitorización de logs (LogWatcher). Este agente tiene la configuración en local de los logs a monitorizar y de los patrones de mensaje a buscar. Si alguno de los patrones definidos es encontrado en los ficheros monitorizados el agente generará un evento en formato syslog a ZenOSS. En la ilustración 18 se muestra el diseño de este tipo de monitorización.
Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento
52
Ilustración 18: Diseño para la monitorización de Logs mediante logWatcher
El agente logWatcher está basado en la herramienta opensource SEC (Simple Event Correlator). Es una herramienta desarrollada en Perl que permite chequear ocurrencias de patrones de texto en ficheros de log en tiempo real y ejecutar comandos o código embebido cuando suceden estas ocurrencias.
Los patrones configurados se han definido en base a expresiones regulares. Cada patrón corresponde con una regla y tiene asignada una acción. En este caso se han definido tantas reglas como patrones de logs generen alarma y todas tienen asignadas la misma acción: el envío de un mensaje de syslog a ZenOSS. Para el envío de los mensajes de syslog se utilizan las propias librerías que proporciona Perl.
El software que se requiere es el propio SEC. El SEC tiene como requisito que el servidor disponga de una versión de Perl 5.8. Si la versión es anterior sería necesario instalar los siguientes módulos Perl: Getopt, POSIX, Fcntl, Socket, IO::Handle, y NetSys::Syslog.
Los mensajes de syslog que se envíen a ZenOSS desde los sistemas a monitorizar llevarán un formato muy concreto que incluye los siguientes campos:
App_name: el LogWatcher permite identificar el EventClass al que se asignan los eventos de syslog.
Facility: syslog
Priority: según la criticidad del evento puede ser warning (WARNING), critical (CRITICAL) o notice (OK).
El texto del mensaje es la clave para poder realizar el mapping con los Event Class en ZenOSS. El formato del texto definido en nuestro caso es el siguiente:
##AgrupacionLogica##Fichero_log## Mensaje de Syslog
Las palabras clave se localizan entre almohadillas dobles (##). La primera palabra clave hace referencia a la agrupación lógica de los patrones, es decir, un nombre lógico que se puede
de Log del que se ha extraído la información. Por ejemplo, para un mensaje de log desde el aplicativo brix el formato de syslog sería:
##BRIX##bxworx.log##mensaje
El uso de este formato permite facilitar la administración de nuevos patrones de log tal y como se explica a continuación en la integración con la solución.
4.4.2 Integración del LogWatcher con ZenOSS
Los eventos en ZenOSS se integran a través de mapeos con la Event Class. Como ya se ha indicado anteriormente, para la integración de los eventos de log se ha creado una Event Class principal denominada Logs/, y, según los patrones de monitorización que se identifiquen en la plantilla, se incluirán nuevas clases según las funcionalidades afectadas (ver ilustración 19).
Ilustración 19: Estructura de Event Classes para tratamientos de Logs
La integración de los logs se realiza en dos etapas: en la primera se identifica el eventClassKey (logWatcher) para asignar los eventos a la clase Logs/. En una segunda fase se busca las palabras clave que puedan identificar las diferentes subclases (AgrupacionLogica).
El primer mapeo se realiza de forma automática a través del campo App_name del mensaje de syslog, ya que ZenOSS, por defecto, asigna al eventClassKey el valor del App_name. Las subclases se definen a partir de los patrones de log a tratar. En función del tipo de patrón de log se asignan las distintas políticas de eventos.
Todos los logs tienen asignado el mismo eventClassKey y para especializarlos en una subclase concreta deben cumplir un patrón concreto en su mensaje. Este diseño evita tener que estar modificando los ficheros internos de ZenOSS.
La especialización de las subclases se realiza desde la propia interfaz web de ZenOSS, añadiendo nuevos mappings con expresiones regulares de este tipo:
*:##AgrupacionLogica##.*
Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento
54
Ilustración 20:Lógica de asignación de Event Class
Además de la agrupación de los eventos en las distintas EventClasses y la asignación de propiedades del evento, ZenOSS hace un mapeo interno entre la priority de los mensajes de syslog y las severidades de ZenOSS (Severity). El mapeo que se va a establecer es el que se muestra en la tabla 47.
Tabla 47: El mapeo de severidad entre LogWatcher y ZenOSS
Syslog Priority ZenOSS Severity
critical (1) CRITICAL (5)
warning (4) WARNING (3)
notice (5) CLEAR (0)
La de duplicación de los eventos se basa en el concepto de ‘fingerprint’; en ZenOSS llamado dedupid. ZenOSS genera los fingerprint en base a los siguientes campos, delimitados por el carácter ‘|’: device | component | eventClass | eventKey | severity | summary
El campo summary solo se incluye en el fingerprint si el campo eventKey está en blanco. Cuando un evento se registra se construye el fingerprint, y si existe otro evento que ya tenga ese mismo fingerprint, se realizará la de duplicación. Esto implica que no se realiza de duplicación entre eventos con distintas severidades, por lo que se realizarán las transformaciones necesarias para implementar esta de duplicación.
La cancelación de los Eventos se realiza de manera automática cuando llega un evento con severidad CLEAR (0).