Monitorización distribuida

Livestatus es una interfaz integrada en el núcleo de monitorizaciónque permite a otros programas externos consultar datos de estado y ejecutar comandos. Livestatus puede estar disponible a través de la red para que pueda acceder a él un site remoto de Checkmk. La interfaz de usuario de Checkmk utiliza Livestatus para combinar todos los sites conectados en una visión general. De este modo, parece un "gran" sistema de monitorización.

El siguiente diagrama muestra esquemáticamente la estructura de una monitorización con Livestatus distribuida en tres emplazamientos. El site central Checkmk se encuentra en el site central de proceso. Desde aquí se controlan directamente los sistemas centrales. Además, están el Site remoto 1 y el Site remoto 2, que se encuentran en otras redes y son controlados por sus sistemas locales:

Lo que hace especial a este método es que el estado de monitorización de los sites remotos no se envía continuamente al site central. La GUI sólo recupera los datos en directo de los sitios remotos cuando los necesita un usuario del centro de control. A continuación, los datos se recopilan en una vista centralizada. Por tanto, no hay almacenamiento central de datos, ¡lo que ofrece enormes ventajas para la ampliación!

He aquí algunas de las ventajas de este método:

En un sistema distribuido utilizando Livestatus como el descrito anteriormente, es muy posible que los sites individuales puedan ser mantenidos independientemente por diferentes equipos, y que el site central sólo tenga la tarea de proporcionar un dashboard centralizado.

En el caso de que sean varios, o de que todos los sitios deban ser administrados por el mismo equipo, una configuración central es mucho más fácil de manejar. Checkmk apoya esto y se refiere a tal configuración como un entorno de configuración distribuida. Con esto, todos los host y servicios, usuarios y permisos, periodicidades y notificaciones, etc., se mantendrán y configurarán en el site central, y luego, dependiendo de sus tareas, se distribuirán automáticamente a los sites remotos.

Un sistema así no sólo tiene una visión general común del estado, sino también una configuración común, y efectivamente "se siente como un gran sistema".

Incluso puedes ampliar un sistema así con sites del visor dedicados, por ejemplo, que sirvan sólo como interfaces de estado para subáreas o grupos de usuarios concretos.

No hay requisitos especiales para el site central. Esto significa que un site establecido desde hace tiempo puede ampliarse a una monitorización distribuida sin necesidad de modificaciones adicionales.

Los sites remotos se generan como nuevos sites de la forma habitual con omd create. Esto tendrá lugar naturalmente en el servidor (remoto) destinado al site remoto respectivo.

Notas especiales:

Aquí tienes un ejemplo para crear un site remoto con el nombre remote1:

El paso más importante ahora es habilitar Livestatus a través de TCP en la red. Ten en cuenta que Livestatus no es per se un protocolo seguro y sólo debe utilizarse dentro de una red segura (LAN segura, VPN, etc.). La habilitación aparece por omd config como usuario del site en un site detenido:

Ahora selecciona Distributed Monitoring:

Establece LIVESTATUS_TCP en ‘on’ e introduce un número de puerto disponible paraLIVESTATUS_TCP_PORT que sea explícito en este servidor. El valor por defecto es 6557:

Después de guardar, inicia el site normalmente con omd start:

Conserva la contraseña para cmkadmin. Una vez que el remoto se haya subordinado al site central, todos los usuarios serán sustituidos igualmente por los del site central.

El remoto ya está listo. Compruébalo con netstat, que debería mostrar que el puerto 6557 está abierto. La conexión a este puerto la realiza un site del superservidor de internet xinetd, que se ejecuta directamente en el site:

La configuración de la monitorización distribuida tiene lugar exclusivamente en el site central en el menú Setup > General > Distributed monitoring, y sirve para gestionar las conexiones a los sites individuales. Para esta función, el propio site central cuenta como site y ya está presente en la lista:

Utilizando Add connection, define ahora la conexión con el primer site remoto:

En Basic settings es importante utilizar el nombre EXACTO del site remoto -tal y como se definió con omd create- como Site ID. Como siempre, el alias puede definirse como se desee y también modificarse posteriormente.

Los ajustes de Status connection determinan cómo consulta la central el estado de los sites remotos a través de Livestatus. El ejemplo de la captura de pantalla muestra una conexión con el método Connect via TCP(IPv4). Éste es el óptimo para conexiones estables con periodos de latencia cortos (como, por ejemplo, en una LAN). Más adelante hablaremos de los ajustes óptimos para conexiones WAN.

