Business Intelligence (BI)

Antes de empezar paso a paso con la aplicación práctica de BI, primero tendrás que conocer algunos términos:

Cada aplicación formalizada con BI se denomina agregación BI, ya que se agrega un estado general a partir de muchos estados individuales.

Una agregación se construye como un «árbol» de objetos. Estos objetos se llaman nodos. Los nodos finales —las hojas del árbol— son los hosts y los servicios de tus sitios de Checkmk. Los nodos restantes son objetos de BI creados artificialmente.

Cada nodo se crea mediante una regla. Esto también se aplica a las raíces del árbol —el nodo de nivel superior—. Estas reglas determinan qué nodos están conectados a otro nodo y cómo se debe determinar el estado de los nodos superiores a partir de sus estados.

El nodo superior de una agregación —la raíz del árbol— también se genera mediante una regla. De esta forma, una regla puede generar múltiples agregaciones.

La forma más fácil de entender esto es con un ejemplo concreto. Hemos creado la aplicación Mystery específicamente como demostración para este artículo. Supongamos que se trata de una aplicación importante en una organización no especificada. Entre otras cosas, cinco servidores y dos switches desempeñan un papel importante. Para que puedas entender mejor nuestro ejemplo, usaremos nombres sencillos como srv-mys-1 o switch-1. El siguiente diagrama ofrece una vista general sencilla de la estructura:

Si quieres seguir los siguientes pasos uno por uno, simplemente puedes replicar los objetos de monitorización tal y como se muestra en nuestro ejemplo. Para una prueba, basta con que clones varias veces un host existente y les pongas nombre a los clones como corresponda. Más adelante habrá que añadir algunos servicios al juego, para lo cual tendrás tiempo de añadir los hosts pertinentes a la monitorización. Incluso ahí puedes volver a hacer trampa: con simples local checks conseguirás rápidamente servicios que coincidan con los que quieres probar.

Los hosts se verán entonces más o menos así en la monitorización:

Empieza con algo sencillo —con la agregación significativa más simple posible—: una agregación con solo dos nodos. A continuación, querrás resumir los estados de los hosts switch-1 y switch-2. La agregación debería llamarse «Network» y debería estar en «OK» cuando ambos switches estén disponibles. En caso de un fallo parcial, el estado debería pasar a «WARN», y si ambos switches están apagados, a «CRIT».

Para empezar: configura BI a través de Setup > Business Intelligence > Business Intelligence. La configuración de las reglas y las agregaciones se realiza dentro de los paquetes de configuración: los paquetes BI. Estos paquetes no solo son prácticos porque te permiten gestionar mejor configuraciones más complejas, sino que también puedes aplicar permisos a un paquete y asignar ciertos grupos de contactos, e incluso permitir a usuarios sin derechos de administrador editar partes de la configuración. Pero hablaremos más de eso más adelante…​

La primera vez que accedas al módulo BI debería verse algo así:

Ya existe un paquete titulado «Default Pack». Este contiene una demostración de una agregación que resume los datos de un host individual.

Para este ejemplo, lo mejor es crear un nuevo paquete —con el botón «Add BI Pack»— al que llamarás «Mystery». Como siempre en Checkmk, especifica un ID interno (mystery) que no se puede cambiar más adelante, y un título descriptivo. La opción «Public» es necesaria para otros usuarios si hay reglas en este paquete que quieran usar para sus propias reglas o agregaciones. Como probablemente quieras hacer tus experimentos a solas y en paz, deja esta opción desactivada:

Tras la creación, encontrarás, por supuesto, dos paquetes en la lista principal:

Junto a cada entrada hay un icono () para realizar la edición de las propiedades, y un icono para abrir el contenido real del paquete (), que es donde quieres ir ahora. Una vez allí, crea tu primera regla directamente a través de Add rule.

Como siempre en Checkmk, esta regla también necesita tener un ID único y un título. El título de la regla no solo tiene una función de documentación, sino que más adelante también será visible como el nombre del nodo que creará esta regla:

El siguiente cuadro se llama «Child Node Generation» y es el más importante. Aquí especificas qué objetos de este nodo deben resumirse. Pueden ser otros nodos de BI —para los que elegirías una regla BI diferente— u objetos sujetos a la monitorización, es decir, hosts o servicios.

Para el primer ejemplo, selecciona la segunda variante (State of a host) y crea dos objetos como hijos, concretamente los dos hosts switch-1 y switch-2. Esto se hace con el botón «Add child node generator». Aquí, naturalmente, eliges «State of a host» e introduces un nombre para cada host:

En la tercera y última caja, Aggregation Function, especificas cómo se debe calcular el estado de monitorización del nodo. La base para ello es siempre la lista de estados de los subnodos. Hay varios enlaces lógicos posibles.

La opción preseleccionada es Best — take the best of all node states. Eso significaría que el nodo pasa a ser CRIT cuando todos los subnodos son CRIT o DOWN. Como se ha mencionado anteriormente, este no debería ser el caso aquí. Elige en su lugar Count the number of nodes in state OK para tomar como referencia el número de subnodos con el estado OK. Aquí se sugieren los números 2 y 1 como umbrales. Esto es genial porque es exactamente lo que necesitas:

Así es como se verá el formulario una vez completado:

Con un clic en «Create» tendrás tu primera regla:

Nota: es importante entender que una regla aún no es una agregación. Checkmk aún no puede saber si esto es todo o solo parte de un árbol más grande. Los objetos BI reales solo se crearán y serán visibles en la interfaz de estado cuando crees una agregación. Para ello, switch a la lista de agregaciones «».

El botón «» te lleva a un formulario para crear una nueva agregación. Aquí hay poco que rellenar. En el campo «Aggregation groups» puedes especificar cualquier nombre que elijas. Estos nombres aparecerán luego en la interfaz de estado como grupos, bajo los cuales se harán visibles todas aquellas agregaciones que compartan este nombre de grupo. En realidad, se trata del mismo concepto que con los hashtags o las palabras clave. También puedes asignar libremente el «Aggregation ID» como de costumbre, pero no podrás cambiarlo más adelante.

Defines el contenido de la agregación a través de Add new element. Selecciona la configuración Call a rule y, en Rule:, la regla que acabas de crear (y antes del paquete de reglas en el que se encuentra).

Si ahora guardas la agregación con «», ¡ya está! Tu primera agregación debería aparecer ahora en la interfaz de estado, siempre y cuando tengas al menos uno de los hosts, switch-1 o switch-2.

Si has hecho todo correctamente, ahora podrás ver tu primera agregación en la interfaz de estado. La forma más fácil de hacerlo es a través de Monitor > Business Intelligence > All Aggregations:

Echa un vistazo más de cerca al aspecto del árbol de BI. El siguiente ejemplo muestra tu miniagregación en una situación en la que uno de los dos switches es DOWN y el otro UP. Tal y como deseabas, la agregación entra en el estado WARN:

También puedes ver que, para estandarizar los hosts y los servicios, el host que es DOWN se trata casi como un servicio que es CRIT. Del mismo modo, UP se convierte en OK.

Las hojas del árbol muestran los estados de los hosts y los servicios. El nombre del host —y, en el caso de los servicios, también el nombre del servicio— es clicable y te lleva al estado actual del objeto correspondiente. Además, también puedes ver el último resultado del check plugin.

A la izquierda de cada agregación encontrarás dos iconos: y . Con el primer icono —— accedes a una página que muestra solo esa única agregación. Esto resulta útil, naturalmente, sobre todo si has creado más de una agregación. Esto es, por ejemplo, muy adecuado como marcador. te llevará al cálculo de la disponibilidad. Más sobre esto más adelante.

A la izquierda del nombre del host encontrarás un icono interesante: . Esto permite realizar un análisis de «¿y si…?» La idea es sencilla: al hacer clic en el icono, el objeto switchará a otro estado a modo de prueba —aunque solo para la interfaz de BI—, ¡no en la realidad! Varios clics te llevarán de (OK) pasando por (WARN), (CRIT) y (UNKNOWN) de vuelta a .

A continuación, BI construye el árbol completo basándose en el estado supuesto. El siguiente gráfico muestra la agregación mínima bajo la suposición de que, además de switch-1, que realmente ha fallado, switch-2 también sería DOWN:

El estado general de la agregación pasa así de WARN a CRIT. Al mismo tiempo, el color del estado viene acompañado de un patrón de cuadros. Este patrón te indica que el estado real es, en realidad, diferente. Esto no siempre es así, porque algunos cambios en un host o servicio ya no son relevantes para la condición general; por ejemplo, si el en cuestión ya está CRIT.

Puedes usar este análisis de «¿y si...?» de varias maneras, por ejemplo:

