Si en uno de nuestros anteriores artículos hablábamos sobre los indicadores y su importancia para la gestión de los departamentos de TI, en éste vamos a profundizar en el origen de los mismos, es decir, en aquellas variables que constituyen la fuente del dato sobre el estado de nuestro parque tecnológico y que se obtienen a partir de un proceso de monitorización.

La monitorización constituye uno de los pilares para garantizar la disponibilidad de los servicios de TI ya que mediante la observación de los distintos componentes de nuestra infraestructura podemos detectar e incluso anticiparnos a posibles situaciones que puedan llegar a originar un problema en el negocio de nuestra organización. De hecho, en muchas ocasiones, son los propios procesos de monitorización los que pueden incorporar la ejecución de tareas o comandos sobre los entornos. Por ejemplo, si se detecta que un proceso que ha de estar siempre corriendo no lo está, se podrá lanzar un comando para arrancarlo; o si se dispara el consumo de una CPU, se podría generar un informe sobre los procesos en ejecución.

¿Qué retos nos plantea la monitorización?

En primer lugar, la elección de los mecanismos de monitorización más adecuados.
Existen distintas alternativas desde mecanismos sencillos incorporados en los propios sistemas hasta la utilización de complejas herramientas comerciales que ofrecen funcionalidades de gran potencial que van mucho más allá de la simple monitorización. Todos los enfoques se centrarán en extraer información periódica y construir “variables de monitorización” que se diferencian en la forma de obtenerla:

• Monitorización no intrusiva, utilizando la información suministrada por los propios componentes a monitorizar. Existen elementos de nuestra infraestructura TI que se han construido incluyendo funcionalidades de monitorización y que cuando detectan alguna situación importante y susceptible de ser tenida en cuenta son capaces de generar un aviso o dejar un registro para analizar.
• Monitorización intrusiva, utilizando comandos administrativos. Se trata de la monitorización típica que realizan los administradores de los sistemas y aplicaciones. A través de los interfaces que se proporcionan, bien sea por línea de comando, por WEB o con un API específico, se realizan llamadas internas a los sistemas para identificar el estado de sus componentes y construir nuestras variables de monitorización.

Aquí surge un dilema, ¿monitorizamos dentro de los propios entornos o bien desde fuera? La respuesta es sencilla, dependerá del caso. Lo recomendable es que el proceso de monitorización no interfiera o añada más carga de trabajo al entorno a monitorizar. Hay casos en los que la información que se necesita sólo se puede extraer desde dentro, aplicando lo que se denomina un agente. Un agente va a ser una pieza software que se va a encargar de obtener las variables de monitorización ejecutándose dentro del mismo entorno a monitorizar y, por lo tanto, podrá ofrecer una gran riqueza y diversidad de variables a costa de aumentar la carga de trabajo del entorno.

El segundo reto es la profundidad con la que queremos monitorizar, es decir, teniendo en cuenta la diversidad y volumen de tecnologías que pueden encontrarse en un mismo Centro de Proceso de Datos (CPD). Existen soluciones que pueden llegar a cubrir todas las tecnologías a monitorizar, bien sea porque incorporan funcionalidades diseñadas para el escenario concreto, o bien porque ofrezcan funcionalidades de scripting o kits de desarrollo que permiten incorporar la monitorización de esos entornos de forma no demasiado costosa. Si se optara por la utilización de distintas herramientas, se ha de tener en cuenta que la definición de islas de monitorización implicará un mayor esfuerzo a la hora de gestionar y administrar la información. En este punto hay que pensar en cómo se gestionan las variables obtenidas en un entorno distribuido y heterogéneo de herramientas. Una estrategia adecuada puede ser la utilización de una de ellas como centralizadora de toda la información para poder explotarla de manera conjunta y, por lo tanto, se tendrá que revisar y asegurar que todas las herramientas desplegadas son capaces de interactuar o integrarse en la medida que nuestro proceso de monitorización lo requiera.

El tercer reto que se nos presenta es el alcance de la monitorización. Éste puede ir desde la monitorización de un conjunto de componentes con las mismas particularidades (servidores, bases de datos, etc) a uno más amplio como es el de la monitorización extremo a extremo, es decir, de la simulación del comportamiento de un usuario, construyendo para ello una transacción que denominaremos “sintética” que nos permita tener la percepción de éste sobre el funcionamiento del servicio.

