Monitorización distribuida

Livestatus es una interfaz integrada en el core de monitorización que 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 sitio Checkmk remoto. La interfaz de usuario de Checkmk utiliza Livestatus para combinar todos los sitios conectados en una vista general, que entonces se asemeja a un único y gran sistema de monitorización.

El siguiente diagrama muestra esquemáticamente la estructura de una monitorización con Livestatus distribuida en tres ubicaciones. El sitio central de Checkmk se encuentra en el sitio de procesamiento central. Desde aquí se controlarán 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 sitios remotos no se envía continuamente al sitio central. La GUI solo recupera datos en tiempo real de los sitios remotos cuando lo solicita un usuario del centro de control. A continuación, los datos se recopilan en una vista centralizada. Por lo tanto, no hay un almacenamiento central de datos, ¡lo que ofrece enormes ventajas para la escalabilidad!

Estas son algunas de las ventajas de este método:

En un sistema distribuido que utiliza Livestatus como se ha descrito anteriormente, es muy posible que los distintos sitios puedan ser mantenidos de forma independiente por diferentes equipos, y que el site central solo tenga la tarea de proporcionar un dashboard centralizado.

En el caso de que varios sitios, o todos ellos, deban ser administrados por el mismo equipo, una configuración central es mucho más fácil de manejar. Checkmk admite esto y se refiere a dicha configuración como una configuración central. Con esto, todos los hosts y servicios, usuarios y permisos, periodos de tiempo, notificaciones, etc., se mantendrán en el «Setup» del site central y luego se distribuirán automáticamente a los sitios remotos según tus especificaciones.

Este sistema no solo ofrece una vista general común del estado, sino también una configuración común, y da la sensación de ser «un gran sistema».

Incluso puedes ampliar este sistema con sitios del visor dedicados, por ejemplo, que sirvan únicamente como interfaces de estado para subáreas o grupos de usuarios específicos.

No hay requisitos especiales para el site central. Esto significa que un site ya establecido puede ampliarse a una monitorización distribuida con solo una única modificación, necesaria para el correcto manejo de los datos piggyback. Todo lo que tienes que hacer es habilitar el hub piggyback en la página de configuración Setup > General > Global settings, en la sección «Site management»:

A continuación, activa los cambios, ya que para activar o desactivar el hub piggyback es necesario reiniciar el site.

Los sitios remotos se generan entonces como nuevos sitios de la forma habitual con omd create. Esto se llevará a cabo, naturalmente, en el servidor (remoto) destinado al sitio remoto correspondiente.

Notas especiales:

Aquí tienes un ejemplo para crear un site remoto con el nombre myremote1 y la contraseña t0p53cr3t para el administrador del site cmkadmin:

Los pasos más importantes ahora son activar Livestatus a través de TCP para la red y habilitar también el concentrador piggyback aquí. Ten en cuenta que Livestatus no es en sí mismo un protocolo seguro y solo debe utilizarse dentro de una red segura (LAN protegida, VPN, etc.). La habilitación se realiza utilizando omd config como usuario del site mientras el site está detenido:

Ahora selecciona Distributed Monitoring:

Configura LIVESTATUS_TCP en on y, en LIVESTATUS_TCP_PORT, introduce un número de puerto no asignado que sea único en este servidor. El valor predeterminado es 6557:

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

Recuerda la contraseña de cmkadmin. Solo la necesitarás dos veces: primero para habilitar el hub piggyback y luego para establecer la conexión entre el site remoto y el site central. Una vez que el site remoto se haya subordinado al site central, todos los usuarios serán sustituidos por los del site central de todos modos.

La instancia ya está lista. Una check con netstat muestra que el puerto 6557 está abierto. La conexión a este puerto se realiza con una instancia del súper servidor de internet xinetd, que se ejecuta directamente en el site:

Ahora inicia sesión una vez en el site remoto como usuario cmkadmin y activa el concentrador piggyback utilizando la configuración de Setup > General > Global en la sección Site management:

A continuación, activa los cambios, ya que para encender o apagar el concentrador piggyback es necesario reiniciar el site.

La configuración de la monitorización distribuida se realiza exclusivamente en el site central, en el menú «Setup > General > Distributed monitoring», y sirve para gestionar las conexiones con los sitios individuales. Para esta función, el propio site central cuenta como un sitio y ya aparece en la lista:

Mediante 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 define en omd create— como Site ID. Como siempre, el alias se puede definir como se desee y también se puede cambiar más adelante.

La configuración de Status connection determina cómo el sitio central consulta el estado de los sitios 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). Esta es la opción óptima para conexiones estables con tiempos de latencia cortos (como, por ejemplo, en una LAN). Más adelante hablaremos de la configuración óptima para conexiones WAN.

Introduce aquí la URL HTTP de la interfaz web del site remoto, sin el check_mk/ al final de la URL. Si normalmente accedes a Checkmk a través de HTTPS, sustituye aquí el http por https. Puedes encontrar 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, por lo tanto, utilizar la configuración central es, como comentamos en la introducción, opcional. Activa la replicación seleccionando Push configuration to this site si deseas configurar el sitio remoto desde el site central. En tal caso, selecciona los ajustes exactos que se muestran en la imagen de arriba.

Asegúrate de checkear qué Message broker port debes especificar. Para averiguarlo, inicia sesión en el site remoto correspondiente y ejecuta omd config desde la línea de comandos. Ve a la sección Basic. Aquí, la variable RABBITMQ_PORT es la relevante.

Es muy importante que la configuración de URL of remote site sea correcta. La URL siempre debe terminar en /check_mk/. Se recomienda una conexión con HTTPS, siempre que el Apache del sitio remoto admita HTTPS. Esto debe instalarse manualmente en el sitio remoto a nivel de Linux. En el caso de la Appliance Checkmk, HTTPS se puede configurar mediante la interfaz de configuración web. Si utilizas un certificado autofirmado, tendrás que marcar la casilla «Ignore SSL certificate errors».

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

El estado de monitorización del sitio remoto (hasta ahora) vacío ya está correctamente integrado. Para utilizar la configuración central, sigues necesitando una cuenta Login para el sitio Checkmk remoto. Para ello, el site central intercambia un secreto de inicio de sesión generado aleatoriamente con el sitio remoto, a través del cual se llevará a cabo toda la comunicación futura. La cuenta cmkadmin en el sitio remoto ya no se utilizará a partir de ahora.

En el siguiente formulario, utiliza como Login credentials cmkadmin y la contraseña asignada al crear el site remoto. En este punto, confirma que deseas sobrescribir la configuración haciendo clic en «Confirm overwrite».

Si el inicio de sesión se realiza correctamente, se realizará un reconocimiento de la siguiente manera:

Si se produce un error al realizar el inicio de sesión, esto podría deberse a varias razones, por ejemplo:

Las dos primeras entradas de la lista se pueden comprobar fácilmente accediendo manualmente a la URL del sitio remoto en tu navegador.

Cuando todo haya salido bien, ejecuta Activate Changes. Esto te llevará, como siempre, a una vista general de los cambios aún no activados. Al mismo tiempo, la vista general también mostrará los estados de las conexiones de Livestatus, así como los estados de sincronización de cada sitio en la configuración central:

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

Los siguientes iconos muestran el estado de replicación del entorno de configuración:

En la columna «Status» se puede ver el estado de la conexión de Livestatus para el site en cuestión. Esto se muestra solo a título informativo, ya que la configuración no se transmite a través de Livestatus, sino por HTTP. Los siguientes valores son posibles:

Al hacer clic en el botón «» (Actualizar todos los sitios) Activate on selected sites, se sincronizarán todos los sitios y se activarán los cambios. Esto se realiza en paralelo, por lo que el tiempo total equivale al tiempo que tarda el sitio más lento. En ese tiempo se incluye la creación de una instantánea de configuración para el sitio correspondiente, la transmisión por HTTP, la descompresión 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 la sincronización se haya completado 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, solo tienes que indicar a cada host qué site debe supervisarlo. El site central se especifica por defecto.