En este último caso, como prueba, configuras el dispositivo que se va a reparar o sus servicios como «». Si entonces toda la agregación sigue siendo «OK», eso significa que, en ese momento, la redundancia puede compensar el fallo.

Hay otra forma de probar las agregaciones BI: cambiando directamente el estado real de un objeto. Esto resulta especialmente práctico en un sistema de pruebas.

Para ello, los comandos cuentan con un comando de host/servicio llamado Fake check results. Por defecto, solo está disponible para el rol de Administrador. Este método se ha utilizado, por ejemplo, para crear las capturas de pantalla de este artículo, en las que switch-1 se ha establecido en DOWN. De ahí viene el texto revelador «Manually set to Down by cmkadmin».

Aquí tienes un pequeño consejo útil: Si trabajas con este método, es mejor desactivar las comprobaciones activas de los hosts y servicios relevantes, de lo contrario, en el siguiente intervalo de comprobación volverán inmediatamente a su estado real. Si eres un poco vago, hazlo a nivel global a través del snap-in «Master Control». Pero... ¡no te olvides nunca de volver a activarlo después!

Al crear la agregación, abordamos brevemente las posibilidades disponibles para la entrada «Aggregation Groups». En el ejemplo, simplemente confirmaste el nombre sugerido «Main» aquí. Por supuesto, tienes total libertad a la hora de asignar nombres, y también puedes asignar una agregación a varios grupos.

Los grupos cobran importancia cuando el número de agregaciones supera lo que quieres mostrar en una pantalla. Accedes a un grupo haciendo clic en uno de los nombres de grupo que aparecen en la página «All aggregations»; en nuestro ejemplo anterior, simplemente en el encabezado «Main». Por supuesto, si hasta ahora solo tienes esta única agregación, no cambiará gran cosa. Sin embargo, si te fijas bien, te darás cuenta de que:

Si quieres visitar esta vista de tabla más a menudo, simplemente añádela a tus favoritos, preferiblemente con el elemento «Bookmarks» en la barra lateral.

Una vez que hayas configurado las agregaciones BI, en el menú de contexto de tus hosts y servicios encontrarás un nuevo icono de «»:

Este icono te lleva a la lista de todas las agregaciones en las que se incluye el host o servicio en cuestión.

Ahora que tienes un árbol un poco más interesante, puedes acercarte un poco más a las diversas opciones de visualización que ofrece Checkmk. El punto de partida para ello son las «Modify display options», a las que puedes acceder a través del menú «Display». Esto abre una caja con varias opciones. El contenido de la caja siempre se ajusta a los elementos que se muestran en la página. En el caso de BI, actualmente puedes encontrar cuatro opciones:

Por último, puedes establecer un intervalo de actualización (Refresh interval) de 30, 60 o 90 segundos y especificar el número de columnas mediante Entries per row.

Además de las representaciones tabulares, Checkmk también domina la visualización de agregaciones BI. Puedes ver las agregaciones desde una nueva perspectiva y, a veces, con mayor claridad. Encontrarás el BI Visualization a través de en la vista de tabla habitual.

Puedes mover el árbol libremente haciendo clic en el fondo y ajustar el tamaño de toda la pantalla con la rueda del ratón. En cuanto pasas el puntero del ratón por encima de un nodo concreto, aparece una ventana emergente con la información de estado asociada a ese nodo. Usa la rueda del ratón para ajustar la longitud de las ramas del árbol.

Al hacer clic en los nodos hoja, accederás directamente a las vistas detalladas del host o del servicio. Al hacer clic con el botón derecho en los demás nodos —dependiendo del tipo de nodo— podrás acceder a las opciones de visualización y, por ejemplo, a la propia regla responsable —Edit rule, en la imagen de abajo.

Continuemos con la configuración. Ahora es el momento de ponernos manos a la obra de verdad. Hasta ahora, el ejemplo ha sido tan sencillo que ha sido posible enumerar individualmente todos los objetos de la agregación BI sin dificultad. Pero, ¿y si las cosas se complican? ¿Y si quieres formular muchas dependencias recurrentes que son iguales o similares? ¿Y si una aplicación incluye no uno, sino varios sites? ¿Y si quisieras agrupar cientos de servicios individuales de una base de datos en un solo nodo de BI?

Para este tipo de requisitos necesitarás métodos de configuración más potentes. Y esto es precisamente lo que distingue a Checkmk BI de otras herramientas —y, por desgracia, aquí la curva de aprendizaje es un poco más pronunciada. También es la razón por la que Checkmk BI no permite configurarse mediante «arrastrar y soltar». Sin embargo, una vez que conozcas las posibilidades, seguro que no querrás prescindir de ellas.

Empecemos por los parámetros. Imagina la siguiente situación: no solo quieres saber si los dos switches están UP, sino que también quieres conocer el estado de los dos puertos responsables del enlace ascendente. En términos generales, esto depende de los siguientes cuatro servicios:

Ahora, el nodo Switch 1 & 2 debería ampliarse para sustituir los dos estados de host de los switches 1 y 2, de modo que cada uno tenga un subnodo que muestre el estado del host y las dos interfaces de enlace ascendente. Estos dos subnodos deberían ser Switch 1 o Switch 2.

De hecho, ahora necesitarás dos reglas nuevas: una para cada switch. Es mejor hacerlo creando una nueva regla switch y dotándola de un parámetro. Este parámetro es una variable que invocas cuando llamas a la regla desde el nodo padre —que aquí puede ser proporcionada por la antigua regla Switch 1 & 2. En este ejemplo, puedes simplemente pasar un 1 o un 2. El parámetro recibe un nombre que puedes elegir libremente. Toma aquí, por ejemplo, el nombre NUMBER. El uso de mayúsculas aquí es puramente arbitrario, y si te parecen más bonitas las minúsculas, también eres libre de usarlas.

El título de la regla quedará así:

Puedes elegir switch como ID para la nueva regla. En Parameters, simplemente introduce el nombre de la variable: NUMBER. Ahora también es importante que la variable se utilice en el Rule Title de la regla, para que ambos nodos no se llamen simplemente switch y, por lo tanto, tengan el mismo nombre. Al utilizar la variable, se añade un signo de dólar al principio y al final, como es habitual en muchos lugares de Checkmk. Como resultado, los dos nodos se llamarán Switch 1 y Switch 2.

Vale la pena volver a examinar más de cerca el tema de las expresiones regulares. Al hacer coincidir el nombre del servicio, al principio dimos por sentado tácitamente que básicamente solo se trata de expresiones regulares. Como acabamos de mencionar, hay una concordancia de prefijo.

Así que en un nodo BI, si por ejemplo, en el nombre del servicio especificas disk, se capturarán todos los servicios del host en cuestión que empiecen por Disk.

En general, se aplican los siguientes principios:

Quizá esto te parezca un poco atrevido al principio, porque ¿no es arriesgado omitir sin más, sin comentarios, items que deberían estar presentes?

Bueno, con el tiempo te darás cuenta de lo práctico que es este concepto, porque te permitirá escribir reglas «inteligentes» que puedan reaccionar ante situaciones muy diferentes. ¿Hay algún servicio que no exista en todos los sites de una aplicación? No hay problema: solo se tendrá en cuenta si está ahí. ¿O se pueden eliminar temporalmente hosts o servicios de la monitorización? En ese caso, simplemente desaparecerán de BI sin provocar errores ni nada por el estilo. ¡BI no está ahí para comprobar si tu configuración de monitorización está completa!

Por cierto, este principio también se aplica a los servicios definidos explícitamente, ya que estos en realidad no existen porque los nombres de los servicios siempre se consideran expresiones regulares, incluso si no contienen caracteres especiales como .*. Siempre es automáticamente un patrón de búsqueda.

Pero aún puedes automatizar más y, sobre todo, reaccionar con flexibilidad ante los cambios. Continúa con el ejemplo de los dos servidores de aplicaciones srv-mys-1 y srv-mys-2 del ejemplo. Tu árbol debería seguir creciendo. El nodo Infrastructure debería pasar al nivel 2. Y como raíz definitiva, debería haber una regla con el título The Mystery Application bajo la cual se agrupará todo. Junto a Infrastructure debería haber un nodo llamado Mystery Servers. Se supone que los (actualmente) dos servidores misteriosos deben agruparse bajo este nodo. En cada uno de ellos se incluyen algunos servicios genéricos en la agregación. El resultado debería verse así:

Al igual que en la búsqueda de host, también hay un tipo de generador secundario llamado Create nodes based on a service search. Aquí tienes un ejemplo:

Puedes usar () aquí —encerrando expresiones parciales entre paréntesis— tanto en el host como en el servicio, donde:

Y no olvides que siempre puedes usar para obtener ayuda en línea.

