Una necesidad

Desde nuestra experiencia, nos hemos planteado varias preguntas a las que intentaremos dar respuesta, preguntas como:

1. ¿Cómo puedo determinar las versiones (7,8) de agentes de monitorización OVO que tengo instalados en cada máquina de la plataforma?
2. Si alguno de los agentes OVO tiene procesos de monitorización caídos o corruptos ¿Como puedo enterarme en un plazo corto de tiempo?
3. Si algunos de los agentes OVO tiene problemas de conectividad con el Manager... ¿Como podemos detectar el problema?

La dificultad principal radica en detectar problemas independientemente del estado del agente OVO local instalado en cada máquina o incluso, independientemente del estado de la máquina (cpu, memoria, swap, io...).
Aunque, si que es cierto, que el Manager de OVO, tiene sus propios mecanismos de control para detectar problemas en la comunicación con los agentes OVO, problemas en el agente, etc... aunque nuestra experiencia nos dice, que no siempre los nodos OVO o el Manager OVO alertan de problemas en la monitorización a tiempo.


La clave

La clave que presentamos, es monitorizar el estado de nuestros agentes OVO desde el propio Manager. De esta manera conseguimos estandarizar la monitorización y abstraernos del estado de los agentes y/o máquinas locales.

Para monitorizar el estado de los agentes OVO desde el Manager vamos a utilizar un comando muy común para cualquier administrador HP OpenView Operations, este comando es el 'opcragt -status <node_name>'.

El comando 'opcragt -status <node_name>' envía una petición de 'status' al nodo monitorizado, el servidor recibe este 'status' y lo muestra por la salida estándar por defecto.

Si los nodos monitorizados están dados de alta como 'Controlled' en la bbdd de OVO, podemos extraer mucha información relevante del estado del agente OVO local que esta corriendo en el nodo monitorizando.

Pongamos un ejemplo:

#opcragt -status nodo1
    Node nodo1:
    OVO Managed Node status :
    -------------------------
    OV Control ovcd (3084) is running
    OV Communication Broker ovbbccb (3085) is running
    OV Config and Deploy ovconfd (3086) is running
    OV Performance Core coda (4349) is running
    Subagent EA:
    Message Interceptor opcmsgi (3097) is running
    Message Agent opcmsga (3098) is running
    Action Agent opcacta (3107) is running
    Logfile Encapsulator opcle (3397) is running
    Monitor Agent opcmona (3398) is running
    Done.


De esta manera el administrador OVO tiene visibilidad de los procesos del agente que están levantados, y visibilidad de procesos que puedan tener problemas en un momento determinado.


Un camino

En este punto, el paso siguiente, es definir un proceso estandarizado que nos permita chequear el 'status' de todos los nodos 'Controlled' adminstrados en nuestra plataforma OpenView.
Una primera aproximación, nos puede llevar a pensar en desarrollar un shell script que chequee todos estos nodos monitorizados y en el momento en que el script detecte algún proceso caído en alguno de los agentes, que el propio script envíe una alarma al manager alertando de esta criticidad.

Esta solución es viable, rápida y fácilmente implementable, aunque entrevee ciertas dificultades que comentamos a continuación:
- ¿Como mantenemos actualizado el listado de máquinas 'Controlled' de nuestra plataforma de monitorización? Si estamos trabajando en una plataforma muy dinámica, tenemos que pensar en una solución lo más trasparente posible de cara al mantenimiento de este fichero por el administrador OVO.
- Estamos monitorizando un gran número de máquinas, el listado de máquinas 'Controlled' está creciendo demasiado, y desde que pasamos con el script por la primera máquina, hasta que llegamos a la última, transcurre demasiado tiempo hasta que detectamos una caída en los procesos de un agente OVO determinado. La solución a este problema pasa por diversificar en varios listados, la lista única de máquinas 'Controlled' de nuestra plataforma. Un criterio perfectamente válido para diversificar este listado de máquinas, puede ser la arquitectura de la máquina monitorizada (Solaris, HP-UX, AIX, Wintel...), otro criterio puede ser la versión del agente de monitorización (siempre y cuando convivan varias versiones, por ejemplo 7 y 8). El criterio que hemos elegido en este caso es una combinación de los dos anteriores, arquitectura y versión del agente monitorizado.



El aspecto técnico

Ya tenemos un planteamiento inicial de una solución que podemos implantar en cualquier plataforma de monitorización OpenView Operations. A partir de aquí profundizaremos en los aspectos téncnicos de la solución.

¿Como obtenemos los listados de máquinas separados por arquitectura y versión de agente de monitorización? Para extraer estos listados podemos utilizar una de las funcionalidades de nos ofrece el Manager OVO en su versión 8.2X.
Estos listados los extraeremos con ayuda del comando 'opcnode', este comando nos permite hacer consultas y cambios directamente sobre la bbdd del Manager OVO, sin necesidad de abrir la consola de administración del Manager.

#opcnode -help

Usage of opcnode:

Possible commands:
------------------
-add_node | -del_node | -chg_commtype | -list_nodes |
-chg_id | -del_id | -list_id | -chg_iptype |
-add_group | -del_group | -chg_nodetype | -list_groups |
-assign_templ | -deassign_templ | -list_ass_nodes | -list_templs |
-assign_node | -deassign_node | -list_ass_templs | -chg_machtype |
-set_virtual | -set_physical | -list_virtual | -move_nodes

Attributes:
-----------
node_name=<node_name> node_label=<node_label>
group_name=<nodegrp_name> group_label=<nodegrp_label>
node_hier=<hierarchy_name> layout_group=<layout_group_name>
net_type=<network_type> mach_type=<machine_type>
comm_type=<comm_type> node_type=<node_type>
id=<id>
cluster_package=<cluster package identifier>
dynamic_ip=yes|no
node_list='<list>'
templ_name=<templ_name> templ_type=<templ_type>




Por ejemplo en el caso de que queramos extraer un listado de todas las máquinas con arquitectura Solaris y Agente de monitorización OVO8 instalado, podemos ejecutar el comando siguiente:
/opt/OV/bin/OpC/utils/opcnode -list_nodes mach_type=MACH_BBC_SOL_SPARC|grep Name|grep -v grep|awk '{print $3}' > MACH_BBC_SOL_SPARC.cfg


De esta manera, si hacemos un script con varios 'opcnode' podemos extraer listados independientes por cada arquitectura y agente de monitorización.



Perfeccionando nuestro script

Pensando en mejorar el script, nos podemos plantear la cuestión de que a priori sólo nos interesa monitorizar los agentes OVO de aquellos nodos que estén configurados como 'Controlled' en la bbdd del Manager, por ejemplo aquellos nodos definidos como 'Disabled' no nos interesa monitorizar.

Para esto, tenemos que buscar la manera de poder extraer de la bbdd del Manager un listado de máquinas definidas como 'no-controlled'. ¿Como podemos hacer esto? En este caso no podemos utilizar el comando 'opcnode', ya que no nos permite extraer esta información. En este punto, nuestra propuesta consiste en extraer esa información directamente sobre la bbdd de OpenView con la query siguiente:
select label, node_type from opc_nodes where NODE_TYPE ='1' OR NODE_TYPE ='4';

Si esta query la damos formato en un script sql el listado de nodos será más fácil de manejar, este script sql lo podemos descargar en este link de la sección de scripts.

A partir de este script sql, podemos crear un shell script que nos permita generar el listado definitivo de nodos 'no-controlled' en toda nuestra plataforma OpenView, este shell script lo podemos descargar en este link de la sección de scripts.

Opcionalmente podemos definir otro listado de nodos definidos en nuestra bbdd de OpenView como 'controlled' pero de los que tampoco queremos hacer 'opcragt -status'. Este listado que administraremos manualmente pero que integraremos en nuestro script final lo podemos denominar 'nodos-nomonitorizar.cfg'.


Generación automática de los listados

En este punto ya podemos obtener manualmente o mediante script los siguientes listados de nodos:
    MACH_RS6000.cfg
    MACH_SUN_SOLARIS.cfg    
    MACH_WINNT.cfg
    MACH_BBC_AIX_PPC.cfg
    MACH_BBC_HPUX_IPF32.cfg
    MACH_BBC_HPUX_PA_RISC.cfg
    MACH_BBC_LX24RPM_X86.cfg
    MACH_BBC_LX26RPM_X86.cfg
    MACH_BBC_SOL_SPARC.cfg
    MACH_BBC_WINNT_X86.cfg
    MACH_HP10_S800.cfg
    MACH_HP11_PA_RISC.cfg
    MACH_LINUX24.cfg
    MACH_LINUX26.cfg
    MACH_NON_IP.cfg
    MACH_OTHER.cfg
    nodos-disabled.cfg
    nodos-nomonitorizar.cfg


Si seguimos desarrollando nuestra idea, ahora lo que nos interesaría sería poder integrar de manera automática la generación de estos listados en un único script. En este link podemos obtener el shell script que agrupa la generación de los listados.

El siguiente paso sería planificar la ejecución de este script, para olvidarnos de la administración y el mantenimiento de los listados. Para esto tenemos dos opciones:
1. La primera opción consiste en crear un tarea en el crontab de nuestro servidor unix de monitorización, esta opción es más clásica pero en la mayoría de los casos muy fiable y eficaz.
2. La segunda opción* es crear una plantilla en nuestro manager OpenView de tipo 'Schedule', en esta política podemos especificar los mismos parámetros de ejecución que en el caso del crontab de unix, también podemos enviar a la consola mensajes informativos en el caso de que la tarea programada se haya ejecutado correctamente o enviar mensajes con instrucciones en caso de que la tarea programada no haya finalizado con éxito.

*Si optamos por esta segunda opción, debemos saber que si nuestro manager OpenView no está funcionando correctamente, está caído, o tiene problemas con la ejecución de las tareas programadas, la generación automática de los listados de nodos, no está garantizada.


Que procesos monitorizar y script

Una vez que ya hemos obtenido los listados con los nodos de nuestra plataforma de monitorización dividos por arquitecturas y los listados con los nodos sobre los que no queremos que nuestro script haga 'opcragt -status', procederemos a definir la estructura del script y los procesos críticos que queremos monitorizar en nuestros agentes de monitorización OVO7 y OVO8.