El atributo necesario para esto es Monitored on site. Puedes configurarlo individualmente para cada host. Por supuesto, esto también se puede hacer 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 que tener en cuenta nada especial.

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

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

Para llevar a cabo el cifrado, Checkmk utiliza el programa stunnel junto con su propio certificado y su propia autoridad de certificación (CA) para firmar el certificado. Estos se generan automáticamente de forma individual con cada nuevo site y, por lo tanto, no son CA ni certificados estáticos predefinidos. Este es un factor de seguridad muy importante para evitar que los atacantes utilicen certificados falsos, ya que cualquier atacante podría entonces acceder a una CA disponible públicamente.

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 surjan problemas de conexión que no puedas identificar. Al mismo tiempo, por supuesto, es posible que, una vez que un certificado se haya visto comprometido, esté expuesto al abuso durante ese mismo tiempo. Así que, si temes que un atacante pueda acceder a la CA o al certificado del sitio firmado con ella, ¡sustituye siempre ambos certificados (el de la CA y el del sitio)!

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

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

Dado que los certificados se generaron automáticamente durante la actualización, el sitio utilizará inmediatamente la nueva función de cifrado. Para que puedas seguir accediendo al sitio desde el site central, comprueba que la opción «Encryption» esté configurada en «Encrypt data using TLS» en el menú bajo «Setup > General > Distributed Monitoring»: Comprueba esto y, si es necesario, configura la opción como se muestra en la siguiente captura de pantalla:

El último paso es el descrito anteriormente; aquí también tienes que marcar primero la CA del site remoto como de confianza.

Todos los accesos a un host supervisado se realizan siempre desde el sitio al que está asignado el host. Esto se aplica no solo a la monitorización propiamente dicha, sino también al descubrimiento de servicios, la página de Diagnósticos, las notificaciones, los alert handlers y todo lo demás. Este punto es muy importante, ya que no se da por sentado que el site central tenga realmente acceso a este host.

Algunas de las vistas estándar se agrupan según el site desde el que se realizará la monitorización del host; esto se aplica, por ejemplo, a All hosts:

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

Esta información suele estar disponible para usarla en una columna al crear tus propias vistas de tabla. También hay un filtro con el que se puede filtrar una vista de tabla de los hosts de un site específico:

Hay un snap-in de Site status para la barra lateral que se puede añadir usando . Esto muestra el estado de cada sitio. También ofrece 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 aparecerán marcados con el estado «». Con esto también puedes desactivar un sitio de que esté generando tiempos de espera, evitando así tiempos de espera innecesarios. Esta desactivación no es lo mismo que desactivar la conexión de Livestatus mediante la configuración de conexión en Setup. Aquí, la «desactivación» solo afecta al usuario que está conectado actualmente y tiene una función puramente visual. Al hacer clic en el nombre de un sitio, se mostrará una vista de tabla de todos sus hosts.

En una monitorización distribuida, el snap-in «Master control» tiene un aspecto diferente. Cada sitio tiene su propio switch global:

Si supervisas con un clúster HA de Checkmk, los nodos individuales del clúster deben asignarse al mismo sitio 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 sitio correspondiente.

Algunos check plugins utilizan datos piggyback, por ejemplo, para asignar datos de monitorización que se han «acoplado» desde un host a las máquinas virtuales individuales. En la monitorización distribuida, el host piggyback —es decir, el host que recibe los datos piggyback— y los hosts que dependen de él —como consumidores reales de los datos piggyback— no siempre se monitorizan desde el mismo site. En estos casos, se puede activar una asignación de datos piggyback entre sitios.

Para habilitar esta comunicación, solo tienes que asegurarte de que el puerto del broker de mensajes esté configurado correctamente en todos los sites participantes y de que el piggyback hub esté habilitado.