En tus intentos, es posible que te hayas topado con el generador secundario State of remaining services. Este genera un nodo para cualquiera de los servicios de tu host que aún no se hayan clasificado en tu Agregación BI. Esto resulta útil si utilizas BI para combinar los estados de todos los servicios de un host en grupos claramente organizados, tal y como se hace en nuestro ejemplo incluido.

Volvamos de nuevo a los paquetes de reglas. Para todas las acciones de edición en BI, normalmente necesitas tener el rol de administrador. Más concretamente, para BI hay dos permisos, que se encuentran en Setup > Users > Roles & permissions:

En el rol de usuario de monitorización normal, solo el primero de los dos permisos está activo por defecto. Por lo tanto, los usuarios de monitorización normales solo pueden trabajar en aquellos paquetes de reglas para los que hayan sido definidos como contacto. Esto se configura en Detalles del paquete de reglas.

En el siguiente ejemplo de Permitted Contact Groups, se ha autorizado al grupo de contacto The Mystery Admins; por lo tanto, todos los miembros de este grupo pueden ahora editar las reglas de este paquete:

Por cierto, con Public > Allow all users to refer to rules contained in this pack puedes permitir que otros usuarios al menos utilicen las reglas que contiene —es decir, que definan (en otro lugar) sus propias reglas—, las cuales pueden invocar estas reglas como subnodos.

¿Cuál es la situación con respecto a la visibilidad real de las agregaciones en la interfaz de estado? ¿Qué contactos pueden ver algo?

Bueno, no puedes asignar ningún permiso en las propias agregaciones BI. Esto se realiza indirectamente a través de la visibilidad de los hosts y servicios, y se rige por la opción «See all hosts and services» en «Setup > Roles & Permissions:»

En el rol «User», este permiso está desactivado por defecto. Los usuarios normales solo pueden ver los hosts y servicios compartidos, y en BI esto se traduce en que pueden ver exactamente todas las Agregaciones BI que contengan al menos un host o servicio compartido. Sin embargo, estas Agregaciones BI solo contienen estos objetos autorizados, por lo que pueden resultar algo «pobres». Y esto, a su vez, significa que pueden tener estados diferentes para distintos usuarios.

Que eso sea bueno o malo depende de lo que quieras. Si tienes dudas, puedes activar o desactivar el permiso y, dando un rodeo por BI, permitir que algunos o todos los usuarios vean hosts y servicios para los que no son contactos —y así asegurarte de que el estado de una agregación sea siempre el mismo para todos.

Por supuesto, todo este tema solo importa si hay, de hecho, agregaciones que están tan mezcladas que solo algunos usuarios son contactos para partes específicas de la misma.

¿Cómo gestiona realmente BI el tiempo de mantenimiento programado de un? Hemos reflexionado mucho sobre este tema y lo hemos discutido con muchos usuarios; el resultado es el siguiente:

Para entender con qué regla BI calcula el estado «en tiempo de mantenimiento», te ayudará recordar cuál es la idea real detrás de los tiempos de mantenimiento programados: se está trabajando actualmente en el objeto en cuestión. Es de esperar que se produzcan fallos. Aunque el objeto esté actualmente «OK», no debes confiar en él. Puede pasar a estar «CRIT» en cualquier momento. Esto es algo conocido y documentado, por lo que no debería activar una notificación.

Esta idea se puede trasladar tal cual a BI: En la agregación BI puede haber algunos hosts y servicios que estén actualmente en tiempo de mantenimiento. Que estos estén simplemente «OK» o «CRIT» no importa, porque en realidad es una coincidencia si durante el trabajo de mantenimiento los objetos se apagan y vuelven a encenderse a veces, o no. El mero hecho de que haya un objeto «en tiempo de mantenimiento» en la agregación no significa inmediatamente que la aplicación que realiza el mapeo de la agregación esté «amenazada» y deba marcarse también como «en tiempo de mantenimiento». La aplicación también puede tener una redundancia instalada que compense el fallo de los objetos en «tiempo de mantenimiento». Solo si ese fallo llevara realmente a un estado de «CRIT» para la agregación —es decir, si no hay suficiente redundancia y la agregación está realmente en peligro—, solo entonces Checkmk la marcará como «en tiempo de mantenimiento». Aquí tampoco importa, por lo general, el estado actual de los objetos.

Para decirlo de forma más concisa, la regla exacta es la siguiente:

Si un estado «CRIT» de un host/servicio provocara un estado «CRIT» de la agregación, un estado «en tiempo de mantenimiento» de ese host/servicio provocará un estado «en tiempo de mantenimiento» para la agregación.

