Cómo simplificar la arquitectura de monitorización en entornos complejos

En tecnología perseguimos sin parar el brillo de lo nuevo. Nos hipnotiza ese framework recién lanzado, otra arquitectura más que acaba de salir, las promesas del enésimo servicio de nube o capas adicionales de abstracción… Y de complicación. Lo cual es un problema, porque la eficiencia de una infraestructura no depende solamente de su poder bruto, sino, sobre todo, de la elegancia de su arquitectura interna.
Una que, cuantas más piezas móviles tiene, más puntos de ruptura posee. Eso hace que también necesitemos una monitorización de sistemas TI compleja, llena de excepciones y matices para controlar bien a la bestia que hemos creado, porque está plagada de parches, recovecos y reformas extrañas que ningún arquitecto hubiera aprobado.
Todo un problema cuando algo se rompe en un rincón oscuro que la monitorización apenas ilumina, o un actor malicioso se hace con una vieja impresora que no sabíamos ni que existía.
En monitorización también cometemos el error de mirar solo hacia fuera.
Nos obsesionamos con la complejidad de la red que vigilamos, la dispersión de aplicaciones cloud o la heterogeneidad de nuestros dispositivos. Pero rara vez nos detenemos a mirar hacia dentro, a la propia plataforma que sostiene esa visibilidad.
Pero cuando esa arquitectura de monitorización también se vuelve un laberinto, su complejidad operativa devora el valor que aportaba la herramienta.
La monitorización vino a salvarnos y, como dijo Obi Wan a Anakin, se acaba convirtiendo en lo que juró que destruiría.
En otra carga complicada más y no un alivio del peso.
Por eso, vamos a detallar cómo simplificar esa arquitectura de monitorización, apoyándonos en las múltiples innovaciones que aporta Pandora FMS 800 LTS Aquarius en este sentido.

El problema: cuando la propia plataforma de monitorización se vuelve difícil de operar

A medida que una organización escala, su herramienta de monitorización también suele hacerlo por acumulación, no por diseño.
Se añaden servidores para tareas específicas, se crean hilos dedicados para protocolos minoritarios y se fragmenta la lógica de procesamiento para «no saturar» el núcleo.
Como he empezado con Star Wars, voy a seguir por ahí y dejar claro que: «Es una trampa», como diría el almirante Ackbar, porque el resultado es un monstruo de Frankenstein operativo que ya he comentado a menudo en otras ocasiones.
Si nuestra plataforma de monitorización requiere un equipo de tres personas dedicado exclusivamente a mantenerla viva, actualizarla o equilibrar cargas internas, hemos perdido el norte más que los Stark.
La arquitectura de monitorización importa mucho porque:

• Condiciona directamente el coste de propiedad (TCO).
• Influye en la agilidad de los equipos de Site Reliability Engineering (SRE).
• Determina la capacidad de respuesta ante crisis.

Una herramienta compleja de operar es, por definición, una herramienta frágil.

Qué síntomas indican que la arquitectura de monitorización empieza a ser un problema

Como en cualquier patología técnica, el agotamiento arquitectónico presenta síntomas claros previos al colapso total.
Los principales son:

• Demasiados procesos dedicados: Si para monitorizar WMI necesitamos un binario, para SNMP debemos instalar otro y para chequeos web un tercero (cada uno con su propia configuración y ciclo de vida, por supuesto) estamos multiplicando los puntos de fallo.
• Recursos infrautilizados: Como por ejemplo, procesos que consumen memoria y ciclos de CPU simplemente por estar «en espera» de una tarea que solo ocurre una vez cada diez minutos.
• Dependencias rígidas: Causadas por componentes que no pueden actualizarse de forma independiente. O que requieren que toda la plataforma se detenga para realizar un cambio menor, porque hay que descargar otra versión de no sé qué librería que también influye en otro programa y a lo mejor lo rompe.
• Crecimiento que obliga a sobredimensionar: La incapacidad de la arquitectura para aprovechar los hilos de procesamiento modernos obliga a desplegar más máquinas virtuales de las necesarias.
• Mantenimiento costoso: Porque al final, el tiempo que el equipo técnico dedica a «cuidar» la herramienta de monitorización supera al tiempo dedicado a analizar los datos que esta proporciona.

Por qué agrupar tareas similares mejora el uso real de recursos

