Business Intelligence (BI)

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

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

Una agregación se construye como un "árbol" de objetos. Estos objetos se llaman nodos. Los nodos inferiores -las hojas del árbol- son los host y los servicios de tus instancias de Checkmk. Los nodos restantes son objetos BI creados artificialmente.

Cada nodo se crea mediante una regla. Esto también se aplica a la raíz del árbol, el nodo superior. Estas reglas determinan qué nodos cuelgan debajo de otro nodo, y cómo a partir de sus estados debe determinarse el estado del nodo superior.

El nodo superior de una agregación -la raíz del árbol- también se genera con una regla. De este modo, una regla puede generar múltiples agregaciones.

La forma más fácil de entender esto es utilizar un ejemplo concreto. Para este artículo hemos ideado la "Aplicación Misteriosa ". Supongamos que se trata de una aplicación importante en una empresa no especificada. Entre otras cosas, desempeñan un papel importante cinco servidores y dos conmutadores de red. Para que puedas entender mejor el ejemplo, utilizamos nombres sencillos como srv-mys-1 o switch-1. El siguiente diagrama ofrece una visión general sencilla de la estructura:

Si quieres trabajar uno a uno los pasos siguientes, puedes simplemente replicar los objetos de monitorización como se muestra en nuestro ejemplo. Para hacer una prueba basta con que clones varias veces un host existente y des a los clones el nombre correspondiente. Más adelante habrá que añadir algunos servicios al juego, para lo que entonces tendrás tiempo de registrar los host correspondientes en la monitorización. Incluso ahí puedes volver a hacer trampas: con simplesdummy-local-checks obtendrás rápidamente servicios coincidentes con los que jugar.

Los hosts tendrán entonces este aspecto en la monitorización:

Empieza con algo sencillo, con la agregación significativa más simple posible: una agregación con sólo dos nodos. Entonces querrás resumir los estados de los host switch-1 y switch-2. La agregación se llamará Red y debería estar OKsi ambos conmutadores están disponibles. En caso de fallo parcial, debería pasar aWARN, y si ambos conmutadores están apagados, a CRIT.

Empezar: configurar BI a través de Setup > Business Intelligence > Business Intelligence.La configuración de las reglas y agregaciones se realiza dentro de los paquetes de configuración -los Paquetes BI-. Los paquetes no sólo son prácticos porque con ellos puedes gestionar mejor configuraciones más complejas: también puedes aplicar permisos a un paquete y asignar a determinados grupos de contacto -e incluso permitir a usuarios sin derechos de administrador- permisos para editar partes de la configuración. Pero de eso hablaremos más adelante...

La primera vez que llames al módulo BI debería ser algo parecido a esto:

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

Para este ejemplo es mejor crear un nuevo paquete -con el botón Add BI Pack - al que darás el nombre de Misterio. Como siempre en Checkmk, especifica un ID interno (mystery) que no se pueda cambiar más tarde, y un título descriptivo. La opción Public es necesaria para otros usuarios si hay reglas en este paquete que quieran utilizar para sus propias reglas o agregaciones. Como probablemente quieras hacer tus experimentos solo y en paz, deja esta opción desactivada:

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

Con cada entrada hay un símbolo para editar las propiedades (), y un símbolo para llegar al contenido real del Paquete (), que es donde quieres ir ahora. Una vez allí, crea tu primera regla de inmediato a través de Add rule.

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

La siguiente caja se llama Child Node Generation, y es la más importante. Aquí se especifica qué objetos de este nodo deben resumirse. Puede tratarse de otros nodos BI -para los que elegirías otra regla BI- o de objetos de monitorización, es decir, host o servicios.

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

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

El preseleccionado es Best — take best of all node states. Eso significaría que el nodo se convierte en CRIT cuando todos los subnodos están CRIT o DOWN. Como ya se ha dicho, esto no debería ser así en este caso. Elige en su lugarCount the number of nodes in state OK para obtener el número de subnodos con estadoOK como criterio. Aquí se sugieren los números 2 y 1 para los umbrales, lo cual es estupendo porque es exactamente lo que necesitas:

Este es el aspecto que tendrá la máscara rellenada:

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

Ahora es importante que entiendas que una regla aún no es una agregación. Checkmk aún no puede saber si esto es todo o sólo una parte de un árbol más grande. Los objetos BI reales sólo se crean y se hacen visibles en la interfaz de estado cuando creas una Agregación. Para ello, pasa a la lista de agregaciones.