Introduce aquí la HTTP-URL a la interfaz web del remoto (sólo la parte que precede al componente check_mk/ ). Si básicamente accedes a Checkmk mediante HTTPS, sustituye aquí http por https. Encontrarás más información en la ayuda en línea o en el artículo sobre cómo proteger la interfaz web con HTTPS.

Replicar la configuración y utilizar así el entorno de configuración distribuido es, como hemos comentado en la introducción, opcional. Actívalo si deseas configurar el remoto con y desde el site central. En tal caso, selecciona la configuración exacta como se muestra en la imagen de arriba.

Es muy importante una configuración correcta de URL of remote site. La URL debe terminar siempre en /check_mk/. Se recomienda una conexión con HTTPS, siempre que el Apache del site remoto admita HTTPS, que debe instalarse manualmente en el remoto a nivel de Linux. Para el Appliance Checkmk, HTTPS puede configurarse mediante la interfaz de configuración basada en web. Si utilizas un certificado autofirmado, necesitarás la caja Ignore SSL certificate errors.

Una vez guardada la máscara, aparecerá un segundo site en la vista general:

El estado de monitorización del site remoto (hasta ahora) vacío está ahora correctamente integrado. Para poder utilizar el entorno de configuración distribuida sigues necesitando un login para el site remoto de Checkmk. Para ello, el site central intercambia un secreto de inicio de sesión generado aleatoriamente con el site remoto, a través del cual se realizará toda la comunicación futura. Posteriormente, ya no se utilizará el acceso cmkadmin en el site remoto.

Para iniciar sesión utiliza los datos de acceso cmkadmin y la contraseña correspondiente del site remoto. No olvides marcar la caja Confirm overwrite, antes de pulsar el botón Login:

Un inicio de sesión con éxito será reconocido:

Si se produce un error en el inicio de sesión, puede deberse a varias razones, por ejemplo:

Los puntos 1. y 2. pueden comprobarse fácilmente llamando manualmente a la URL del remoto en tu navegador.

Cuando todo haya ido bien, ejecuta Activate Changes. Esto te llevará, como siempre, a una vista general de los cambios aún no activados. Simultáneamente, la vista general también mostrará los estados de las conexiones Livestatus, así como los estados de sincronización del entorno de configuración distribuido de los sites individuales:

La columna Version muestra la versión de Livestatus del site correspondiente. Si utilizas la CMC como núcleo de Checkmk (ediciones comerciales), el número de versión del núcleo (que se muestra en la columna ‘Core’ ) es idéntico al de Livestatus. Si utilizas Nagios como núcleo (Checkmk edición Raw), aquí se mostrará el número de versión de Nagios.

Los siguientes símbolos muestran el estado de replicación del entorno de configuración:

En la columna Status se puede ver el estado de la conexión Livestatus para el site correspondiente. Esto se muestra a título meramente informativo, ya que la configuración no se transmite a través de Livestatus, sino a través de HTTP. Son posibles los siguientes valores:

Al hacer clic en el botón Activate on selected sites se sincronizarán ahora todos los sites y se activarán los cambios. Esto se realiza en paralelo, de modo que el tiempo total equivale al tiempo requerido por el site más lento. En el tiempo se incluye la creación de una instantánea de configuración para el site respectivo, la transmisión a través de HTTP, el desempaquetado de la instantánea en el site remoto y la activación de los cambios.

Importante: No salgas de la página antes de que se haya completado la sincronización en todos los sites - si sales de la página se interrumpirá la sincronización.

Una vez instalado tu entorno distribuido, puedes empezar a utilizarlo. En realidad, sólo tienes que indicar a cada host qué site debe monitorizarlo. Por defecto, se especifica el site central.

El atributo necesario para ello es ‘Monitored on site’. Puedes establecerlo individualmente para cada host. Naturalmente, esto también puede realizarse a nivel de carpeta:

Añadir hosts funciona como de costumbre - aparte del hecho de que la monitorización y el descubrimiento de servicios se ejecutarán desde el site remoto correspondiente, no hay consideraciones especiales.

Al migrar hosts de un site a otro hay un par de puntos que debes tener en cuenta.No se transferirán los datos de estado actuales ni históricos del host.Sólo se conserva la configuración del host en el entorno de configuración. En efecto, es como si se hubiera eliminado el host de un site y se hubiera instalado de nuevo en el otro site:

