ZenOSS Core basa la monitorización en un modelado de monitorización configurable y adaptable a las necesidades específicas del entorno monitorizado.
En la ilustración 8 vemos el diagrama global de la monitorización tanto activa como reactiva de un dispositivo:
Ilustración 8: Modelado Global de la Monitorización
Los principales aspectos de este modelado se describen en los siguientes apartados.
4.2.1 El modelado de los elementos monitorizados
Los elementos monitorizados en ZenOSS se modelan utilizando un paradigma orientado a objetos. Tanto los dispositivos a monitorizar como los componentes que se monitorizan dentro del dispositivo (por ejemplo: Interfaces, Procesos, FileSystems, etc..), ver ilustración 9.
Ilustración 9: Concepto de dispositivo
Como parte del modelado, ZenOSS asigna atributos a nivel de Device (Dispositivo) que permiten hacer sub-agrupaciones de cara a la posterior administración. Estos atributos son propiedades que se establecen cuando se da de alta un dispositivo:
Systems: Permite indicar el tipo de sistema al que pertenece un dispositivo.
Groups: Permite establecer agrupaciones en las que incluir un dispositivo.
Location: Permite seleccionar una ubicación física del equipo entre todas aquellas registradas en el sistema.
Estas propiedades no afectan a la monitorización de los dispositivos, únicamente permite organizarlos para una mejor administración.
A cada dispositivo monitorizado en el sistema se le asigna una clase (Device Class) que define las plantillas de monitorización (monitoring templates) a utilizar con esa clase y los plugins de descubrimiento (modeler plugins) que permiten descubrir e inventariar de manera automática los componentes monitorizados dentro de cada dispositivo (ver ilustración 10).
Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento
28
4.2.2 Herencia en la definición de los tipos de dispositivos
Las diferentes Device Classes se agrupan siguiendo una estructura jerárquica que permite definir grupos y subgrupos de dispositivos (ver ilustración 11). Un grupo de dispositivos hijo hereda todos los plugins de modelado y plantillas de monitorización de su grupo padre. El listado de plugins de modelado y las plantillas de monitorización se pueden sobrescribir en las Device Classes hijas. El sistema permite también sobrescribir el listado de plugins de modelado y las plantillas de monitorización a nivel de dispositivo.
Ilustración 11: Lógica de agrupación de dispositivos
ZenOSS tiene definida por defecto una jerarquía de Device Classes donde el primer nivel corresponde al tipo de dispositivo (red, servidores, http, etc.) y luego se especializa por fabricante. En el caso de los servidores, se va a especializar por sistema operativo (Linux, Solaris, Windows, etc.) y a continuación por protocolo de comunicación/acceso a cada equipo (ssh, snmp, etc..).
4.2.3 Definición de plugins de descubrimiento
Cada Device Class tiene asociado un conjunto de modeler plugins, que permiten inventariar mediante el descubrimiento de los diferentes componentes del dispositivo. Este descubrimiento se puede realizar de manera automática utilizando los protocolos de acceso a los equipos (SNMP y SSH fundamentalmente).
ZenOSS permite la organización de los diferentes componentes (Networks, procesos, IP Services, etc.) de manera independiente a los DeviceClasses. Para alguno de los componentes (procesos, servicios IP, etc.) la herramienta permite establecer patrones de descubrimiento, de tal forma que, si el patrón no se cumple, no se va a añadir a los dispositivos durante el modelado. 4.2.4 Definición de plantillas de monitorización
Las plantillas de monitorización (monitoring templates), mostradas en la ilustración 12, definen la lógica de la monitorización activa es decir en las plantillas de monitorización se definen los chequeos activos a los equipos monitorizados, esos chequeos se pueden realizar mediante la ejecución automática de comandos SSH, peticiones SNMP, chequeo de superación de umbral, eventos a generar, etc.
Tanto las Device Class como cada una de las clases asociadas a los componentes (Procesos, File Systems, Interfaces, etc.) poseen unas plantillas de monitorización definidas por defecto.
Data Source es una consulta concreta que se realiza al equipo que se monitoriza, obteniendo de esta forma uno o varios datos concretos denominados DataPoints. Estos DataPoints son los que se utilizan para diseñar las gráficas de rendimiento y establecer los umbrales de generación de alarmas.
Ilustración 12: Estructura de una plantilla de monitorización (Monitoring Template)
4.2.5 Definición de Event Class para el tratamiento de alarmas
ZenOSS modela las alarmas/eventos generados de manera independiente a las Device Class. Este modelado se basa en la definición de Event Classes. Las Event Classes se utilizan para clasificar los eventos por tipos y poder configurar tratamientos diferenciados en función del tipo. Estos tratamientos, denominados transformaciones, se asocian a una Event Class y definen el procesamiento que se realiza con todos los eventos de ese tipo. Algunos ejemplos de las transformaciones más habituales son:
Modificación de campos del evento o del dispositivo
Generación de nuevos campos de usuario en el evento
Modificación del ciclo de vida del evento: descarte o archivado directo
El modelado de eventos se utiliza para categorizar y tratar tanto los eventos resultantes de la monitorización activa (chequeo de umbrales) como los eventos que se reciben mediante monitorización reactiva (traps SNMP o mensajes de Syslog).
En el caso de la monitorización activa, puesto que parte de la definición de los umbrales en un plugin de monitorización, se debe indicar a qué Event Class se va a asignar la alarma que se generará para los diferentes dispositivos que tengan asociada la plantilla.
En el caso de la monitorización reactiva, la asignación de la Event Class se realiza en base de tres parámetros de chequeo, en el siguiente orden:
La propiedad EventClassKey del evento (obligatorio)
Diseño y despliegue de un sistema de monitorización de red para gestión de fallos y rendimiento
30
Estos tres parámetros definen un mapping, de tal forma que si el evento cumple el mapping establecido se asignará a la Event Class a la que está asignado dicho mapping. Si no se cumplen las condiciones, se asignará a la Event Class Unknown.
El campo eventClassKey es el único que se debe cumplir siempre y que dependerá del tipo de evento (syslog o SNMP trap). El campo Rule permite verificar que las propiedades de un evento cumplen ciertas condiciones. El campo Regex permite verificar que el summary del evento tiene un patrón concreto.
En los mensajes de syslog la EventClasKey se identifica en el propio mensaje, estableciendo patrones que el proceso zensyslog busca con cada mensaje recibido. En caso de que no se cumpla ningún patrón en zensyslog, identifica el eventClassKey con el valor del APP_Name del mensaje de syslog.
Para los traps SNMP el EventClassKey se va a asignar al nombre del OID del trap. Por ejemplo:
Para un mensaje syslog del tipo “EQUIPO1 Error Login en aplicativo X” un posible patrón seria: EQUIPO1: Error <?EventClassKey> .* aplicativo .*
La EventClassKey seria” Login”.
Para un trap cuyo OID sea LinkUP, el EventClassKey será “LinkUP”.