El botón te lleva a una máscara para crear una nueva agregación. Aquí hay poco que rellenar. En Aggregation groups puedes especificar cualquier nombre de tu elección. Estos nombres aparecen entonces en la interfaz de estado como grupos, bajo los cuales se hacen visibles todas aquellas agregaciones que comparten este nombre de grupo. En realidad, se trata del mismo concepto que con los hashtags o las palabras clave.

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

Si ahora guardas la agregación con , ¡habrás terminado! Tu primera agregación debería aparecer ahora en la interfaz de estado - ¡suponiendo que de hecho también tengas al menos uno de los host 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 sencilla de hacerlo es a través de Monitor > Business Intelligence > All Aggregations:

Echa un vistazo más de cerca a la apariencia del árbol BI. El siguiente ejemplo muestra tu miniagregación en una situación en la que uno de los dos conmutadores estáDOWN y el otro UP. Como es de esperar, la agregación entra en estado WARN:

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

Las hojas del árbol muestran los estados de hosts y servicios. El nombre del host -y para 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 símbolos y . Con el primer icono - - llegas a una página que muestra sólo esa única agregación. Naturalmente, esto es útil sobre todo si has creado más de una agregación. Por ejemplo, es muy adecuado como marcador. te llevará al cálculo de la disponibilidad. Más adelante hablaremos de ello.

A la izquierda del nombre del host encontrarás un icono interesante: . Esto permite realizar un análisis del tipo "¿y si...? La idea es sencilla: al hacer clic en el icono, el objeto cambiará a otro estado a modo de prueba, aunque sólo para la interfaz de BI, ¡NO de verdad! Si haces varios clics, pasarás de (OK) a(WARN), (CRIT) y(UNKNOWN), y de vuelta a .

BI construye entonces el árbol completo basándose en el estado supuesto. La siguiente figura muestra la agregación mínima bajo el supuesto de que junto aswitch-1 que ha fallado realmente, ese switch-2 también estaría DOWN:

El estado global de la agregación pasa así de WARN a CRIT. Al mismo tiempo, el color del estado está respaldado por un patrón check. Este patrón te indica que el estado real es realmente distinto. 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 que está en cuestión ya es CRIT.

Puedes utilizar este análisis "¿y si...?" de varias formas, por ejemplo:

En este último caso, a modo de prueba, pon el aparato a reparar o sus servicios a . Si entonces toda la agregación sigue OK, debe significar que el fallo se puede compensar actualmente con redundancia.

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

Para ello, los comandostienen un comando host/servicio llamado Fake check results. Por defecto, sólo está disponible para el rol de Administrador. Este método se ha utilizado, por ejemplo, para la creación de las capturas de pantalla utilizadas en este artículo, en las que switch-1se ha configurado como DOWN. De aquí procede el texto reveladorManually set to Down by cmkadmin.

He aquí un pequeño consejo útil: Si trabajas con este método, lo mejor es desactivar los checks activos para los host y servicios relevantes, de lo contrario en el siguiente intervalo de check volverán inmediatamente a su estado actual. Si te da pereza, hazlo globalmente a través del elemento de la barra lateral Master Control. Eso sí: ¡nunca olvides volver a activarlo después!

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

Los grupos adquieren importancia cuando el número de agregaciones excede posiblemente lo que quieres ver 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 es simplemente en el encabezamiento Main. Por supuesto, si hasta ahora sólo tienes esta única agregación no cambiará mucho, pero si te fijas bien, te darás cuenta de ello:

Si quieres visitar esta vista más a menudo, sólo tienes que marcarla, preferiblemente con el elemento Bookmarks de la barra lateral.

Una vez que hayas configurado la Agregación BI, en el menú contextual de tus host y servicios encontrarás un nuevo icono:

Este icono te lleva a la lista de todas las agregaciones en las que está incluido el host o servicio afectado.

Ahora que tienes un árbol un poco más interesante, puedes acercarte un poco más a las distintas opciones de visualización que ofrece CMK. El punto de partida 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 mostrados en la página. En el caso de BI actualmente puedes encontrar cuatro opciones:

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

A partir de la versión 1.6.0, además de las representaciones tabulares Checkmk también domina la visualización de las Agregaciones BI. Puedes ver las agregaciones desde una nueva perspectiva, y a veces con mayor claridad. Encontrarás laBI Visualization vía en la vista de agregaciones normal.

Puedes mover el árbol libremente haciendo clic en el fondo, y escalar toda la visualización utilizando la rueda del ratón. En cuanto el puntero del ratón esté sobre un nodo individual, obtendrás la información de estado asociada al nodo a través de una ventana flotante. Utiliza la rueda del ratón para escalar la longitud de las ramas del árbol.

