¿Y tu caja está abierta o cerrada? Monitoriza con un enfoque diferente

Caja Abierta y Cerrada: dos modelos de Monitorización

En el campo automatizado de la computación, cada cierto tiempo se imponen algunos términos o modas. Hoy veremos el concepto de Caja Abierta y Cerrada, aplicándolo a la ciencia y al arte de la monitorización.

Introducción

Hoy daremos un nuevo enfoque a la materia de monitorización, desde que instalamos a Pandora FMS (o cualquier otro software que hayamos seleccionado, ya que hablaremos en gran parte sobre conceptos) para luego introducir las ideas de Caja Abierta y Cerrada. Seremos breves en nuestra explicación; no obstante incluiremos enlaces para que quien lo desee pueda ahondar en cada aspecto.

Recolectando métricas

Todo administrador de una red de área local debe ser consciente de que la monitorización es algo insoslayable y que con Pandora FMS el trabajo se hace mucho más fácil. Para ello, Pandora FMS toma en cuenta las métricas más importantes, pero como -por ahora- Pandora FMS no puede hacer magia, usa la monitorización dinámica, una característica agregada desde el lanzamiento de nuestra versión 7.0 NG para hacer más llevadera la instalación.

Dichas métricas que recolectamos están englobadas en cuatro categorías:

• Indicadores de rendimiento de sistemas (hardware a nivel de ordenadores).
• Indicadores de rendimiento de bases de datos (a nivel de sistema operativo).
• Indicadores de rendimiento de aplicación (ídem al renglón anterior).
• Indicadores de rendimiento de red (hardware a nivel de red, “cableado” solemos decirle). Por sí sola esta categoría nos lleva a la pérdida de paquetes y a la monitorización del ancho de banda.

Todas estas métricas son recolectadas de muy diferentes formas y maneras, dependiendo de la topología de red, lo que nos lleva a la monitorización distribuida, donde explicamos muy bien la flexibilidad que caracteriza a Pandora FMS.

Manejo de alertas

Pasado cierto tiempo (digamos una semana) recolectando datos se nos llenará nuestra vida de alertas (ya sea por medio de correo electrónico o por servicios de mensajería tales como Telegram o Twitter), lo cual es completamente normal y no es para asustarse ni retroceder.

• Si es algo realmente importante procederemos a corregirlo y dejar la alerta tal cual, comenzando así a cosechar el fruto de nuestro trabajo con Pandora FMS.
• Si no amerita mayor atención podremos modificar la alerta (sí, sabemos que la monitorización dinámica de Pandora FMS fue quien la incluyó, pero al final somos nosotros lo que decidimos) ajustando los valores para evitar la excesiva repetición. Cada alerta en Pandora FMS tiene una pestaña de comentarios donde podemos justificar y/o narrar la razón por la que modificamos los valores de la alerta. Así podremos ir de vacaciones y nuestros suplentes tendrán una guía humana presente para asesorar.
• Es necesario saber que una alerta puede ser suspendida para que no se muestre en el escritorio de Pandora FMS, ya sea porque vamos a realizar algo puntual y urgente o incluso la podremos programar en ciertos horarios (por ejemplo, a la hora de respaldar datos de servidores de bases de datos, lógicamente la red se congestionará y disparará una alerta, ya que Pandora FMS no está al tanto de cómo es nuestra política o manera de respaldar datos).
• El siguiente paso sería desactivar una alerta determinada, lo cual es más recomendable que eliminarla porque en esto de la monitorización hoy tenemos un ambiente y mañana no sabemos, así que podríamos volver a necesitarla y nos ahorraremos el trabajo de crearla de nuevo. También esto explica el porqué los trabajos de monitorización no pueden ser completamente automatizados.
• Cuando modificamos una alerta uno de los valores que podremos establecer es el número máximo de repeticiones que nos notificará Pandora FMS (eso viene a ser como cuando nuestra piel siente las primeras gotas de la lluvia, pasado cierto tiempo, y estando ya mojados, deja de informarnos de ello). Sin embargo hay otros eventos que se producen en cascada y disparan una gran cantidad de alertas en masa: si el módem con el cual acceden al Internet en una determinada sucursal, por ejemplo, se daña o no tiene conexión, todos los dispositivos en esa red de área local dispararán las alarmas (suponiendo que no tengamos un servidor satélite). Para ello, Pandora FMS cuenta con una Protección en Cascada bajo una entidad modelo “padre-hijo”: activamos la casilla de correspondiente y luego pasamos a asociarlo con el agente padre. En caso de que el agente padre tenga alguna alerta de estado crítico, los agentes hijos no dispararán sus alarmas.

• No podemos despedir esta sección sin comentar que una vez afinadas todas estas alertas, podremos evolucionar y crear alertas genéricas por grupos de agentes (a fin de reutilizarlos en nuevos dispositivos que agreguemos a nuestras redes) e incluso llegar a la creación de alertas por correlación de eventos para identificar y actuar en casos donde no se dispara ninguna alerta clásica. Imaginad que tenemos varios servidores web con carga balanceada y los tenemos configurados para que alerten si alguno sobrepasa el 90% de uso de CPU, pero sucede que todos y cada uno de ellos llegan al 60% y hasta 70% de su capacidad: este es un buen momento de alertarnos para tomar la decisión de primero revisar qué está produciendo la sobrecarga y si es necesario agregar más servidores, si el caso fuera el crecimiento natural de la empresa y sus clientes web. Además, hasta nos es útil para detectar modificaciones de hardware y/o software que conllevan a investigar y/o agregar más agentes monitorización (o al menos su modificación).

Caja Abierta

Ya podemos entonces definir el modelo de Caja Abierta: nosotros conocemos nuestro sistema, cómo funciona, cuáles son los procesos, y con la ayuda de Pandora FMS podremos colocar agentes (e incluso satélites) para recolectar los datos. Estamos en la categoría de Caja Abierta, pues tenemos el mapa completo, sabemos al detalle cada proceso y el mecanismo completo, no hay nada oculto ni cerrado para nosotros. Evidentemente que la recolección de métricas bajo el esquema de Caja Abierta nos permite ahorrar tiempo y esfuerzo, ya que sabemos con antelación dónde y cómo trabajan los puntos clave y podremos monitorizar de manera vertical; sin embargo, puede ser que algún aspecto desconocido o inesperado, bajo ciertas condiciones, se escape de nuestras manos, así que surge la prueba de Caja Abierta.

Prueba de Caja Abierta

La prueba de Caja Abierta es también conocida como caja transparente o caja cristalina (entre otros nombres) y en realidad está fuera de nuestro alcance pues pertenece al equipo de desarrollo y al equipo de operaciones (al cual estamos adscritos como equipo de monitorización) y aprovecha el conocimiento que tenemos del software y el sistema para hacerlo parte de un proceso de prueba. Sucede que, bajo ciertas circunstancias que hemos detectado por nuestras alertas, en base a métricas bien recolectadas por el modelo de Caja Abierta, podemos indicarles las condiciones exactas para reproducir una determinada excepción. Las ventajas son claras:

• Obtenemos un máximo panorama de la situación.
• Ayuda a optimizar el código.
• Introspección de los programadores, conciencia de sus actos.
• Permite encontrar posibles errores ocultos.
• Todo esto lleva a una eficiencia para encontrar errores y problemas.

Las desventajas de la prueba de Caja Abierta:

• Necesitamos conocer el código fuente del o los software involucrados.
• Requiere un alto conocimiento y experiencia del programa o programas afectados.

Software de monitorización que utilizan el modelo Caja Abierta

Aparte del propio Pandora FMS, son muchos otros software los que utilizan este modelo; en su debida oportunidad publicamos un artículo sobre Zabbix (podremos ver su funcionamiento en detalle aunque se trate de una comparativa); tenemos a PRTG Network Monitor (el cual evaluamos y es del mismo peso y talla de Pandora FMS, pero con software privativo).

Cuando los usuarios nos reportan que “el sistema va lento”

Si bien ya tenemos nuestra navaja suiza (Pandora FMS) y estamos más prestos que un niño explorador, en algún momento llegará el temido reporte cualitativo de uno o más usuarios finales: “el sistema va lento“.

Con los reportes debemos tener más paciencia que un santo: de nuestros usuarios, ya sean empleados o clientes, aquí es que debemos agudizar nuestro ingenio. Para los usuarios que son empleados debemos indicarles el método más adecuado para reportar cualquier problema.

En el caso de los clientes de la empresa debemos confiar en el departamento de atención al cliente. Esto no quiere decir que la batalla esté perdida, sino que es hora de llamar a la caballería y a la artillería que tenemos en Pandora FMS.

Aplicaciones que interactúan con los usuarios

Hoy en día nuestro mundo de información transcurre en dos tipos de aplicaciones: una, la de siempre, la que es instalada en un sistema operativo mediante un proceso adecuado y debidamente configurado para ese ambiente particular y es lo que conocemos siempre como vulgares aplicaciones de escritorio (compiladas especialmente para un ambiente particular).

La otra es, irónicamente, también una aplicación de escritorio pero que desde hace más o menos diez años ha ganado un tremendo protagonismo gracias a los complementos desarrollados para ella: nuestros navegadores web. Un navegador web escrito en software libre como lo es Mozilla Firefox ofrece a los programadores los típicos lenguajes de HTML (CSS incluido) y JavaScript, dándonos un entorno bien conocido y seguro, sin importar el sistema operativo instalado o el hardware utilizado. Pero aún más, nos permite incorporar los complementos o “plugins” para una amplia variedad de tareas, desde juegos hasta emular sistemas operativos o simplemente ejecutar terminales virtuales. Cada día avanza más la programación hacia este sector, dadas las evidentes ventajas.

Monitorizando aplicaciones de escritorio

Pandora FMS tiene para el sistema operativo Windows el Pandora Desktop Robot (PDR), el cual nos permitirá grabar acciones sobre cualquier software instalado y obtener sus resultados (ejecución correcta o no, tiempo de procesado) que luego podrán ser enviados a nuestro servidor de monitorización para evaluar los datos.
Se recomienda instalar el PDR y la sonda en máquinas virtuales con autoarranque y autoregistro de usuario para poder grabar las acciones, guardar y listo. Podremos tener estas máquinas virtuales corriendo continuamente para ejecutar pruebas periódicas o lanzarlas cuando un usuario nos reporte algún problema. Para ello, reproduciremos la situación planteada una sola vez ya que la grabaremos y programaremos para que se ejecute de manera autónoma muchas veces, luego analizar los resultados y confirmar bien sea el fallo o el error en el reporte.

Una opción más atrevida es instalarla mediante Active Directory en las máquinas de los usuarios finales y desde allí, desde el entorno real, ejecutar nuestras pruebas. Esta opción debe llevarse a cabo con mucho tacto, incluso sobre usuarios puntuales que reiteran el mismo reporte una y otra vez.

Monitorizando aplicaciones web

Aquí hay dos componentes que podemos monitorizar: en el lado del servidor y en el lado del cliente. En el lado del servidor haremos uso del modelo de Caja Abierta ya que conocemos cómo funciona, a qué base de datos se conecta, lenguajes utilizados, etc. Pero en el lado del cliente haremos uso del Pandora Web Robot (PWR), que permite la navegación por sitios web simulando acciones de usuario y recogiendo los resultados como si fuera una monitorización cualquiera. Podéis ver este vídeo explicativo en Youtube.

Entre las posibilidades de esta monitorización se incluye la capacidad de instalar máquinas virtuales o reales en situaciones geográficas distintas, pongamos por caso el de diferentes ciudades e incluso continentes apuntando al mismo servidor web; esto nos dará un panorama real y, lo más importante, un informe cuantitativo que podrá ser confrontado con lo reportado por los usuarios (modo correctivo) o por tareas programadas por nosotros mismos (modo preventivo).

Caja Cerrada

Esto último que hemos visto es el modelo de Caja Cerrada, ya que podremos aplicarlo aún cuando no tengamos a mano los datos de un modelo de Caja Abierta (de hecho, es un modelo independiente). El modelo de Caja Cerrada podemos usarlo en cualquier aplicación de escritorio o aplicación web y comenzar a recolectar datos durante un tiempo como si fueran métricas normales y promediar valores (de nuevo, tomemos una semana por asunto) para que a partir de allí se generen alertas.

Se llama modelo de Caja Cerrada porque desconocemos cómo funcionan las aplicaciones, a dónde van y de dónde vienen; lo que conocemos es lo que ve el usuario final, quien nos indicará qué procesos son críticos y que nosotros procederemos a analizar y monitorizar en busca de deterioro (o tal vez mejora) en el rendimiento del software. Estamos en el extremo final, donde solo conocemos el resultado y no tenemos ni la menor idea de qué lo causa.

Podremos ver este modelo de Caja Cerrada como un proceso de auditoría: una empresa nos contrata para que revisemos su software en diferentes ambientes pero no nos proporciona ni el código fuente ni nos permite acceder a sus servidores, solo a sus servicios API o WEB según sea el caso. Su funcionamiento está oculto pero tranquilamente podemos enviar nuestros informes de forma cuantitativa en donde los valores están extendidos/excedidos o cuando hayan variado significativamente (un valor de 10% siempre es una buena referencia de variación, para bien o para mal) y en distintas condiciones (hora, ubicación geográfica, método de conexión, diferentes ordenadores y/o sistemas operativos, etcétera).

En el desarrollo de software privativo viene muy bien el modelo de Caja Cerrada: Pandora FMS es la herramienta para probar y/o llevar al extremo las futuras aplicaciones que llegarán a los usuarios sin comprometer para nada el código fuente o tocar los servidores o infraestructuras correspondientes. O sea, monitorizamos incluso antes de que comience la etapa de producción, una especie de usuario beta pero con herramientas muy especializadas.

Siguiendo el ejemplo último, tal vez nuestro cliente se interese en averiguar dónde ocurre o qué causa el problema, pero no podremos darle esa respuesta ya que nos contrataron para trabajar bajo el modelo de Caja Cerrada y dicho modelo solo evalúa resultados, no sus causas, a menos que tengamos a Pandora FMS en nuestro arsenal.

Prueba de Caja Cerrada

Las pruebas de Caja Cerrada (también conocidas como pruebas funcionales) tratan el software bajo prueba como un todo sin conocer sus componentes internos. Las pruebas usan interfaces de software y tratan de garantizar que funcionen como se espera. Mientras la funcionalidad de las interfaces permanezca sin cambios, las pruebas deberían ser exitosas incluso si se cambian las funciones internas. La prueba de Caja Cerrada es “consciente” de lo que debería hacer el programa, pero no tiene el conocimiento de cómo lo hace. La prueba de Caja Cerrada es el tipo de prueba más comúnmente utilizado en las organizaciones tradicionales que tienen usuarios beta como un departamento separado, especialmente cuando no son expertos en codificación y tienen dificultades para comprender el código. Proporciona una perspectiva externa, como una auditoría, del software bajo prueba.

Software que utilizan el modelo de Caja Cerrada

Nagios (aunque sus agentes son un tanto engorrosos de configurar) es uno de los software que, al fin y al cabo, obtiene sus métricas de esta manera.

Monitorización: Caja Abierta y Caja Cerrada

Pandora FMS está diseñado para adaptarse a muchos de los retos que se presentan; cada empresa tiene sus particularidades pero no por ello significa que no estemos preparados, en absoluto. La monitorización de servicios es algo bien diferente a lo habitual: los servicios serán esa serie de funciones o trabajos que ofrecemos a nuestros clientes o colaboradores. Dichos servicios, resumiendo, serán los de bajo nivel (modelo de Caja Abierta) o de alto nivel (modelo de Caja Cerrada), por lo que constituye un modelo mixto de trabajo y hasta nos atreveríamos a decir que es el más adecuado pero también el que conlleva mayor trabajo, porque ambos resultados deberemos compaginarlos y entregarlos a los equipos de desarrollo y operaciones, a fin de hallar la solución a los errores o encontrar posibles mejoras al desempeño.

Conclusiones

Hemos abarcado al menos un 80% de la materia de la monitorización, de la forma más amena posible. Si lo deseais podéis agregar nuestro artículo a vuestras webs favoritas para que vayáis leyendo -y descubriendo- en varios días la razón por la que nos apasiona tanto nuestro trabajo: abarca programación, administración de redes y asistencia a usuarios finales, usuarios programadores e incluso robots. ¡Titánica tarea!