Si la continuidad del historial es importante para ti, al implantar la monitorización debes planificar cuidadosamente qué host se va a monitorizar y desde dónde.

Para lograr la encriptación, Checkmk utiliza el programa stunnel junto con su propio certificado y su propia Autoridad de Certificación (AC) para firmar el certificado. Estos se generarán individualmente de forma automática con un site nuevo y, por tanto, no son CAs o certificados estáticos predefinidos. Se trata de un factor de seguridad muy importante para evitar que los atacantes utilicen certificados falsos, ya que cualquier atacante podría acceder a una CA de acceso público.

Los certificados generados también tienen las siguientes propiedades:

El hecho de que el certificado estándar sea válido durante tanto tiempo evita de forma muy eficaz que tengas problemas de conexión que no puedas clasificar. Al mismo tiempo, es posible, por supuesto, que una vez que un certificado se ha visto comprometido, quede abierto durante mucho tiempo al abuso. Por tanto, si temes que un atacante acceda a la CA o al certificado de site firmado con ella, ¡reemplaza siempre ambos certificados (CA y site)!

Durante una actualización de Checkmk, las dos opciones LIVESTATUS_TCP y LIVESTATUS_TCP_TLS nunca se cambian automáticamente. La activación automática de TLS podría acabar provocando que tus sites remotos ya no puedan ser consultados.

Si hasta ahora has estado utilizando Livestatus sin cifrar y ahora decides utilizar el cifrado, debes activarlo manualmente. Para ello, primero detén los sites afectados y luego activa TLS con el siguiente comando:

Como los certificados se generaron automáticamente durante la actualización, el site utilizará inmediatamente la nueva función de encriptación. Para que puedas seguir accediendo al site desde el site central, comprueba que la opción Encryption está configurada como Encrypt data using TLS en el menú Setup > General > Distributed Monitoring:

El último paso es como el descrito anteriormente - de nuevo aquí primero tienes que marcar la CA del site remoto como de confianza.

Todos los accesos a un host monitorizado se realizan sistemáticamente desde el site al que está asignado el host. Esto se aplica no sólo a la monitorización propiamente dicha, sino también al descubrimiento de servicios, la página de Diagnósticos, lasNotificaciones, los alert handlers y todo lo demás. Este punto es muy importante, ya que no se supone que el site central tenga realmente acceso a este host.

Algunas de las vistas estándar están agrupadas según el site desde el que se monitorizará el host - esto se aplica, por ejemplo, a All hosts:

El site también se mostrará en los detalles del host o servicio:

Esta información suele estar disponible para utilizarla en una columna alcrear tus propias vistas. También hay un filtro con el que se puede filtrar una vista de tablas de host en un site concreto:

Hay un snap-in Site status para la barra lateral que puede añadirse utilizando . Muestra el estado de los sitios individuales. También proporciona la opción de desactivar y volver a activar temporalmente un solo sitio haciendo clic en el estado - o todos los sitios a la vez haciendo clic en Disable all o Enable all.

Los sitios desactivados se marcarán con el estado. Con esto también puedes desactivar un sitio que esté generando timeouts, evitando así timeouts superfluos. Esta desactivación no es lo mismo que desactivar la conexión Livestatus utilizando la configuración de conexión en Setup. Aquí la "desactivación" sólo afecta al usuario conectado en ese momento y tiene una función puramente visual. Al hacer clic en el nombre de un sitio se mostrará una vista de todos sus hosts.

En una monitorización distribuida, el snap-in Master control tiene un aspecto diferente.Cada site tiene su propio interruptor global:

Si monitorizas con Checkmk HA-Cluster, los nodos individuales del clúster deben estar asignados al mismo site que el propio clúster. Esto se debe a que para determinar el estado de los servicios en clúster se accede a archivos de caché generados mediante la monitorización del nodo. Estos datos se encuentran localmente en el site correspondiente.

Algunos check plugin utilizan datos piggyback, por ejemplo, para asignar los datos de monitorización recuperados de un host de ESXi a las máquinas virtuales individuales. Por la misma razón que en la monitorización de clústeres, en la monitorización distribuida el host "piggy" (portador), así como sus hosts dependientes, deben monitorizarse desde el mismo site. En el caso de ESXi, esto significa que las máquinas virtuales deben estar asignadas al mismo site en Checkmk que el sistema ESXi del que se recogen los datos de monitorización. Esto puede significar que es mejor sondear directamente el sistema host ESXi en lugar de sondear un vCenter global. Encontrarás más detalles al respecto en la documentación sobre la monitorización de ESXi.