La tendencia de diseño de software debería ser consolidación inteligente en lugar de fragmentación infinita. A pesar de lo que diga ese dev que nunca se calla en las reuniones, no todo necesita un proceso aislado.
De hecho, en entornos de monitorización de infraestructura a gran escala, agrupar tareas por su naturaleza de carga resulta infinitamente más eficiente.
La lógica es sencilla:
Si, por ejemplo, agrupamos los chequeos que dependen de la latencia de red en un rol y los que dependen de la capacidad de computación en otro, podemos optimizar el uso de hilos (threading) de forma mucho más agresiva.
Eso redunda en menos sobrecoste operativo por el cambio de contexto del procesador y también en una gestión de memoria más limpia.
Esta es una muestra de cómo una arquitectura más manejable no es la que tiene menos funciones, sino la que las organiza con más racionalidad.

Qué cambia en Pandora FMS con la nueva arquitectura de servidores

Como predicar está bien, pero hacer es mucho mejor, con la llegada de la versión 800 LTS Aquarius, Pandora FMS hemos ejecutado una cirugía a corazón abierto en su arquitectura de servidores.
Y la idea que guio ese cambio era clara: simplificar para escalar.
Por eso, se han eliminado servidores dedicados que antes operaban de forma independiente, redistribuyendo y absorbiendo ahora sus funciones en servidores más potentes y versátiles.
La mayor ventaja de este cambio es no requerir de servidores e hilos dedicados para grupos de monitorización que podían ser minoritarios.
Esta reorganización reduce drásticamente la huella operativa y permite que el sistema se adapte mejor a las máquinas modernas multinúcleo, donde el trabajo en paralelo es la clave del éxito.
Veamos más a fondo esta estructura simplificada.

Qué aporta el nuevo reparto entre Network Server, Network High Performance Server y Heavy Server

Esta es la santísima trinidad operativa que define la nueva era de la plataforma Pandora FMS y, como quien entiende el «porqué» aplica mucho mejor el «cómo», analicemos cómo simplifica la gestión diaria:

• Network Server: Consolida procesos y tareas, convirtiéndolo en el pulmón de la monitorización remota. Ahora no solo asume los chequeos de red habituales y la ejecución de scripts remotos, sino también la monitorización WMI, la experiencia de usuario web y las capacidades de predicción. Es un servidor orientado a la versatilidad y a la respuesta inteligente.
• Network High Performance Server: Sé que el nombre suena un poco a marketing, pero todo lo contrario. Este especialista está diseñado para una sola cosa: funcionar a velocidad de curvatura en el polling de red. Así, se encarga de los sondeos ICMP y SNMP numéricos con una eficiencia que permite intervalos de chequeo impensables hasta ahora en arquitecturas centralizadas.
• Heavy Server: Cuyo nombre delata que es el peso pesado en esta pelea, el encargado del trabajo sucio y de las tareas que requieren procesar grandes volúmenes de datos o integraciones complejas. Aquí residen los plugins, el inventario, la gestión de vulnerabilidades, el NCM (Network Configuration Management) y la exportación de datos.

El reparto del peso de nuestra infraestructura IT entre estas tres poderosas columnas principales permite que, si por ejemplo nuestro entorno crece en complejidad de inventario, pero no en número de nodos de red, solo precisamos escalar la capacidad del Heavy Server, sin tocar el resto de la infraestructura de monitorización.
Modular, especializado, simple y elegante.

Qué cambia cuando ya no necesitas procesos dedicados para casos minoritarios

Uno de los mayores dolores de cabeza de los administradores era el «peaje» de las cargas minoritarias.
Antes, si teníamos un puñado de servidores Windows que requerían monitorización WMI, la arquitectura obligaba a desplegar un servidor específico para esa tarea… Con su correspondiente consumo de recursos y configuración dedicada.
Ahora, sin embargo, esas funciones se han integrado en el Network Server dentro de Pandora FMS 800 LTS.
El beneficio es inmediato:

• Menos piezas que vigilar (y menos puntos de fallo).
• Menos procesos que monitorizar.
• Una configuración unificada que permite la cuadratura del círculo: El hecho de que utilizar tecnologías muy diferentes (algo inevitable hoy en una infraestructura IT) no venga con el castigo de la complejidad (algo evitable hoy con Pandora FMS 800 LTS Aquarius).

Polling más corto y entornos distribuidos: Por qué no es solo una mejora de rendimiento

En la monitorización moderna, el dato tiene una fecha de caducidad cada vez más corta, con lo que su frescura es esencial.
¿De qué sirve darse cuenta de que un enlace cayó hace quince minutos cuando lo necesitábamos saber a los quince segundos?
La nueva arquitectura de Pandora FMS permite precisamente eso: un polling de red con intervalos de hasta 15 segundos ejecutado desde servidores centralizados.
Esto transforma la percepción de la plataforma en entornos complejos y distribuidos. Al permitir un sondeo tan frecuente, la visibilidad se vuelve casi instantánea, algo fundamental para equipos que operan en un Network Operations Center (NOC) de alto nivel.
Además, la flexibilidad en el reequilibrado de cargas entre servidores en los chequeos remotos, así como las mejoras en la alta disponibilidad (HA) aseguran que esa visibilidad no se pierda nunca, por muy hostil que sea el entorno.

Pandora_supervisor y la simplificación operativa de las actualizaciones

Si preguntas a mil administradores senior cuál es su momento favorito de la semana, vete a saber lo que responderán, porque nadie sabe qué hay en esas cabezas. Pero a lo que puedo apostar es a que ninguno dirá que el momento de las actualizaciones.
Tensión y sudor frío, eso es lo que significa actualizar en el diccionario IT y, en entornos críticos, detener los servicios de monitorización es quedarse a ciegas.
Aquí entra a jugar pandora_supervisor.
Este nuevo componente actúa como el director de orquesta de la plataforma, encargándose de que los reinicios sean mínimos y las actualizaciones lo más transparentes posible.
Menos intervención manual también significa menos errores humanos y una mayor continuidad del servicio en procesos como estos. Dicho de otro modo, pandora_supervisor es el equivalente a reparar los motores de la Enterprise mientras sigue navegando a velocidad de impulso.
Este punto es crítico para otro aspecto clave, qué tener en cuenta antes de actualizar una plataforma de monitorización crítica.
Porque la mantenibilidad no es una opción, es un requisito de supervivencia.

Qué debe exigirse a una plataforma de monitorización realmente escalable

Hay cinco mandamientos clave que debe cumplir una arquitectura de monitorización escalable y simplificada, bajo castigo de volverse ingobernable y opaca:

• Eficiencia real de recursos: Como por ejemplo, no desperdiciando ciclos de CPU en procesos ociosos o redundantes.
• Menos rigidez: Poseyendo una capacidad de adaptarse a diferentes perfiles de carga sin rediseñar todo el entorno.
• Menos componentes obligatorios: Si algo es opcional, no debería ser una carga para el núcleo del sistema.
• Capacidad de crecer sin multiplicar la complejidad: Doblar el número de dispositivos monitorizados no debería significar doblar el tiempo dedicado a mantener la herramienta, el escalado debería ser una característica fundamental en la herramienta.
• Mantenibilidad: De modo que actualizar o ampliar el sistema sea una tarea rutinaria, que no precise sacrificios ni rezos previos a los dioses de la máquina.

Qué aporta Pandora FMS en este enfoque

Básicamente, predicar con el ejemplo y traer a tierra todas esas buenas prácticas que hemos comentado a lo largo de todo el texto.
Pandora FMS ha ido mucho más allá de un cambio de nombre de servidores, ha transformado su filosofía de operación para ofrecer un Single Pane of Glass real y sostenible, a través de:

• Una arquitectura actual más racional y adaptada a la realidad de los centros de datos modernos. Eso permite acomodarla a cualquier tipo de entorno, por muy complejo y distribuido que sea.
• Una mejor distribución de tareas, aumentando la eficiencia.
• Una simplificación de la operativa interna. La cual libera a los técnicos de las tareas de bajo valor (mantener la herramienta) para que puedan centrarse en las de alto valor (analizar la telemetría y gestión de infraestructuras).
• Una base mucho más sólida para el futuro de la plataforma, permitiendo mejoras y ampliaciones de capacidades de una manera más robusta.

Aunque nunca llegue a ver un solo proceso corriendo en el servidor, al cliente le importa la arquitectura interna de una plataforma de monitorización, porque condiciona:

• Cuánto cuesta operarla.
• Cuánto escala fácilmente y con ganancia real.
• Cuánta fricción introduce en el día a día de sus equipos técnicos.

En tecnología vivimos demasiado atrapados por el hechizo de la complejidad, confundiéndola con potencia o eficacia, pero el camino correcto va en dirección contraria. La simplicidad es la base de la elegancia, eliminar lo innecesario para que lo esencial brille con más fuerza.
Y en entornos complejos, esa simplicidad arquitectónica es la máxima expresión de la sofisticación tecnológica.
Hace mucho, uno de mis mejores maestros de escritura dijo una frase que se me quedó y me guía desde entonces, y no solo para dicha escritura:
«Cualquiera puede enrollarse, pero decir lo que deseas con las mínimas palabras exactas, y ni una más, es la marca del maestro».
Lo mismo se puede aplicar a la gestión de infraestructuras IT y todos sus componentes, incluyendo la monitorización. Porque al final del día, el objetivo es dormir tranquilo sabiendo que, si algo sucede, nuestro sistema de control será el primero en verlo y no una parte más del problema.