Importante: el estado real actual de los hosts/servicios no influye en el cálculo; en la lógica de BI se asume que lo que está «en tiempo de mantenimiento» es «CRIT». ¿Por qué? Porque un estado «UP» o «OK» durante un tiempo de mantenimiento programado es pura coincidencia, por ejemplo, si un host informa de «UP» durante unos segundos entre varios reinicios.

Y aquí tenemos otro ejemplo. Para ahorrar espacio, esta es una variante con un solo servidor misterioso en lugar de dos:

Primero, el host switch-1 está en tiempo de mantenimiento. Para el nodo Infrastructure esto no tiene ningún efecto, porque switch-2 no está en tiempo de mantenimiento, y por lo tanto Infrastructure tampoco está en tiempo de mantenimiento. Por lo tanto, no hay ningún icono de para tiempos de mantenimiento derivados.

Pero el servicio Memory en srv-mys-1 también está en tiempo de mantenimiento. Este no es redundante. Por lo tanto, el tiempo de mantenimiento se hereda del nodo padre Mystery Server 1, y luego continúa hasta Mystery Servers, y finalmente hasta el nodo superior The Mystery Application. Por lo tanto, este nodo superior también estará en tiempo de mantenimiento.

¿Hemos dicho antes que no puedes poner manualmente una Agregación BI en tiempo de mantenimiento programado? Eso solo es cierto a medias, ya que, de hecho, existe un comando para configurar tiempos de mantenimiento programados en las Agregaciones BI. Pero esto no hace más que registrar una entrada de tiempo de mantenimiento para cada host y servicio de la Agregación BI. Por supuesto, esto suele provocar que la propia Agregación BI se marque como en tiempo de mantenimiento, pero se trata solo de un procedimiento indirecto.

Como has visto anteriormente, el cálculo del tiempo de mantenimiento programado se basa en un estado «CRIT» (sin datos) supuesto. En las propiedades de una agregación puedes personalizar el algoritmo para que un nodo que asuma el estado «WARN» (sin datos) se marque como en tiempo de mantenimiento. La opción para esto se llama «Escalate downtimes based on aggregated WARN state»:

La suposición básica sigue siendo que los objetos en tiempo de mantenimiento están en estado «CRIT». La única diferencia radica en que, debido a la función de agregación, un «CRIT» puede convertirse en un «WARN», como ocurrió en nuestro primer ejemplo con «Count the number of nodes in state OK». En este caso, ya se habría aceptado un tiempo de mantenimiento programado si solo uno de los dos switches estuviera en tiempo de mantenimiento.

De forma muy similar al proceso con el tiempo de mantenimiento programado, si se ha reconocido un problema, la información también será calculada automáticamente por BI. En este caso, el estado de los objetos sin duda influye.

La idea aquí es trasladar el siguiente concepto a BI: Un objeto tiene un problema (WARN, CRIT), pero esto se sabe, y alguien está trabajando en ello ().

Puedes calcular esto para una agregación de la siguiente manera:

Sin embargo, si la agregación siguiera estando en estado «WARN» o «CRIT», entonces no se consideraría reconocida, porque en ese caso habría al menos un problema importante que no se ha realizado el Reconocimiento, y por lo tanto el estado «OK» se eliminaría de la agregación.

Por cierto, te ofrecerá un comando para que la Agregación BI reconozca sus problemas, pero esto solo significa que se reconocerán todos los hosts y servicios detectados en la Agregación BI (solo aquellos que actualmente tienen problemas).

Usar la función de congelación es muy sencillo: Activa la opción «New aggregations are frozen» en «Aggregation Properties».

Esto congelará la agregación cuando se guarde, y lo hará cada vez que se marque la checkmark; incluso si la agregación ya existía anteriormente (a pesar de la referencia a «New aggregations …​»). Para descongelar el estado congelado, desmarca la checkmark correspondiente.

En la monitorización, ahora verás un nuevo icono de copo de nieve de «» junto a la agregación. Esto te llevará a la vista de tabla que muestra las diferencias: A la izquierda, el árbol congelado; a la derecha, el árbol actual con los cambios resaltados (en este caso, la eliminación del servicio «backup3»):

Si quieres volver a congelar el estado actual, puedes hacerlo a través de Commands > Freeze aggregations. Pero ten cuidado: solo hay un estado actual congelado y no hay historial, incluidos los estados anteriores.