Deberías check esto a más tardDisablede que veas aquí:

El tráfico de datos suele crear un cuello de botella en la comunicación. Si los datos van y vienen de un punto a otro, esto puede provocar rápidamente una avalancha de datos y, por lo tanto, una sobrecarga de la red de comunicación. Por eso, es recomendable reducir el número de canales de comunicación y mantener el intercambio de datos principalmente dentro de una red local. Así pues, para reducir la carga en tu sitio central u optimizar el tráfico de red, también puedes permitir que los sitios remotos se comuniquen directamente entre sí (conexión entre pares). Como requisito previo para ello, ambos sitios remotos deben haber sido configurados por el sitio central, es decir, Push configuration to this site debe estar activado para ambos tal y como se describe en la sección Asignación de sitios remotos al sitio central.

En Setup > General > Distributed monitoring, selecciona el elemento de menú «Connections > Add peer-to-peer message broker connection». Asigna aquí un ID único y selecciona los dos sitios para la conexión directa. Asegúrate de seguir las instrucciones de la ayuda en línea.

El inventario de HW/SW de Checkmk también funciona en entornos distribuidos. Para ello, los datos de inventario del directorio ~/var/check_mk/inventory deben transmitirse regularmente desde los sitios remotos al site central. Por motivos de rendimiento, la interfaz de usuario siempre accede a este directorio de forma local.

En las ediciones comerciales, la sincronización se lleva a cabo automáticamente en todos los sitios conectados mediante el proxy Livestatus.

Si ejecutas el inventario con Checkmk Community en sistemas distribuidos, debes replicar el directorio regularmente en el site central con tus propias herramientas (por ejemplo, con rsync).

Incluso cuando todos los sitios se realizan tareas de monitorización de forma centralizada, es perfectamente posible realizar un inicio de sesión en la interfaz de un sitio individual y, a menudo, también es lo más adecuado. Por este motivo, Checkmk garantiza que la contraseña de un usuario sea siempre la misma en todos los sitios.

Un cambio de contraseña realizado por el administrador surtirá efecto automáticamente tan pronto como se comparta con todos los sitios mediante Activate pending changes.

Un cambio realizado por el propio usuario a través de la barra lateral de en su configuración personal funciona de forma algo diferente. Esto no puede ejecutar un comando «Activate pending changes», ya que el usuario, por supuesto, no tiene permiso general para esta función. En tal caso, Checkmk compartirá automáticamente la contraseña cambiada en todos los sitios, de hecho, justo después de que se haya guardado.

Como todos sabemos, las redes nunca están disponibles al 100 %. Si no se puede acceder a un sitio en el momento del cambio de contraseña, este no recibirá la nueva contraseña. Hasta que el administrador ejecute correctamente un comando «Activate pending changes», o hasta el siguiente cambio de contraseña que se realice con éxito, este sitio mantendrá la contraseña antigua para el usuario. Un icono de estado informará al usuario del estado de la sincronización de la contraseña en los sitios individuales.

Es obvio que las etiquetas del host utilizadas en el sitio remoto también deben ser conocidas por el site central para que puedan transferirse. Checklas antes de la migración y añade manualmente al site central cualquier etiqueta que falte. Aquí es esencial que haya coincidencia entre los ID de las etiquetas; el título de la etiqueta es irrelevante.

A continuación, mueve los hosts y las reglas al entorno de configuración del site central. Esto solo funciona para los hosts y las reglas que están en subcarpetas (es decir, no en la carpeta Main). Los hosts de la Carpeta principal deben moverse primero a una subcarpeta del site remoto a través de Setup > Hosts > Hosts.

La migración propiamente dicha se puede realizar de forma muy sencilla copiando los directorios correspondientes. Cada carpeta del entorno de configuración se corresponde con un directorio dentro de ~/etc/check_mk/conf.d/wato/. Estos se pueden copiar utilizando la herramienta que prefieras (por ejemplo, scp) desde el sitio vinculado a la misma ubicación en el site central. Si ya existe allí un directorio con el mismo nombre, simplemente cámbiale el nombre. Ten en cuenta que el site central también utiliza los usuarios y grupos de Linux.