El inventario de hardware/software de Checkmk también funciona en entornos distribuidos. Para ello, los datos del inventario del directoriovar/check_mk/inventory deben transmitirse regularmente desde los remotos al site central. Por razones de rendimiento, la interfaz de usuario siempre accede a este directorio localmente.

En las ediciones comerciales, la sincronización se realiza automáticamente en todos los sites que están conectados mediante el proxy Livestatus.

Si realizas inventarios utilizando Checkmk Raw en sistemas distribuidos, el directorio debe reflejarse regularmente en el site central con tus propias herramientas (por ejemplo, con rsync).

Incluso cuando todos los sites se monitorizan de forma centralizada, es muy posible, y a menudo también adecuado, iniciar sesión en la interfaz de un site individual. Por este motivo, Checkmk garantiza que la contraseña de un usuario sea siempre la misma para todos los sites.

Un cambio de contraseña realizado por el administrador tendrá efecto automáticamente en cuanto se comparta con todos los sites con Activate Changes.

Un cambio realizado por el propio usuario mediante la barra lateral de su configuración personal funciona de forma algo distinta. No puede ejecutarlo un Activate changes, ya que, por supuesto, el usuario no tiene autoridad general para esta función. En tal caso, Checkmk compartirá automáticamente la contraseña modificada en todos los sites, directamente después de guardarla, de hecho.

Como todos sabemos, las redes nunca están disponibles al 100 %. Si un site está inaccesible en el momento de un cambio de contraseña, no recibirá la nueva contraseña. Hasta que el administrador ejecute con éxito un Activate changes, o respectivamente, el siguiente cambio de contraseña con éxito, este site retendrá la antigua contraseña para el usuario. Un símbolo de estado informará al usuario del estado de la compartición de contraseñas a los sites individuales.

Es evidente que las etiquetas del host utilizadas en el site remoto también deben ser conocidas por el site central para que puedan ser transferidas. Compruébalas antes de la migración y añade manualmente al site central las etiquetas que falten. Aquí es esencial que coincidan los tag-IDs - el título de la etiqueta es irrelevante.

A continuación, traslada los host y las reglas al entorno de configuración del site central. Esto sólo funciona para host y reglas en subcarpetas (es decir, no en la carpeta Main ). Los host de la carpeta principal deben trasladarse primero simplemente a una subcarpeta de un site remoto a través de Setup > Hosts > Hosts.

La migración propiamente dicha puede realizarse simplemente copiando los directorios apropiados. Cada carpeta del entorno de configuración corresponde a un directorio dentro de ~/etc/check_mk/conf.d/wato/. Estos pueden copiarse utilizando una herramienta de tu elección (por ejemplo, scp) desde el sitio remoto a la misma ubicación en el sitio central. Si ya existe allí un directorio con el mismo nombre, simplemente cámbiale el nombre. Ten en cuenta que los usuarios y grupos de Linux también son utilizados por el sitio central.

Tras la copia, los host aparecerán en el Setupdel sitio central, así como las reglas que hayas creado en estas carpetas. Con la copia también se incluirán las propiedades de las carpetas, que se encuentran en el directorio del archivo oculto .wato.

Para que los atributos de las funciones de la carpeta padre del site central se hereden correctamente, como paso final tras la migración, las características de las carpetas padre deben abrirse y guardarse una vez - de este modo, los atributos del host estarán definidos de nuevo.

Instalar el proxy Livestatus es muy sencillo. Está activado por defecto en las ediciones comerciales, lo que se puede ver al iniciar un site:

Selecciona la opción 'Use Livestatus Proxy-Daemon' para la conexión a los sites remotos en lugar de 'Conectar vía TCP':

Los detalles de host y puerto son los de siempre. No hay que hacer ningún cambio en el site remoto. En Number of channels to keep open introduce el número de conexiones TCP paralelas que el proxy debe establecer y mantener con el site de destino.

El conjunto de conexiones TCP es compartido por todas las consultas de la GUI. El número de conexiones limita el número máximo de consultas que pueden procesarse simultáneamente, lo que indirectamente limita el número de usuarios. En situaciones en las que todos los canales estén reservados, esto no provocará inmediatamente un error. La GUI espera un tiempo determinado a que haya un canal libre. En realidad, la mayoría de las consultas sólo requieren unos milisegundos.