De cara a monitorizar bloques de componentes, se podrán definir distintos procesos que se encarguen de contrastar el estado de cada uno de los componentes tecnológicos. Con ello, podríamos ver que cada componente está dando servicio independientemente pero no tendríamos la visión global. En este punto es donde las transacciones sintéticas ofrecen su valor al representar la percepción real del usuario final. En algunas ocasiones no es sencilla la implantación de estrategias extremo a extremo, principalmente por la complejidad de las interfaces que utilizan los usuarios, pero su utilización es muy recomendable siempre que sea posible porque, aparte de proporcionarnos información sobre la disponibilidad del entorno, se obtendrán otras variables de gran importancia como, por ejemplo, el tiempo de respuesta para los usuarios finales.

¿Cómo gestiono todos los parámetros que monitorizo?

Las variables obtenidas se representan en aplicaciones gráficas que se denominan consolas. En las consolas las variables aparecerán como iconos que, por ejemplo, cambiarán de color o parpadearán para asociar las distintas casuísticas definidas para su estado o umbral de funcionamiento. Se podrán realizar asociaciones y agrupaciones de variables o construir nuevas, en definitiva, la información se podrá organizar de múltiples maneras para poder llegar a representar componentes de infraestructura TI a partir de las variables que estamos monitorizando. Y todo para que los operadores y los administradores de los entornos puedan llegar a identificar un problema lo antes posible en entornos tecnológicos complejos.

Como hemos comentado anteriormente, puede ocurrir que sea necesario utilizar distintas herramientas de monitorización, sin embargo no es muy recomendable que se definan componentes aislados e independientes dentro del proceso global, lo que se denominan islas de monitorización, ya que la información que gestionen no podrá utilizarse en relación con la del resto del entorno.

Llegados a este punto, desde Grupo SIA ofrecemos una propuesta innovadora: centralizar toda la información de monitorización en un único punto que además nos ofrezca una visión del impacto en el negocio. En este sentido, recurrimos a las mejores prácticas de ITIL para aplicar cierta visión del impacto de los eventos y alarmas en el negocio mediante la utilización de la Base de Datos de Gestión de Configuración (CMDB) integrada con el propio

sistema de monitorización y potenciada con un motor de reglas de negocio que permita aplicar un contexto de negocio (fechas críticas, ubicaciones, compromisos legales, etc) a los eventos tecnológicos. Este enfoque innovador venimos aplicándolo en los últimos años con gran éxito ya que nos ha permitido dotar a los departamentos de TI de esa visión de negocio que muchas veces es difícil de mostrar en entornos tecnológicos de gran volumen y complejidad.

Comencemos a monitorizar

Sea cual sea la herramienta que se está utilizando, hay que tener muy claro qué variables son las que nos interesa controlar. Lo normal a la hora de trabajar con una herramienta de monitorización es que una vez instalada nos ofrezca múltiples variables de las que activamente sólo se monitorizan alrededor de un 30% y el resto sean útiles para los administradores de cara a hacer un ajuste fino sobre sus entornos. Por lo tanto, es importante hacer una labor de análisis y filtrado para dedicar los recursos que realmente sean imprescindibles al control de aquellas variables que nos interesen.

Una vez definido el entorno y nuestras variables, tenemos que realizar una fase de pruebas para identificar que realmente se está monitorizando tal y como se ha definido. Lo normal es que aparezcan falsas alarmas, es decir, que se identifiquen situaciones aparentemente problemáticas cuando realmente no lo son. Igualmente siempre nos encontraremos alguna situación que nuestro proceso de monitorización no estará contemplando. Por ello, va a ser necesaria una fase inicial de pruebas y simulaciones sobre los entornos, así podremos realizar el correcto ajuste para que nuestro proceso de monitorización contemple correctamente las situaciones requeridas.

Y para finalizar, algo que le resultará de utilidad porque, además de servirnos en el momento de su extracción, nuestras variables de monitorización pueden ser almacenadas en repositorios para poder ser explotadas posteriormente. El análisis del histórico de nuestras variables permitirá analizar la evolución de los componentes monitorizados para, por ejemplo, identificar situaciones y escenarios que se repiten con frecuencia (Gestión de Problemas) o para poder definir su evolución y planificación a futuro (Gestión de la Capacidad).

Como ha podido comprobar, llegar a un buen nivel de monitorización basado en el equilibrio entre variables a monitorizar y recursos disponibles para hacerlo, no es tarea fácil, sin embargo constituye uno de los pilares sobre los que se soporta toda la gestión de servicios de TI.