Tras la copia, los hosts aparecerán en el site central Setup, así como las reglas que hayas creado en estas carpetas. Las propiedades de las carpetas también se incluirán en la copia. Estas se pueden encontrar en el directorio del archivo oculto .wato.

Para que los atributos de las funciones de la carpeta principal del site central se hereden correctamente, como paso final tras la migración, debes abrir y guardar una vez las características de las carpetas principales ; de este modo, se volverán a definir los atributos del host.

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

Selecciona la configuración «Use Livestatus Proxy-Daemon» para la conexión a los sitios remotos en lugar de «Connect via TCP»:

Los detalles del host y el 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 sitio de destino.

El grupo 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 se pueden procesar simultáneamente. Esto limita indirectamente el número de usuarios. En situaciones en las que todos los canales están reservados, esto no provocará un error de inmediato. La GUI espera un tiempo determinado a que haya un canal libre. La mayoría de las consultas solo requieren unos pocos milisegundos.

Si la GUI tiene que esperar más de unTimeout waiting for a free channele por un canal, se interrumpirá con un error y el usuario recibirá un mensaje de error. En tal caso, se debe aumentar el número de conexiones. Ten en cuenta, sin embargo, que en el site remoto se deben permitir suficientes conexiones entrantes paralelas; esto está configurado en 20 por defecto. Esta configuración se encuentra en las opciones globales, en «Monitoring core > Maximum concurrent Livestatus connections».

El «Regular heartbeat» proporciona una monitorización constante de las conexiones directamente a nivel de protocolo. En este proceso, el proxy envía regularmente una sencilla consulta «Livestatus» a la que el site remoto debe responder en un 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 sean realmente accesibles, pero el core de monitorización ya no responda.

Si no llega ninguna 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 ocurre de forma proactiva, es decir, sin que el usuario tenga que abrir una ventana de la GUI. De esta forma, las interrupciones se detectan rápidamente y, mediante una recuperación, las conexiones se restablecen de inmediato y, en el mejor de los casos, están disponibles antes incluso de que el usuario se dé cuenta de la interrupción.

El «Caching» garantiza que las consultas estáticas solo tengan que ser respondidas una vez por el site remoto y, a partir de ese momento, puedan responderse directamente y de forma local, sin demora. Un ejemplo de esto es la lista de hosts supervisados que requiere Quicksearch.

El proxy Livestatus tiene su propio archivo de registro: ~/var/log/liveproxyd.log. En un site remoto correctamente configurado con cinco canales (estándar), tendrá un aspecto similar a este:

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

Y cuando un site está actualmente detenido, el estado se verá así:

Aquí el estado es «starting». El proxy está, por lo tanto, 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 hosts y servicios en el formato de configuración de Nagios. Además, redirige la salida de livedump -TC a un archivo:

El inicio del archivo tendrá un aspecto similar a este:

Envía el archivo al site central (por ejemplo, con scp) y guárdalo allí en el directorio ~/etc/nagios/conf.d/ – donde Nagios espera encontrar los datos de configuración de los hosts y servicios. Elige un nombre de archivo que termine en .cfg, por ejemplo, ~/etc/nagios/conf.d/config-myremote1.cfg. Si es posible acceder por SSH desde el sitio remoto al site central, puedes hacerlo, por ejemplo, como se muestra a continuación:

Ahora inicia sesión en el site central y activa los cambios:

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

Notas:

Una vez que los hosts sean visibles en el site central, tendremos que configurar una transmisión (periódica) del estado de monitorización de los remotos. Vuelve a crear un archivo con `livedump`, pero esta vez sin opciones secundarias:

Este archivo contiene los estados de todos los hosts y servicios en un formato que Nagios puede leer directamente a partir de los resultados de las checkings. El inicio de este archivo tiene un aspecto similar a este:

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 similar a este:

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 por completo y ya se puede leer:

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