Si haces clic en los nodos de las hojas, accederás directamente a las vistas detalladas del host o del servicio. Un clic con el botón derecho del ratón en los demás nodos -según el tipo de nodo- da acceso a las opciones de visualización y, por ejemplo, a la propia regla responsable -Edit rule en la imagen inferior.

Continúa con la configuración. Ha llegado el momento de ponerse manos a la obra. Hasta ahora, el ejemplo ha sido tan sencillo que ha sido posible enumerar individualmente todos los objetos de la agregación sin dificultad. Pero, ¿y si las cosas se vuelven más complejas? ¿Y si quieres formular muchas dependencias recurrentes iguales o similares? ¿Y si una aplicación no incluye una única instancia, sino varias? ¿Y si quieres agrupar cientos de servicios individuales de una base de datos en un nodo BI?

Pues bien, para este tipo de requisitos necesitas métodos de configuración más potentes. Y esto es exactamente 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 se deja configurar mediante "arrastrar y soltar". Sin embargo, una vez que conozcas sus posibilidades, seguro que no querrás pasar sin ellas.

Empecemos por los parámetros. Tomemos la siguiente situación: no sólo quieres saber si los dos conmutadores están UP, sino también conocer el estado de los dos puertos responsables del enlace ascendente. En términos generales, se trata de los cuatro servicios siguientes:

Ahora el nodo Switch 1 & 2 debe ampliarse para sustituir los dos estados host de los conmutadores 1 y 2, de modo que cada uno tenga un subnodo que muestre el estado host y las dos interfaces de enlace ascendente. Estos dos subnodos deben ser Switch 1 o Switch 2.

En realidad, ahora necesitas dos reglas nuevas, una para cada conmutador. Para ello, lo mejor es crear una nueva regla <conmutador> y dotarla de un parámetro. Este parámetro es una variable a la que llamas cuando invocas la regla desde el nodo padre -que aquí puede proporcionarte la antigua regla Switch 1 & 2. En este ejemplo puedes pasar simplemente un 1 o un 2. El parámetro recibe un nombre que puedes elegir libremente. Toma aquí por ejemplo el nombre NUMBER. La ortografía con mayúsculas es puramente arbitraria, y si te parecen más bonitas las minúsculas también eres libre de utilizarlas.

Y el encabezamiento de la regla tendrá este aspecto:

Puedes elegir switch como ID de la nueva regla. En parametersimplemente introduce el nombre de la variable: NUMBER. Ahora también es importante que la variable se utilice en la regla Rule Titlepara que los dos nodos no se llamen simplemente switch y tengan el mismo nombre. Al utilizar la variable se establece un signo de dólar inicial y final, como es habitual en muchos lugares de Checkmk. Como resultado, los dos nodos se llamarán Switch 1 ySwitch 2.

El tema de las expresiones regulares merece de nuevo un análisis más detallado. Al hacer coincidir el nombre del servicio, al principio hemos subrayado tácitamente que, en el fondo, sólo se trata de expresiones regulares. Como acabamos de mencionar, existe una concordancia de prefijo.

Así, en un nodo BI, si, por ejemplo, en 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á te parezca un poco atrevido! ¿No es peligroso omitir silenciosamente cosas que deberían estar ahí si faltan?

Bueno, con el tiempo te darás cuenta de lo práctico que es este concepto, porque te permitirá escribir reglas "inteligentes" que pueden reaccionar ante situaciones muy diferentes. ¿Hay algún servicio que no existe en todas las instancias de una aplicación? No hay problema: ¡sólo se tiene en cuenta si está ahí! ¿O se pueden eliminar temporalmente host o servicios de la monitorización? Entonces simplemente desaparecen de BI sin que se produzcan errores ni nada parecido ¡BI no está ahí para ver 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 en realidad no existen, porque los nombres del servicio siempre se ven como expresiones regulares, aunque no contengan 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 a los cambios. Continúa con el ejemplo de los dos servidores de aplicacionessrv-mys-1 y srv-mys-2 del ejemplo. Tu árbol debería seguir creciendo. El nodo Infrastructure debería deslizarse al nivel 2. Y como raíz definitiva, debería haber una regla con el título The Mystery Application bajo la cual se colgará todo. Junto a Infrastructure debería haber un nodo con el nombre Mystery Servers. Bajo éste se supone que se colgarán los (actualmente) dos servidores misteriosos. En cada uno de ellos, unos cuantos servicios genéricos entran en la agregación. El resultado debería ser el siguiente:

De forma similar a la búsqueda de host, también existe un tipo de generador de hijos llamadoCreate nodes based on a service search. Aquí tienes un ejemplo:

Aquí puedes utilizar () -poniendo entre paréntesis expresiones parciales- tanto en el host como en el servicio, donde:

Y nunca olvides que siempre puedes utilizar para obtener ayuda en línea.

Es posible que en tus intentos hayas tropezado con el generador de hijosState of remaining services. Esto genera un nodo para cualquiera de los servicios de tu host que aún no hayan sido ordenados en tu Agregación BI. Esto es útil si utilizas BI para combinar los estados de todos los servicios de un host en grupos claramente ordenados, como se hace en el ejemplo incluido.

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

Por defecto, el rol User es sólo el primero de los dos permisos activos. Los usuarios normales sólo pueden trabajar en aquellos paquetes de reglas para los que se hayan definido como contacto, lo que se hace en los Detalles del paquete de reglas.

En el siguiente ejemplo Permitted Contact Groups se ha autorizado al grupo de contacto The Mystery Admins, por lo que 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 packpuedes permitir que otros usuarios utilicen al menos las reglas contenidas aquí - es decir, que definan (en otro lugar) sus propias reglas - que luego pueden invocar estas reglas como subnodos.

¿Cómo es la visibilidad real de las agregaciones en la interfaz de estado? ¿Qué contactos pueden ver algo?

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

En el rol User, este derecho está desactivado por defecto. Los usuarios normales sólo pueden ver los host y servicios compartidos, y en BI éstos se expresan de tal forma que pueden ver exactamente todas las agregaciones BI que contengan al menos un host o servicio compartido. Sin embargo, estas agregaciones sólo contienen estos objetos autorizados, por lo que pueden estar algo "adelgazadas", ¡y esto a su vez significa que pueden tener diferentes estados para diferentes usuarios!

En caso de duda, puedes alternar el permiso y, mediante un desvío a través de BI, permitir que algunos o todos los usuarios vean host y servicios de los que no son contactos, garantizando así que el estado de una agregación sea siempre el mismo para todos.

Por supuesto, todo este asunto sólo importa si, de hecho, hay agregaciones tan variopintas que sólo algunos usuarios son contactos para partes de ella.

¿Cómo gestiona realmente BI los tiempos de mantenimiento? Bueno, hemos reflexionado mucho sobre el asunto y lo hemos discutido con muchos usuarios: el resultado es el siguiente:

Para entender qué regla BI calcula el estado "en mantenimiento", ayuda que te recuerden cuál es la idea real detrás de los tiempos de mantenimiento:se está trabajando en el objeto en cuestión. Cabe esperar fallos. Aunque el objeto esté OK, no debes confiar en él. Puede convertirse en CRIT en cualquier momento. Esto se sabe y está documentado, por lo que no debería activar una notificación.

Esta idea puede trasladarse 1:1 a BI: En la agregación puede haber algunos host y servicios que estén actualmente en mantenimiento. El hecho de que estén OK o CRIT no influye, porque en realidad es una coincidencia que durante las tareas de mantenimiento los objetos se apaguen y vuelvan a encenderse o no. Que haya un objeto de mantenimiento en la unidad no significa inmediatamente que la aplicación que mapea la agregación esté a su vez "amenazada" y deba marcarse también como "en mantenimiento". También puede tener instalada una redundancia que compense el fallo de los objetos en mantenimiento. Sólo si un fallo de este tipo condujera realmente a un estado CRIT para la agregación -por lo que no hay suficiente redundancia y la agregación está realmente amenazada-, sólo entonces Checkmk la marcará como "en mantenimiento". En este caso tampoco suele importar el estado actual de los objetos.

Para decirlo más concisamente, la regla exacta es la siguiente:

Si un estado CRIT de un host/servicio diera lugar a un estado CRIT de la agregación, un estado "en mantenimiento" de ese host/servicio da lugar a un estado "en mantenimiento" de la agregación.

Importante: el estado actual real de los host/servicios no interviene en el cálculo: lo que está en mantenimiento se considera CRIT en la lógica de BI. ¿Por qué? Porque un estado UP u OK durante un periodo de mantenimiento es pura coincidencia, por ejemplo si un host informa UP durante unos segundos entre varios reinicios.

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

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

Sin embargo, el servicio Memory de srv-mys-1 también está en mantenimiento. Éste no es redundante. Por tanto, el mantenimiento lo hereda el nodo padre Mystery Server 1, luego continúa hasta Mystery Serversy finalmente hasta el nodo superior The Mystery Application. Así que este nodo superior también está en mantenimiento.

Antes hemos escrito que no se puede poner manualmente una Agregación BI en tiempo de mantenimiento... Eso es cierto sólo a medias, ya que, de hecho, ¡puedes encontrar un comando para establecer tiempos de mantenimiento en las Agregaciones BI! Pero esto no hace más que registrar una entrada de mantenimiento para cada host y servicio de la Agregación! Esto, por supuesto, suele llevar a que la propia Agregación se marque como en mantenimiento. Pero eso es sólo indirecto.

Arriba has visto que el cálculo del tiempo de mantenimiento se basa en un estado CRIT supuesto. En las propiedades de una agregación puedes personalizar el algoritmo para que un nodo que asuma el estado WARN se marque como en mantenimiento. La opción para ello se llama Escalate downtimes based on aggregated WARN state:

La suposición básica sigue siendo que los objetos en mantenimiento son CRIT. Sólo hay una diferencia 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. Aquí ya se habría aceptado un tiempo de mantenimiento si sólo uno de los dos interruptores estuviera en mantenimiento.

De forma bastante similar al proceso con los tiempos de mantenimiento, si se ha reconocido un problema la información también es calculada automáticamente por BI. Esta vez el estado de los objetos desempeña ciertamente un papel.

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 siendo WARN o CRIT, entonces no se consideraría reconocida, porque entonces debe haber al menos un problema importante que no se ha reconocido, y por tanto se eliminará el estado OK de la unidad.

Por cierto, el te ofrecerá un comando para que la Agregación BI reconozca sus problemas, pero esto sólo significa que se reconocerán todos los host y servicios detectados en la agregación (sólo los que tengan problemas en ese momento).

Utilizar 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á siempre que la marca de verificación se ponga de nuevo; incluso si la agregación ha existido previamente (a pesar de la referencia a New aggregations …​). Para descongelar el estado congelado, quita la marca de verificación correspondiente.

En la monitorización, ahora verás un nuevo icono de copo de nieve junto a la agregación, que te llevará a la vista que muestra las diferencias: a la izquierda el árbol congelado, a la derecha el árbol actual con los cambios resaltados (aquí la eliminación del servicio backup3):

Si quieres congelar de nuevo el estado actual, puedes hacerlo a través de Commands > Freeze aggregations. Pero ten cuidado: Siempre hay un único estado actual congelado y ningún historial que incluya estados anteriores.

¿Puedes notificar realmente los cambios de estado en las agregaciones BI? Bueno, en principio no es directamente posible, ya que BI existe exclusivamente en la GUI y no tiene ninguna relación con la monitorización real. Pero puedes convertir las Agregaciones BI en servicios normales, y éstos a su vez, por supuesto, pueden activar notificaciones. Hay dos posibilidades:

Empezaremos con el método del programa fuente de datos, porque siempre es bueno si deseas generar más de un puñado de agregaciones como servicios. Encontrarás el conjunto de reglas adecuado en Setup > Agents > Other integrations > BI Aggregations:

Aquí puedes incluso especificar diferentes opciones para qué host deben añadirse los servicios. No tienes que ceñirte necesariamente al host que ejecuta el programa fuente de datos (Assign to the querying host). También es posible asignar a los host que se ven afectados por la agregación (Assign to the affected hosts). Sin embargo, esto sólo tiene sentido si afecta a un único host. Las expresiones regulares y las sustituciones pueden hacerte aún más flexible con las asignaciones. Todo se realiza entonces mediante el mecanismo piggyback.

Importante: Si el host al que asignas esta regla debe seguir siendo monitorizado a través del agente normal, asegúrate en su configuración de que se ejecutan los programas Agente y Fuente de datos:

La notificación mediante un check activo es más o menos la forma más directa, y no requiere ningún "host helper" artificial al ejecutar el programa fuente de datos, ya que tiene que consultar cada unidad individualmente, pero con un número mayor de agregaciones es bastante menos eficiente y también más complicado de configurar.

Simplificando: Hay un check activo que puede recuperar el estado de las agregaciones BI mediante HTTP desde la API-REST de Checkmk. Puedes configurarlo fácilmente con el conjunto de reglasSetup > Services > Other services > Check State of BI Aggregation:

Ten en cuenta lo siguiente:

En el ejemplo se activa Automatically track downtimes of aggregation. Estrictamente hablando, esto significa los tiempos de mantenimiento programados. Esto hará que el nuevo servicio activo obtenga automáticamente un tiempo de mantenimiento, ¡aunque la Agregación BI también lo haga!

El nuevo servicio muestra entonces -con un retraso de hasta un intervalo de comprobación, por supuesto- el estado de la unidad. El ejemplo muestra el BI-Check en el host srv-mys-1:

Como de costumbre, puedes asignar este servicio a contactos y utilizarlo como base para una notificación.