Si la GUI debe esperar más de Timeout waiting for a free channel por un canal, se interrumpirá con un error y el usuario recibirá un mensaje de error. En tal caso, debe aumentarse el número de conexiones. Ten en cuenta, sin embargo, que en el site remoto deben permitirse suficientes conexiones entrantes paralelas - por defecto está configurado a 20. Este ajuste se encuentra en las opciones globales enMonitoring core > Maximum concurrent Livestatus connections.

Regular heartbeat proporciona una monitorización activa constante de las conexiones directamente a nivel de protocolo. En el proceso, el proxy envía regularmente una simple consulta de Livestatus que debe ser respondida por el site remoto en el tiempo predeterminado (por defecto: 2 segundos). Con este método también se detectará una situación en la que el servidor de destino y el puerto TCP están realmente accesibles, pero el núcleo de monitorización ya no responde.

Si no aparece una respuesta, todas las conexiones se declararán "muertas" y, tras un tiempo de "enfriamiento" (por defecto: 4 segundos), se volverán a establecer. Todo esto tiene lugar de forma proactiva, es decir, sin que el usuario tenga que abrir una ventana GUI. De este modo, las interrupciones pueden detectarse rápidamente y, mediante una recuperación, las conexiones pueden restablecerse inmediatamente y, en el mejor de los casos, estar disponibles antes de que el usuario se dé cuenta de la interrupción.

Caching garantiza que las consultas estáticas sólo tengan que ser respondidas una vez por el site remoto, y que a partir de ese momento puedan ser respondidas directa y localmente, sin demora. Un ejemplo de ello es la lista de host monitorizados que requiere Quicksearch.

El proxy Livestatus tiene su propio archivo de registro, que se encuentra en var/log/liveproxyd.log. En un site remoto correctamente configurado con cinco canales (estándar), tendrá un aspecto similar al siguiente:

El proxy Livestatus registra regularmente su estado en el archivo var/log/liveproxyd.state:

Y cuando un site esté detenido, el estado tendrá este aspecto

Aquí el estado es 'starting'. Por tanto, el proxy está intentando establecer conexiones. Aún no hay canales. Durante este estado, las consultas al site se responderán con un error.

Primero, en el site remoto, crea una copia de las configuraciones de sus host y servicios en formato Nagios-configuration. También redirige la salida de livedump -TC a un archivo:

El inicio del archivo será algo parecido a esto

Transmite el archivo al site central, (por ejemplo con scp) y guárdalos allí en el directorio ~/etc/nagios/conf.d/ - aquí Nagios espera encontrar los datos de configuración de host y servicios. Selecciona un nombre de archivo que termine en.cfg, por ejemplo ~/etc/nagios/conf.d/config-remote1.cfg. Si es posible un acceso SSH desde el site remoto al site central, puede hacerse, por ejemplo, como se indica a continuación:

Ahora accede al site central y activa los cambios:

Ahora todos los host y servicios del remoto deberían aparecer en el site central - inicialmente con el estado PEND, que conservarán por el momento:

Nota:

Una vez que los host sean visibles en el site central, necesitaremos configurar una transmisión (regular) del estado de monitorización de los remotos. Crea de nuevo un archivo con livedump, pero esta vez sin opciones secundarias:

Este archivo contiene los estados de todos los host y servicios en un formato que Nagios puede leer directamente de los resultados de check. El inicio de este archivo es algo parecido a esto

Copia este archivo en el site central, en el directorio ~/tmp/nagios/checkresults . Importante: El nombre de este archivo debe empezar por c y tener siete caracteres. Con scp tendrá un aspecto parecido a éste:

Por último, crea un archivo vacío en el site central con el mismo nombre y la extensión .ok. Con esto Nagios sabrá que el archivo de estado se ha transferido completamente y ahora se puede leer en él:

El estado de los host/servicios remotos se actualizará inmediatamente en el site central:

A partir de ahora, la transmisión del estado debe hacerse con regularidad. Lamentablemente, Livedump no admite esta tarea y tendrás que guionizarla tú mismo. El script livedump-ssh-recv se encuentra en ~/share/check_mk/doc/treasures/livedump, que puedes emplear para recibir las actualizaciones de Livedump (incluidas las de la configuración) en el site central por SSH. Para más detalles, consulta los comentarios del propio script.

El volcado de la configuración y del estado también puede restringirse utilizando filtros Livestatus. Por ejemplo, podrías limitar los host a los miembros del grupo del host mygroup:

Puedes encontrar más información sobre Livedump en el archivo README del directorio ~/share/doc/check_mk/treasures/livedump.