A partir de ahora, la transmisión del estado debe realizarse con regularidad. Puedes utilizar un script para repetir los pasos descritos anteriormente a intervalos que elijas. En lugar de copiar los datos a través de scp, tu script se puede ejecutar directamente desde el site central para que pueda recibir datos de estado o configuración a través de ssh.

Hay un script para realizar estas acciones disponible en GitHub, en el directorio treasures.

La configuración y el volcado de estado también se pueden restringir utilizando los filtros de Livestatus. Por ejemplo, podrías limitar los hosts a los miembros del grupo del host mygroup:

Las ediciones comerciales ofrecen un mecanismo integrado para notificaciones centralizadas que se puede activar individualmente para cada sitio remoto. Estos sitios remotos envían entonces todas las notificaciones al site central para su posterior procesamiento. La notificación centralizada es, por lo tanto, independiente de si la monitorización distribuida se ha configurado de la forma estándar, con CMCDump o mediante una combinación de estos procedimientos. Técnicamente hablando, el servidor de notificaciones central ni siquiera tiene que estar literalmente en el «centro». Esta tarea puede asumirla cualquier sitio de Checkmk.

Si un sitio remoto se ha configurado en «reenvío», todas las notificaciones se reenviarán directamente al sitio central tal y como lo harían desde el core —prácticamente en formato sin procesar—. Una vez allí, las reglas de notificación evaluarán a quién se debe notificar realmente y cómo. Los scripts de notificación necesarios se ejecutarán en el sitio central.

Los spoolers de notificaciones de los sitios remotos y centrales (de notificaciones) se comunican entre sí a través de TCP. Las notificaciones se envían desde los sitios remotos al sitio central. El sitio central realiza un Reconocimiento a los remotos para indicar que se han recibido las notificaciones, lo que evita que se pierdan incluso si se interrumpe la conexión TCP.

Hay dos alternativas para establecer una conexión TCP:

Por lo tanto, no hay ningún obstáculo para reenviar notificaciones si, por motivos de red, solo es posible establecer conexiones en una dirección específica. Las conexiones TCP son supervisadas por el spooler mediante una señal de latido y se restablecen inmediatamente cuando es necesario, no solo en el evento de una notificación.

Dado que los sitios remotos y el sitio central requieren ajustes globales diferentes para el spooler, debes realizar ajustes específicos para cada sitio en todos los sitios remotos. La configuración del sitio central se realiza utilizando los ajustes globales habituales. Nota: estos ajustes serán heredados automáticamente por todos los sitios 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 sitios remotos.

Paso 1: En el site remoto, edita la configuración global específica del site «Notifications > Notification Spooler Configuration» y activa «Accept 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» solo en el site remoto, selecciona la opción «Forward 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 otros sitios remotos según sea necesario):

Paso 4: Establece la configuración global «Notification Spooling» en «Asynchronous 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 sitio remoto hacia fuera, el procedimiento es idéntico, diferenciándose de la descripción anterior únicamente por el simple intercambio de los roles de site central y remoto.

También es posible una combinación de los dos procedimientos. En tal caso, el site central debe configurarse para que escuche las conexiones entrantes y también se conecte a los sitios remotos. Sin embargo, en toda relación central/remota, ¡solo uno de los dos puede establecer la conexión!

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

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

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

Para probarlo, selecciona cualquier servicio remoto sujeto a monitorización y configúralo 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 se verá así en el site remoto:

En la configuración global puedes cambiar tanto el archivo de registro normal para las notificaciones (notify.log) como el archivo de registro del spooler de notificación a un nivel de registro más alto.

Una vez que hayas configurado todo tal y como se describe, verás que en el site central, y respectivamente en los remotos, aparecerá un nuevo servicio que sin duda debes incluir en la monitorización. Este supervisa el spooler de notificación y sus conexiones TCP. De este modo, cada conexión se supervisará dos veces: una vez por el site central y otra por el site remoto: