En la búsqueda de la solución apropiada de monitoreo resulta frecuente encontrarse con diferentes alternativas en relación a la estrategia que cada herramienta utiliza para cumplir con su función.

Se encontrarán referencias a monitoreos pasivos vs activos, locales vs remotos, invasivos vs no invasivos, mediante WMI, mediante SNMP, etc., y la lista continúa.

Qué significan realmente estos términos y como deben evaluarse al momento de decidirse por una herramienta particular ?

Monitoreo informático (o monitorización), refiere al flujo de información que se genera desde y hacia la estructura informática (en sentido amplio, contemplando hardware, software e infraestructura), con el objeto de relevar el estado en el que se encuentran los distintos parámetros operativos, con la intención de alimentar diversos procesos IT. Fundamentalmente:

» Gestión de fallas (o Fault Management)

» Gestión de incidentes (o Incident Management)

» Gestión de performance (o Performance Management)

» Gestión de capacidad (o Capacity Management, o Capacity Planning)

Manual vs Automático

El monitoreo manual es más frecuente de lo que podría pensarse. De hecho, es el mecanísmo más habitual. En este, uno o varios operadores, revisan parámetros que consideran relevantes de la estructura IT, e intentan detectar condiciones no deseadas para luego poder proceder a la toma de acción.

Habitualmente este modelo es extremadamente costoso en términos de esfuerzo (horas-hombre), ya que el tiempo insumido se repite ad-infinitum, en la medida que no se tomen acciones para automatizarlo.

En el monitoreo automático, se elaboran instrumentos informáticos para efectuar el control, que deben considerar básicamente 3 aspectos:

» Como ejecutar el control (puede ser en forma manual, o automática mediante schedulers)

» Como obtendrá el control la información deseada (una vez disparado)

» Como reportará los resultados

El segundo de estos puntos es el que habitualmente recibe una mayor atención. Si bien es seguramente el más importante de los tres (sin él los otros dos no tienen sentido), es de suma importacia conseguir respuestas efectivas para los otros aspectos.

En el monitoreo automático, por estar estrechamente ligado a la noción de repetición del control, es fundamental la revisión y ajuste de las herramientas utilizadas para asegurar la efectividad a lo largo del tiempo.

Cuando se cumplen con estos objetivos, los recursos de operación ven aliviada su carga de tareas repetitivas y se pueden reasignar a otras de mayor valor.

Local vs Remoto

El monitoreo remoto ocurre cuando para el control de un determinado servicio IT, toda la ejecución del software de control ocurre sin utilizar recursos del equipamiento monitoreado.

Como ejemplo puede pensarse en el control de un web server. Si desde un equipo "cliente" se realiza un requerimiento http hacia el servidor web, y según su respuesta (o falta de ella) se llega a una cierta conclusión sobre su estado, podemos decir que todo el software de control se ha ejecutado fuera del web server, y por lo tanto estamos en presencia de monitoreo remoto. Podría argumentarse que el servidor web ha tenido que responder al requerimiento http, por lo que en definitiva se han utilizado recursos del dispositivo que se quiere monitorear; pero debe tenerse en cuenta que el servidor no ha ejecutado "software de control", sino que ha cunplido con su funcionamiento habitual de responder requerimientos http.

En contraposición, en el monitoreo local, se involucran recursos del equipo a monitorear para la ejecución de software de control. Como ejemplo de esta modalidad, podemos considerar el caso en el cual se prepara un cierto script o programa para que extraiga de un log la condición de finalización del backup nocturno. De este modo, cuando este script de ejecute, se tendrá un elemento de control para evaluar la ejecución de dicho backup. Vemos como en este caso, es el propio equipo monitoreado quien facilita sus recursos (CPU, memoria, etc) para la realización del control.

Esta distinción entre ambas modalidades, tiene implicancias sobre el significado y la intepretación que deben asignarse a un control; y debe ser tenida en cuenta a la hora de diseñar un procedimiento de monitoreo. Tomese por caso el control de un servidor web. Mediante monitoreo local, podemos tener la posibilidad de relevar diversos parámetros y conocer en profundidad las causas de un mal funcionamiento cuando este ocurra. Estas son las ventajas que se obtienen con un monitoreo local (o interno).

Sin embargo, con un monitoreo remoto, a pesar de limitarse el acceso a información de detalle; podemos conocer como se percibe el servicio web, desde un punto externo al propio servidor. Debe considerarse que si ambos controles generarán un log con los resultados de sus ejecuciones, en los equipamientos donde se ejecutan, ante una pérdida de conectividad del servidor web (con el resto del mundo), obtendriamos un escenario en donde se registra dicha caida en el log del monitoreo remoto, pero no se detectan caidas en el log local.

Activos vs pasivos

Este aspecto refiere básicamente a la respuesta a la pregunta: quien "dispara" la ejecución del control. No ya quien la ejecuta, sino quien la dispara.

Dado que "activo" y "pasivo" son términos que dependen del punto de vista que se tome para analizar este punto, asumamos que contamos con un servidor central de control como el NobServer de NoxGlobe (que es quien coordina el monitoreo, y concentra los resultados). Con esta consideración, diremos que controles "activos" son aquellos "disparados" por el servidor central, y "pasivos" aquellos son "disparados" por cada uno de los equipos monitoreados (o endpoints).

Logicamente cuando no existe un servidor central de monitoreo esta distinción pierde sentido.

Por otro lado, muchos productos de monitoro carecen de la posibilidad de ejecutar controles pasivos, ya que no cuentan con un scheduler propio del lado de los endpoints.

Contar con ambas alternativas es una opción muy interesante ya que entre las opciones que brinda, se incluye la posibilidad de ajustarse del mejor modo posible a las condiciones particulares que para cada organización median entre los endpoints y el servidor central de monitoreo.

Invasivos vs no-invasivos

Esta distinción es más sutil, y busca encontrar un punto de equilibrio entre proveer al control de todo lo necesario para que la información que este releva sea suficiente y significativa; y diseñarlo de tal modo que su propia ejecución no resulte disruptiva del servicio que pretende controlar. Puede tomarse como ejemplo una medición sobre la performance de un servidor de base de datos. Si deseamos conocer que tan bien está desempeñandose el servidor frente a las consultas que recibe, y para ello medimos la ejecución de una consulta ad-hoc, incluida en el propio control, de naturaleza particularmente compleja y de costoso procesamiento, seguramente estaremos afectando significativamente con la propia medición, la performance que deseamos controlar. Es por esto que se considera deseable balancear estos aspectos de cualquier control, para acercarse lo más posible al óptimo.

Algunas consideraciones que deberían tenerse en cuenta a la hora de optar por una solución de monitoreo:

El ahorro de tiempo que la herramienta le otorga por la automatización de controles que le permite realizar, debe ser significativamente mayor al tiempo de administración que la herramienta demanda. Muchas soluciones económicas, exigen un alto nivel de expertise por parte de sus operadores, y las instancias de configuración son realmente complejas. Es inevitable que deba dedicarse tiempo y recursos al desarrollo de controles propios de su organización, que son particulares y distintos de lo que se encuentran en otras empresas. Pero si además de esto debe asignar tiempo y recursos a capacitación y administración en la herramienta, la ecuación no resulta tan conveniente.

Aléjese lo antes posible del modelo manual. Como todo en IT, aquellas cosas que deben hacerse siempre del mismo modo, y sin aplicar demasiado criterio o sentido común, deben hacerlas las máquinas. Elija una solución que le permita absorver rápidamente el 80% de su esfuerzo de monitoreo.<

Exija acceso a la información histórica. Fuera de la facilidades de reporting que la herramienta ofrezca, asegurese de poder accederla desde otras aplicaciones y de que el modelo de datos le sea provisto.

Verifique las facilidades para personalizar el acceso a la información. Dado que todo corre sobre IT en la organización, poder darle visibilidad de lo monitoreado a los distintos actores es facilitar el ingreso del producto a su empresa. Seguramente la alta gerencia no querrá saber sobre detalles de discos, redes y memorias; pero sin dudas les resultará atractivo contar con un overview de la disponibilidad del servicio o de ciertos parámetros aplicativos.

Indague sobre que alternativas de notificaciones le ofrece. Qué ocurre cuando usted o su personal se retira de las instalaciones corporativas ? Como será informado si ocurren eventos no deseados ? Quiénes y cuando serán notificados ? El motor de notificaciones es fundamental para que la herramienta se independice de la presencia física del personal en las estaciones de trabajo.

Pruebe la solución. No cree que sería fantástico poder instalar el producto, configurarlo, sin afectar seriamente la disponibilidad de sus reecursos, y probarlo en forma gratuita y con asistencia del proveedor ? Quizás parezca demasiado bueno para ser posible, pero NoxGlobe le brinda esta alternativa. Aplique para un TestDrive de NoxGlobe.

Si su organización no cuenta con un producto de monitoreo (o monitorización), la incorporación de una solución eficiente liberará total o parcialmente recursos afectados al control informático. Opte por una solución cuyo modelo comercial se ajuste a este escenario. NoxGlobe ofrece un novedoso Leasing como instrumento para su adquisición.