Para el caso de agentes de monitorización versiones OVO7 hemos evaluado que los procesos más críticos y que debemos monitorizar son los siguientes:
    opcctla -> Control Agent
    opcmsga -> Message Agent
    opcacta -> Action Agent
    opcle -> Logfile Encapsulator
    opcmona -> Monitor Agent
    opcmsgi -> Message Interceptor
    coda -> Performance Agent

Para el caso de agentes de monitorización versiones OVO8 los procesos más críticos evaluados son:
    ovcd -> OV Control
    ovbbccb -> OV Communication Broker
    ovconfd -> OV Config and Deploy
    opcmsga -> Message Agent
    opcacta -> Action Agent
    opcle -> Logfile Encapsulator
    opcmona -> Monitor Agent
    opcmsgi -> Message Interceptor
    coda -> OV Performance Core

Ahora que ya tenemos los listados de los diferentes grupos de nodos, y los procesos que queremos monitorizar, no sería dificil diseñar un script que recorra estos listados de nodos y obtenga el resultado del status de los procesos del agente OVO que monitoriza una determinada máquina.

En este link podemos descargar una propuesta de shell script 'mon_agentesOVO.sh' para monitorizar los procesos de nuestros agentes OpenView.


Configuración de plantillas y monitores

En este punto que ya tenemos desarrollado el script, tenemos que implementar y distribuir a nuestro gestor/manager las políticas de tipo 'monitor' que ejecutarán periódicamente el script que monitoriza los procesos de agentes OVO.

Vamos a necesitar crear un monitor por cada listado de nodos que queremos que nuestro script gestione, en definitiva, una política de tipo 'monitor' por cada arquitectura que gestionamos en nuestra plataforma OpenView.

Por ejemplo:
###################################################################################
Monitor Name                         Monitor Program                               Polling Interval        Threshold/Message
###################################################################################
mon_RS6000                          mon_agentesOVO.sh mon_RS6000                     5m             Maximun/Continuous
mon_SUN_SOLARIS              mon_agentesOVO.sh mon_SUN_SOLARIS          5m             Maximun/Continuous
mon_WINNT                         mon_agentesOVO.sh mon_WINNT                     5m             Maximun/Continuous
mon_BBC_AIX_PPC               mon_agentesOVO.sh mon_BBC_AIX_PPC          5m             Maximun/Continuous
mon_BBC_HPUX_IPF32         mon_agentesOVO.sh mon_BBC_HPUX_IPF32     5m             Maximun/Continuous
mon_BBC_HPUX_PA_RISC    mon_agentesOVO.sh mon_HPUX_PA_RISC        5m             Maximun/Continuous
mon_BBC_LX24RPM_X86       mon_agentesOVO.sh mon_BBC_LX24RPM_X86    5m             Maximun/Continuous
mon_BBC_LX26RPM_X86       mon_agentesOVO.sh mon_BBC_LX26RPM_X86    5m             Maximun/Continuous
mon_BBC_SOL_SPARC         mon_agentesOVO.sh mon_BBC_SOL_SPARC      5m             Maximun/Continuous
mon_BBC_WINNT_X86         mon_agentesOVO.sh mon_BBC_WINNT_X86      5m             Maximun/Continuous
mon_HP10_S800                   mon_agentesOVO.sh mon_HP10_S800                5m             Maximun/Continuous
mon_HP11_PA_RISC            mon_agentesOVO.sh mon_HP11_PA_RISC          5m             Maximun/Continuous
mon_LINUX24                      mon_agentesOVO.sh mon_LINUX24                    5m             Maximun/Continuous
mon_LINUX26                      mon_agentesOVO.sh mon_LINUX26                    5m             Maximun/Continuous
mon_NON_IP                       mon_agentesOVO.sh mon_NON_IP                    5m             Maximun/Continuous
mon_OTHER                        mon_agentesOVO.sh mon_OTHER                      5m             Maximun/Continuous


Para poder capturar la recepción mensajes de tipo 'opcmsg' que se utilizan cada uno de los monitores anteriormente definidos, es necesario distribuir una plantilla de tipo ‘Message’ al nodo (en este caso el gestor) donde vamos a ejecutar los monitores.

En esta plantilla, si seguimos la nomenclatura del shell script 'mon_agentesOVO.sh', debemos definir tres 'Conditions' en este orden correspondiente:
1 + agente_haciendo_buffering (Application=AgenteOVO;Message Group=gestion_admin;Object=buffering)
2 + procesos_agente_OVO7 (Application=AgenteOVO7;Message Group=gestion)
3 + procesos_agente_OVO8 (Application=AgenteOVO8;Message Group=gestion)



Ya definidas las 'conditions' que recojen los 'opcmsg', podemos perfeccionar nuestras alarmas de control de agentes y añadir las instrucciones necesarias para traspasar las caídas de procesos de agentes OVO al grupo de explotación y operadores de nuestra compañía. Para esto nos podemos hacer referencia al Troubleshooting que ya presentamos en artículos anteriores.