1.1 AUDIENCIA CONTENIDO ITEMS DE MONITOREO ACCIONES MONITOREO Y ALARMA...7. 'HVFULSFLyQ.

Transcripción

1 ,1)250(),1$/ 352<(&72'(*5$'2 +(55$0,(17$'(021,725(2< $/(57$&21),*85$%/(+0$& *XtDSDUDHO'HVDUUROODGRU $QD&DUROLQD3DVFXDO0DUFRV5RGUtJXH] 7XWRUHV$ULHO6DELJXHUR<DZHODN+pFWRU&DQFHOD,QVWLWXWRGH&RPSXWDFLyQ )DFXOWDGGH,QJHQLHUtD 8QLYHUVLGDGGHOD5HS~EOLFD2ULHQWDOGHO8UXJXD\ $EULO

2 ,1',&( 2%-(7, AUDIENCIA CONTENIDO...2 &21&(3726%È6,&26 '(7$//(6'(,03/(0(17$&,Ï1 3.1 ITEMS DE MONITOREO...3 2WUDVFRQVLGHUDFLRQHV 3.2 ACCIONES...5 2WUDVFRQVLGHUDFLRQHV 3.3 MONITOREO Y ALARMA...7 5()(5(1&,$6 1

3 2%-(7,926 Este documento presenta una guía para desarrolladores del monitor de alertas configurable (HMAC). Pretende ser un material de apoyo para aquellas personas que quieran extender la herramienta. Se describen detalles de implementación y diseño necesarios para la incorporación de módulos para monitorear nuevos recursos, generar nuevas monitores y alarmas y ejecutar nuevas acciones. $XGLHQFLD Está dirigido principalmente a aquellas personas interesadas en extender la herramienta, pero podría ser de interés para quienes quieran introducirse un poco más en detalles de implementación. Dado el contenido del documento se asume que el lector tiene formación en orientación a objetos y nociones básicas de programación en java. También debería tener conocimientos de JMX y de la arquitectura de la herramienta HMAC. Es recomendable utilizar como material de apoyo el javadoc generado [Javadoc], el capítulo 3.4 Especificaciones de Diseño y Arquitectura y el JMX del documento Informe final [Informe Final]. &RQWHQLGR En el segundo capítulo se definirán conceptos básicos a los que se hará referencia en las siguientes secciones. En el tercer capítulo se describen los distintos módulos con posibilidades de extender. Se detallarán las características y condiciones que deben cumplir para efectivamente ser módulos del tipo deseado, y también pautas para integrarlos y utilizarlos en sistema. &21&(3726%È6,&26 ËWHPGHPRQLWRUHRobjeto que modela el recurso a monitorear. Mantiene información del recurso que permite identificarlo, provee métodos (atributos) a través de los cuales se obtienen métricas de propiedades que interesa monitorear, y otros métodos (operaciones) que permitan operar sobre él teniendo más control. $ODUPDcondición que permite representar el estado no deseado de un ítem. Mediante la evaluación de la condición de alarma en el contexto adecuado se puede determina el estado del ítem. Cuando se cumple la condición se dice que se genera una alarma. 0RQLWRU Objeto que encapsula la política de scheduling. A través de él se evalúan las condiciones alarmas y se notifica en caso de generarse una alarma. Por este motivo los monitores y las alarmas son conceptos que están muy ligados. $FFLyQ Objeto que encapsula alguna operación que permite reaccionar ante la notificación de una condición de alarma. Ejemplos de acción son envío de mail, llamada telefónica, registro en archivos, etc. 2

4 '(7$//(6'(,03/(0(17$&,Ï1 En las siguientes secciones se detallarán las pautas para desarrollar nuevos módulos de ítems de monitoreo, monitores y acciones, con detalles de las condiciones que deben cumplir, así como guías de cómo integrarlos al sistema.,whpvghprqlwruhr En el entorno de JMX los recursos se modelan como MBeans. La especificación de JMX define a un MBean como una clase de Java que cumple con ciertas condiciones según el tipo de MBean. En esta arquitectura los ítems de monitoreo se modelarán como Standars MBeans los cuales deben cumplir: tener uno o varios constructores, implementar su propia interfase, no implementar la interfase NotificationBroadCaster. Es sólo a través de la interfase que el recurso es administrado, y no directamente sino a través del MBeanServer en donde se registre. El MBeanServer expone a los sistemas de administración la interfase del MBean a través de su propia interfase proveyendo un conjunto de métodos para ésto. Para que una clase java sea una ítem debe cumplir, además de las condiciones de los Standard MBeans, con lo siguiente: residir en el paquete de java monitor.items. extender la clase Item (clase abstracta), e implementar el método getinfo() el cual provee una descripción del ítem. implementar su propia interfase cuyo nombre corresponde al de la clase java seguido de 0%HDQ. su interfase debe implementar la interfase ItemMBean. toda excepción que se dispare desde la clase se debe encapsular en un objeto de clase ItemException. El siguiente modelo intenta resumir las relaciones entre las clases e interfases incluidas en el paquete monitor.items. 3

5 La interfase se compondrá de atributos y operaciones. Los atributos proveen los métodos para obtener medidas y/o modificar las propiedades que interesa controlar de los recursos. Las operaciones son métodos para administrar los recursos. Para distinguir entre atributos y operaciones JMX sigue ciertas convenciones de nombres. Un atributo es identificado por el siguiente patrón: public AttrType getattrname(); public void setattrname(attrtype val); // attribute "getter" // attribute "setter" AttrType puede ser cualquier tipo de Java. AttrName es case sensitive, por lo tanto getconnection() y getconnection() definen dos atributos distintos, Connection y connection respectivamente. Si existen ambos, el atributo getter y el setter, el atributo es de lectura/escritura, si sólo el getter está presente entonces es un atributo de sólo lectura, y si sólo el atributo setter está presente es un atributo de sólo escritura. Por último, si el AttrType es de tipo boolean, el atributo getter puede ser definido siguiendo el patrón public boolean isattrname(); El atributo puede tener uno de los métodos pero no ambos, o getattrname() o isattrname(). Todos los métodos definidos por un Standard MBean que no cumplan con la convención antes descripta, son considerados operaciones. Las operaciones, como los atributos, pueden tomar como parámetro o retornar cualquier tipo válido de Java. Para integrar un nuevo ítem al sistema se deberá especificar en el archivo de configuración del Agente una nueva entrada < Item> en la sección < Items> con la especificación del nuevo tipo de ítem. También se le asociará uno o varios monitores del tipo que corresponda, según el tipo de atributo que se esté monitoreando. En el documento Guía de instalación y configuración [GIC] se describe el proceso de configuración del archivo. En caso de que se necesiten librerías externas para la implementación del nuevo ítem, éstas se deben incluir junto con el resto y se debe modificar el archivo donde se configuran los classpath agregando el path para la nueva librería. 2WUDVFRQVLGHUDFLRQHV 7LHPSRVGHHMHFXFLyQ Los atributos asociados al ítem permiten obtener las medidas sobre las propiedades de recursos que interesa controlar. Es a través de éstos que los monitores obtienen el valor medido, lo evalúan contra la condición de alarma y notifican si es necesario. Los monitores permiten especificar la frecuencia de monitoreo, la cual podría llegar a definirse pequeña. Por este motivo es deseable que los atributos sean métodos que no tengan mucho tiempo de ejecución. No hay un patrón a seguir, pero si es básico que su ejecución no demore más de la frecuencia definida para monitorear el atributo. &DVRVGHSUXHED Durante el desarrollo del proyecto se fueron incorporando casos de prueba asociados a cada clase, utilizando la herramienta JUNIT [JUNIT]. Es recomendable que al generarse un ítem de monitoreo se incorpore su correspondiente clase para las pruebas. De esta forma se podrán incorporar al conjunto de pruebas antes realizadas y asegurar que en futuras pruebas de la herramienta se tomará en cuenta el 4

6 nuevo módulo. El nombre de la clase para las pruebas debe ser el nombre de la clase seguido de la palabra 7HVW. $FFLRQHV Las acciones como los ítems de monitoreo se modelan como Standard MBeans que deben cumplir: tener uno o varios constructores, implementar su propia interfase, no implementar la interfase NotificationBroadCaster. La idea de que las acciones sean MBeans no es en el sentido de controlarlas, u administrarlas, que perfectamente podría serlo. En este caso se definen como MBeans de servicio. Su objetivo es proveer un nuevo servicio que pueda ser utilizado a través de su interfase desde el MBeanServer donde se registre. Para que una clase java sea una acción debe cumplir, además de las condiciones de los Standard MBeans, con lo siguiente: residir en el paquete de java monitor.actions. extender la clase Action (clase abstracta), e implementar el método executeaction() el cual es el encargado de ejecutar la acción específica. implementar su propia interfase cuyo nombre corresponde al de la clase java seguido de 0%HDQ. su interfase debe implementar la interfase ActionMBean. toda excepción que se dispare desde la clase se debe encapsular en un objeto de clase ActionException. El siguiente modelo intenta resumir las relaciones entre las clases e interfases incluidas en el paquete monitor.actions: 5

7 Para agregar una nueva acción al sistema se deberá especificar en el archivo de configuración del Agente una nueva entrada < Action > en la sección < Actions> con la especificación de la nueva acción. Éstas se podrán vincular a los monitores allí definidos. En el documento Guía de instalación y configuración se describe el proceso de configuración del archivo. En caso de que se necesiten librerías externas para la implementación de la nueva acción, éstas se deben incluir junto con el resto y se debe modificar el archivo donde se configuran los classpath agregando el path para la nueva librería. 2WUDVFRQVLGHUDFLRQHV 5HJLVWURGHDFWLYLGDG La clase abstracta Action tiene un atributo log el cual permite dejar registros de las trazas de ejecución de las acciones. Estos registros son especialmente útiles al momento de buscar errores de aplicación utilizando la herramienta en ambiente de producción. Por lo tanto es altamente recomendable su utilización. &DVRVGHSUXHED Al igual que para los ítems se recomienda la generación de una clase asociada a la acción para las pruebas de la misma utilizando JUNIT. Esta clase se deberá llamar como la clase seguido de la palabra 7HVW. 6

8 0RQLWRUHR\DODUPD MX4J [MX4J] provee tres tipos de servicio de monitoreo StringMonitor, CounterMonitor, GaugeMonitor. Son MBeans de servicio, pero también de recurso ya que proveen atributos que permiten monitorearlos, por ejemplo un atributo que da información de si el monitor está activo o no. Éstos heredan de la clase abstracta Monitor donde se realiza la actividad de monitoreo pero la evaluación de la condición de alarma se realiza en las clases específicas. Cada clase tiene su propia interfase. StringMonitor: compara el valor de un atributo alfanumérico con un valor especificado y se configura para alertar en caso de que se de una condición de excepción, esta puede ser configurada para alertar si el string es igual al valor o si es diferente. CounterMonitor: compara el valor de un atributo que puede crecer con el tiempo, controlando que este valor no supere el de un tope especificado, si se pasa este valor se produce una condición de alerta GaugeMonitor: controla que el valor de un atributo numérico este comprendido en un rango definido por un tope máximo y un tope mínimo, se configuran alertas por máximo y por mínimo. La estructura de clases es la siguiente: Durante el desarrollo se debieron realizar cambios sobre estas clases lo que obligó a modificar el código de las mismas. Por lo que todas las clases residen en el paquete monitor.monitors. Además la herramienta cuenta con un cuarto tipo de monitoreo GenericMonitor desarrollado especialmente para esta herramienta. Éste no hereda de la clase Monitor ya que su uso implicaba modificar aspectos críticos de la clase Monitor. Este monitor permite evaluar expresiones booleanas. 7

9 Cuando ésta evalúa TRUE se dice que presenta una condición de alarma. Por expresión booleana se entiende una expresión que consiste de la combinación de operadores lógicos y aritméticos, funciones y variables, cuya evaluación resulta en un tipo boolean (true o false). Las variables de la expresión pueden ser los atributos asociados aun ítem. Al igual que los otros monitores cuando se da una condición de alarma envía una notificación MonitorNotification a todos los listeners que estén escuchando a ese monitor en particular. En particular las acciones son listeners de los monitores. De este modo es que se disparan las acciones. El GenericMonitor permite combinar los distintos atributos monitoreados de un ítem en una sola expresión, lo cual lo hace bastante genérico. El siguiente modelo muestra las relaciones entre clases en interfase: Los monitores son Active MBeans, éstos a diferencia de los Standard MBeans implementan la interfase NotificationBroadcaster la cual permite enviar notificaciones a otros objetos que están escuchando, estos otros implementan la interfase NotificationListener. La definición, estructura de clases, y procesos relacionados a los módulos de los monitores son un poco más complejas que en el caso de los ítems y acciones. En este caso no habría una única forma de proceder en la generación de un nuevo módulo. Una de las opciones podría ser extender la clase Monitor con un nuevo tipo de evaluación de condición de alarma. Otra podría ser un desarrollo similar al que se realizó para el GenericMonitor, pero podría haber otras. En este documento se van a dar las pautas básicas para generar un nuevo módulo de monitoreo y alarma de dos formas posibles. La primera extendiendo la clase Monitor, la segunda forma independiente de la implementación que brinda MX4J. Se recomienda leer el libro Java and JMX: Building Manageable Systems Parte II (JMX Details) capítulo seis que trata en detalle este tema [HKWHLW]. 2SFLyQ([WHQGLHQGRODFODVH0RQLWRU Este caso consiste en agregar un nuevo tipo de evaluación de condición de alarma extendiendo la clase Monitor. Esto no implicaría cambios en la actividad de monitoreo ya que ésta está encapsulada en la clase Monitor. En este caso la nueva clase java debería cumplir lo siguiente: residir en el paquete de java monitor.monitors. implementar su propia interfase cuyo nombre corresponde al de la clase java seguido de 0%HDQ. extender la clase Monitor (clase abstracta), e implementar el método executemonitor () el cual es el encargado de ejecutar la acción específica. 8

10 su interfase debe implementar la interfase MonitorMBean. para notificar cuando se den condiciones de alarma se deberá utilizar el método notifylisteners() implementado en la clase Monitor. 2SFLyQ,QGHSHQGLHQWHGHODLPSOHPHQWDFLyQTXHEULQGD0;- En este caso se incorporaría un módulo independiente de la implementación brindada por MX4J. La idea en este caso es enumerar las condiciones que debe cumplir, y sugerencias que podrían facilitar el desarrollo de mismo. Para que una clase java sea un monitor debe cumplir, además de las condiciones de los MBeans, con lo siguiente: residir en el paquete de java monitor.monitors. implementar su propia interfase cuyo nombre corresponde al de la clase java seguido de 0%HDQ. Debe extender la clase NotificationBroadcasterSupport a través de la cual puede hacer envío de notificaciones. Debe implementar la clase MbeanRegistration para poder guardar una referencia al MbeanServer donde se registre Algunas sugerencias: las notificaciones que emita para dar aviso de condiciones de alarma se deberían realizar mediante el envío de un objeto de clase MonitorNotification. De esta forma todos los listeners de los actuales monitores en uso podrían empezar a utilizar el nuevo módulo sin tener que realizar cambios. su interfase podría implementar la interfase MonitorMBean. De esta forma, al igual que con las notificaciones las aplicaciones que interactúen con los monitores ahora utilizados podrían empezar a utilizar el nuevo monitor sin cambios ya que la interfase que provee es la misma, y es solo a través de esta que se accede al monitor. Para agregar un nuevo monitor al sistema se deberá especificar en el archivo de configuración del Agente una nueva entrada < Monitor> en la sección < Monitors> con la especificación del nuevo monitor. En el documento Guía de instalación y configuración se describe el proceso de configuración del archivo. En caso de que se necesiten librerías externas para la implementación, éstas se deben incluir junto con el resto y se debe modificar el archivo donde se configuran los classpath agregando el path para la nueva librería. 9

11 5()(5(1&,$6 [Informe Final] Informe Final del proyecto de grado: Monitor de Alertas Configurable. [GIC] Guía de instalación y configuración del proyecto de grado: Monitor de Alertas Configurable. [Javadoc] Javadoc generado durante el desarrollo del proyecto de grado Monitor de Alertas Configurable. [HKWHLW] Libro Java and JMX: Building Manageable Systems Autores :Heather Kreger, Ward Harold, Leigh Williamson Publicación : Addison Wesley Fecha publicación 30 diciembre 2002 ISBN : [JMX] fecha último ingreso: 12/04/2004 [JUNIT 1] Junit Primier fecha último ingreso: 12/04/2004 [MX4J] fecha último ingreso: 12/04/