La informática, en el campo automatizado de la computación, cada cierto tiempo se imponen como moda ciertos términos y aquí veremos los conceptos de Caja Abierta y Caja Cerrada (con mayúsculas como nombres propios derivados de los anglicismos Black Box y White Box, respectivamente) aplicado a la ciencia -y arte- de la monitorización. Como sucede en los exámenes en las universidades, justificamos nuestra respuesta, leed nuestro artículo a continuación.
Introducción
En esta oportunidad daremos un enfoque a la materia de monitorización desde el punto de vista cronológico, es decir, 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 Caja Cerrada. Seremos breves en nuestra explicación, no obstante estimado lector o lectora, fijaos que incluimos enlaces hacia artículos anteriores donde podrán ahondar sobre cada aspecto en particular.
Recolectando métricas
Todo administrador de una red de área local (e incluso de redes amplias cuando se intercomunican por Internet) está consciente 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, tal como explicamos en un artículo anterior, pero como -por ahora- Pandora FMS no puede hacer magia pues se vale de 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.
Dicha 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 conlleva 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, y que deberemos gestionar y tratar apropiadamente:
- 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 el por qué modificamos los valores de la alerta, así cuando nos vayamos de vacaciones nuestros suplentes (o relevos, quien sabe) tendrán una guía humana presente para asesorar.
- Es necesario conocer que una alerta la podremos suspender para que no se muestre en nuestro 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 lo 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, en el siguiente punto tomaremos esto en cuenta.
- 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 afinado 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, 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á sobrecargando y si es necesario agregar más servidores, dado el caso sea 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 y cuáles son los procesos, y con la ayuda de Pandora FMS podremos colocar agentes (e incluso satélites) para recolectarlos. Cuando sucede esto 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 claves y podremos monitorizar de manera vertical, sin embargo puede ser que algún aspecto desconocido o inesperado, bajo ciertas condiciones, se escapen 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 monitoreo) 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 hallar 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 muy 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 que utilizan este modelo, en su debida oportunidad publicamos un artículo sobre Zabbix (aunque en realidad es una comparativa podremos ver su funcionamiento en detalle); 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 «está lento el sistema»
Si bien ya tenemos bien 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 está lento».
Así, sin más, eso es lo que reportan y debemos tener más paciencia que un santo: de nuestros usuarios, ya sean empleados o clientes (estos últimos no tendrán vergüenza alguna en quejarse, con o sin razón) 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 usuarios clientes de la empresa… bueno, con ellos no podremos ni hablar, solo confiar en el departamento de atención al cliente de cada empresa. 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 instalarlo en máquinas virtuales con autoarranque y autoregistro de usuario para instalarle el PDR y la sonda, grabamos las acciones, guardamos 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. Un vídeo explicativo, breve y sencillo lo podréis hallar en el sitio web Youtube con el siguiente código: «jaNnpNLKIXY» .
Las posibilidades de esta monitorización incluyen el 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
Pues bien, esto último que vimos no es más que 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 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 tal como explicamos arriba.
Se llama modelo de Caja Cerrada porque desconocemos como 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á cuál o cuales procesos son críticos para él o ella y que nosotros procederemos a analizar y monitorizar en busca de deterioro (o tal vez mejora) en el performance 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 por un costo razonable: 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. Osea, monitorizamos incluso antes de que comience la etapa de producción, una especie de usuario beta pero con herramientas muy especializadas.
Siguiendo con el ejemplo último, tal vez nuestro cliente se interese en averiguar dónde ocurre o qué causa el problema, respuesta que no podremos darle porque 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 con su flexibilidad.
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
El legendario 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 retos que se presentan, cada empresa tiene sus particularidades pero no por ello significa que no estemos preparados en lo 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 posible mejoras al desempeño.
Otro caso nuevo, particular y escabroso es la monitorización en la nube donde aplicaremos mucho el modelo de Caja Cerrada con un poco del modelo de Caja Abierta, tan poco que para muchos tal vez les será imperceptible, pero está allí, pequeñita (si os decidís a saber más seguid el enlace al artículo, no tiene desperdicio).
Conclusiones
Hemos abarcado al menos un 80% de la materia de la monitorización de una forma amena y resumida, de acá podéis agregar nuestro artículo a vuestros favoritos web para que vayáis a vuestro propio ritmo leyendo -y descubriendo- en varios días y entrada por entrada el por qué 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!
Finalizamos contándoles que en Pandora FMS no dejamos cabos sueltos: la monitorización unificada es un objetivo bien estudiado. ¡Hasta la próxima oportunidad, feliz día!