Las ediciones comerciales proporcionan un mecanismo integrado para las notificaciones centralizadas, que puede activarse individualmente para cada site remoto. Estos remotos dirigen todas las notificaciones al site central para su posterior procesamiento. De este modo, la notificación centralizada es independiente de si la monitorización distribuida se ha configurado de la forma estándar, o con CMCDump, o utilizando una mezcla de estos procedimientos. Técnicamente hablando, el servidor de notificación central ni siquiera necesita ser el "central". Esta tarea puede ser asumida por cualquier site Checkmk.

Si un site remoto se ha configurado como "reenviador", todas las notificaciones se reenviarán directamente al site central tal y como lo harían desde el núcleo, es decir, en formato raw. Una vez allí, se evaluarán las reglas de notificación que realmente deciden a quién se debe notificar y cómo. Los scripts de notificación necesarios se invocarán en el site central.

Los spoolers de notificación de los sites remoto y central (notificación) se comunican entre sí mediante TCP. Las notificaciones se envían del site remoto al central. La central reconoce a las remotas que se han recibido las notificaciones, lo que evita que se pierdan aunque se interrumpa la conexión TCP.

Hay dos alternativas para la construcción de una conexión TCP:

Por tanto, no hay nada que impida enviar notificaciones si, por motivos de red, sólo es posible establecer conexiones en una dirección concreta. Las conexiones TCP son supervisadas por el spooler con una señal de heartbeat y se restablecen inmediatamente cuando es necesario, no sólo en caso de notificación.

Dado que el site remoto y el central requieren ajustes globales diferentes, debes realizarajustes específicos para todos los remotos. La configuración del site central se realiza utilizando los ajustes globales normales. Nota: estos ajustes serán heredados automáticamente por todos los remotos para los que no se hayan definido ajustes específicos.

Veamos primero un ejemplo en el que el site central establece las conexiones TCP con los sites remotos.

Paso 1: En el site remoto, edita la configuración global específica del siteNotifications > Notification Spooler Configuration y activaAccept incoming TCP connections. Se recomendará el puerto TCP 6555 para las conexiones entrantes. Si no hay objeciones, adopta esta configuración.

Paso 2: Ahora, del mismo modo, en el submenú Notification Spooling sólo en el site remoto, selecciona la opciónForward to remote site by notification spooler.

Paso 3: Ahora, en el site central- es decir, en la configuración global normal - configura la conexión con el site remoto (y luego con los remotos adicionales que sean necesarios):

Paso 4: Establece la configuración global Notification Spooling enAsynchronous local delivery by notification spooler, para que las comunicaciones del site central también se procesen a través del mismo spooler central.

Paso 5: Activa los cambios.

Si la conexión TCP debe establecerse desde el site remoto, el procedimiento es idéntico, diferenciándose únicamente de la descripción anterior en que simplemente se intercambian los papeles de site central y remoto.

También es posible una mezcla de ambos procedimientos. En tal caso, el site central debe instalarse de modo que escuche las conexiones entrantes, además de conectarse a los sites remotos. Sin embargo, en cada relación central/remoto, ¡sólo uno de los dos puede establecer la conexión!

El spooler de notificación registra en el archivo var/log/mknotifyd.log. En la configuración del spooler se puede aumentar el nivel de registro para que se reciban más mensajes. Con un nivel de registro estándar se debería ver algo así en el site central:

En todo momento, el archivo var/log/mknotifyd.state contiene el estado actual del spooler y de todas sus conexiones:

También existe una versión del mismo archivo en el site remoto. Allí la conexión tendrá un aspecto similar a éste

Para probarlo, selecciona cualquier servicio remoto monitorizado y ponlo manualmente en CRIT con el comando Fake check results.

Ahora, en el site central debería aparecer una notificación entrante en el archivo de registro de notificaciones (notify.log):

El mismo evento tendrá este aspecto en el site remoto:

En la configuración global puedes cambiar tanto el archivo de registro normal de notificaciones (notify.log) como el archivo de registro del spooler de notificación a un nivel de registro superior.

Una vez que hayas configurado todo como se ha descrito, te darás cuenta de que en el site central, y respectivamente en los remotos, se encontrará un nuevo servicio que definitivamente debe ser tenido en cuenta en la monitorización. Monitoriza el spooler de notificación y sus conexiones TCP, por lo que cada conexión será monitorizada dos veces: una por el site central y otra por el site remoto: