Notificaciones

En la configuración por defecto de Checkmk, un usuario recibirá notificaciones por correo electrónico cuando se cumplan los siguientes requisitos previos:

Para que el envío de correos electrónicos se realice correctamente, tu servidor Checkmk debe tener una configuración de servidor SMTP en funcionamiento. Dependiendo de tu distribución de Linux, ésta podría utilizar, por ejemplo, Postfix, Qmail, Exim o Nullmailer. La configuración se implementará con los recursos de tu distribución de Linux.

Por lo general, la configuración se limita a registrar un "smarthost" (también conocido como servidor de retransmisión SMTP) al que se dirigirán todos los correos electrónicos. Éste será el servidor de correo SMTP interno de tu empresa. Por regla general, los smarthost no requieren autenticación en una LAN, lo que simplifica las cosas. En algunas distribuciones, el smarthost se consultará durante la instalación. Con el appliance Checkmk se puede configurar el smarthost cómodamente a través de la interfaz web.

Puedes probar el envío de correos electrónicos fácilmente con el comando mail en la línea de comandos. Dado que existen numerosas implementaciones diferentes para este comando en Linux, para su estandarización Checkmk proporciona la versión del proyecto Heirloom mailx directamente en la ruta de búsqueda del usuario del site (como ~/bin/mail). El archivo de configuración correspondiente es ~/etc/mail.rc. La mejor forma de probarlo es como usuario del site, ya que los script de notificación se ejecutarán posteriormente con los mismos permisos.

El contenido del correo electrónico se lee de la entrada estándar, el asunto se especifica con -s, y la dirección del destinatario simplemente se añade como argumento al final de la línea de comando:

El correo electrónico debería entregarse sin demora. Si esto no funciona, puedes encontrar información en el archivo de registro del servidor SMTP en el directorio /var/log (ver archivos y directorios).

La dirección de correo electrónico y el grupo de contacto de un usuario se definen en la administración de usuarios:

En un site Checkmk recién generado, inicialmente sólo existe el grupo de contacto Everything. Los miembros de este grupo son automáticamente responsables de todos los host y servicios, y serán notificados de cada evento de monitorización relevante por correo electrónico.

Nota: Si tu instalación de Checkmk se ha generado con una versión anterior, es posible que este grupo también se llame Everybody. Sin embargo, esto es ilógico, ya que este grupo no contiene a todos los usuarios, sino a todos los hosts. Aparte de la diferencia de nombres, la función es la misma.

En lugar de correo electrónico o SMS, también puedes enviar notificaciones a un sistema de tickets (como Jira o ServiceNow), a un mensajero (Slack, Mattermost) o a un motor de eventos (Consola de eventos). Hay un método de notificación distinto para cada uno de estos casos especiales, que puede seleccionarse en la regla de notificación. Sin embargo, debes tener en cuenta los dos puntos siguientes al crear la regla:

Para probar las reglas de notificación, Checkmk ofrece una herramienta inteligente con Test notifications. Puedes utilizarla para simular una notificación para un host o servicio y reconocer cuáles de tus reglas de notificación son eficaces. Además de la simulación, también puedes hacer que se envíe la notificación por correo electrónico.

La forma más rápida de acceder a la prueba de notificación es a través de Setup > Events > Notifications y del botón Test notifications. Además, hay otras opciones de llamada desde algunas vistas de monitorización (lista de servicios y detalles de servicios) y en la Configuración (propiedades del host), en cada caso en el menú Host > Test notifications.

En primer lugar, haz clic en uno de los dos botones para decidir si la notificación es para un Host o un Service. A continuación, selecciona de qué host o servicio debe ser. Puedes añadir una descripción del evento en Plugin output. Como evento puedes seleccionar un cambio de estado o el inicio de un tiempo de mantenimiento programado. Utiliza el checkbox Send out HTML/ASCII email notification according to notification rules para especificar si la notificación sólo se simula o se envía realmente.

Por último, en Advanced condition simulation hay otras dos opciones con las que puedes definir el tiempo y el número de notificaciones. Esto te permite probar reglas de notificación que sólo se aplican durante un periodo determinado (por ejemplo, fuera del horario laboral) o que inician una escalada tras un número especificado de notificaciones repetidas.

Haz clic en Test notifications para iniciar la prueba - y también el envío de correo electrónico, si has seleccionado esta opción. El diálogo Test notifications se oculta y se muestran los resultados:

En primer lugar aparece el resumen. En Analysis results puedes ver cuántas reglas de notificación se aplican y cuántas notificaciones se derivan de ellas. Si has seleccionado Enviar notificación, aquí aparece el mensaje correspondiente Notifications have been sent, que debe dar lugar inmediatamente a un correo electrónico para este problema.

La línea inferior resume las notificaciones generadas a partir de tus entradas. Haciendo clic en el icono, puedes mostrar el contexto de la notificación. Esto te permite ver las variables del entorno y sus valores que son válidos en el contexto de esta notificación.

A continuación, las dos secciones siguientes muestran más detalles:

En Resulting notifications puedes ver a quién y cómo se envían las notificaciones. También recibirás esta información sobre la simulación si no has seleccionado enviar la notificación.

En Global notification rules se enumeran las reglas de notificación, que se presentan con más detalle en el capítulo siguiente. En este punto, sólo es importante la primera columna de la tabla, que utiliza iconos para indicar cuáles de las reglas se aplican y cuáles no . En el ejemplo, la primera regla no se aplica porque evalúa los cambios de estado de los host, pero el evento es un cambio de estado de un servicio.

Al enviar correos electrónicos HTML, puede que desees añadir información adicional o definir de forma flexible una dirección de respuesta (Reply to) a un contacto concreto para cualquier consulta. Para ello, existe la regla Setup > Services > Service monitoring rules > Parameters for HTML Email, y en las reglas de notificación el método de notificación de correo electrónico HTML. Con estas reglas puedes añadir una serie de parámetros, como la dirección de respuesta, campos adicionales con detalles o texto libre formateado como HTML.

Ten en cuenta que en el campo Add HTML section above table (e.g. title, description…​), por motivos de seguridad, sólo se permite un pequeño conjunto de tags HTML, que son los siguientes

Como es habitual con todas las reglas de Checkmk, es posible una aplicación de granulación muy fina, de modo que puedas individualizar un conjunto detallado de notificaciones a hosts y servicios según tus necesidades.

Checkmk está configurado "por defecto" para que, cuando se produzca un evento de monitorización, se envíe un correo electrónico de notificación a todos los contactos del host o servicio afectado. Esto es, sin duda, sensato en un principio, pero en la práctica surgen muchos otros requisitos, por ejemplo:

Checkmk te proporciona la máxima flexibilidad en la aplicación de estos requisitos mediante su mecanismo basado en reglas. Introduce la configuración con Setup > Events > Notifications.

Nota: Cuando abras la página Notification configuration por primera vez, verás una advertencia sobre la "dirección de correo electrónico de reserva" no configurada. Puedes ignorar este aviso por el momento. Hablaremos de ello más adelante.

En la configuración de notificación, gestionas la cadena de reglas de notificación, que determinan a quién se debe notificar y cómo. Cuando se produce cualquier evento de monitorización, esta cadena de reglas se ejecuta de arriba abajo. Cada regla tiene una condición que decide si la regla se aplica realmente a la situación en cuestión.

Si se cumple la condición, la regla determina dos cosas:

Importante: A diferencia de las reglas para host y servicios, aquí la evaluación también continúa después de que se haya cumplido la regla aplicable. Las reglas posteriores pueden añadir más notificaciones. Las notificaciones generadas por las reglas anteriores también se pueden eliminar.

El resultado final de la evaluación de las reglas será una tabla con una estructura parecida a ésta

Ahora, para cada entrada de esta tabla se invocará el script de notificación que realmente ejecuta la notificación al usuario adecuada al método.

Si tienes un Checkmk recién instalado, se habrá predefinido precisamente una regla:

Esta regla define el comportamiento por defecto descrito anteriormente. Su estructura es la siguiente

Como de costumbre, puedes editar la regla , clonarla (copiarla) , eliminarla o crear una regla nueva. Cuando tengas más de una regla, puedes cambiar su orden de proceso arrastrándolas y soltándolas con el icono .

Nota: Los cambios en las reglas de notificación no requieren su activación, sino que entran en vigor inmediatamente.

A continuación te presentamos la estructura general de las reglas de notificación con las definiciones de las propiedades generales, métodos, contactos y condiciones.

Como ya se ha mencionado en la selección del método de notificación, también encontrarás la opción de selección Cancel previous notifications. Para poder entender el funcionamiento de una regla de este tipo, lo mejor es visualizar la tabla de notificaciones. Suponiendo que el proceso de las reglas para un evento de monitorización concreto se ha completado parcialmente, y que debido a una serie de reglas se han activado las tres notificaciones siguientes:

Ahora viene la siguiente regla con el método SMS y la selección Cancel previous notifications. La selección de contactos elige el grupo "Windows", al que pertenece Bruno Weizenkeim. Como resultado de esta regla, la entrada "Bruno Weizenkeim / SMS" se elimina de la tabla, que queda así:

Si una regla posterior vuelve a definir una notificación por SMS para Bruno, esta regla tendrá prioridad y el SMS se añadirá de nuevo a la tabla.

En resumen:

Quien configura también puede cometer errores. Un posible error en la configuración de la notificación podría ser que se descubriera un problema crítico de monitorización, pero que no entrara en vigor ni una sola regla de notificación.

Para protegerte de un caso así, Checkmk te ofrece la opción Fallback email address for notifications. La encontrarás en Setup > General > Global settings, en la sección Notifications. Introduce aquí una dirección de correo electrónico. Esta dirección de correo electrónico recibirá entonces las notificaciones a las que no se aplique ninguna regla de notificación.

Nota: También puedes hacer que un usuario sea el destinatario en su configuración personal. La dirección de correo electrónico almacenada con el usuario se utilizará como dirección de reserva.

Sin embargo, la dirección alternativa sólo se utilizará si no se aplica ninguna regla, ¡no cuando no se haya activado ninguna notificación! Como mostramos en el capítulo anterior, la supresión explícita de notificaciones es deseable, no es un error de configuración.

La introducción de una dirección alternativa se "recomendará" en la página Notification configuration con una advertencia en pantalla:

Si -por el motivo que sea- sólo quieres librarte de la advertencia, pero al mismo tiempo no quieres recibir correos electrónicos en la dirección de reserva, introduce primero una dirección de reserva de todos modos y luego crea una nueva regla como primera regla, que elimine todas las notificaciones anteriores. Esta regla no es efectiva en la configuración de notificaciones, ya que aquí todavía no se han creado notificaciones. Pero con esto puedes asegurarte de que al menos una regla se aplicará siempre, permitiendo así eliminar esta advertencia.

Desaconsejamos explícitamente este enfoque, ya que podrías pasar por alto lagunas en tu secuencia de reglas.

Una función útil del sistema de notificaciones de Checkmk es aquella con la que los usuarios -incluso sin derechos de administrador- pueden personalizar las notificaciones. Los usuarios pueden:

El punto de entrada desde el punto de vista del usuario es el menú Usuario, y allí la entrada Notification rules. En la página Your personal notification rules, se puede crear una nueva regla con Add rule.

Las reglas personalizadas se estructuran como las reglas normales, con una diferencia: no contienen una selección de contacto. El propio usuario se selecciona automáticamente como contacto. Esto significa que un usuario sólo puede añadir o eliminar notificaciones para sí mismo.

Sin embargo, el usuario sólo puede borrar notificaciones si la opción allow users to deactivate this notification está activada en la regla que las crea:

En el orden de las reglas de notificación, las reglas personalizadas siempre vienen después de las reglas globales y, por tanto, pueden ajustar la tabla de notificaciones que se ha generado hasta el momento. Así pues, salvo en el caso del bloqueo por eliminación que acabamos de describir, las reglas globales siempre se aplican como la configuración por defecto que puede personalizar el usuario.

Si quieres impedir totalmente la personalización, puedes revocar el permiso General Permissions > Edit personal notification settings del rol user.

Como administrador, puedes mostrar todas las reglas de usuario si en el menú seleccionas Display > Show user rules:

Después de las reglas globales, se enumeran las reglas de usuario, que también puedes editar con .

La desactivación completa de las notificaciones por parte de un usuario está protegida con el permiso General Permissions > Disable all personal notifications, que está establecido por defecto en no para el rol de usuario user. Un usuario sólo verá los checkbox correspondientes en su configuración personal si asignas explícitamente este derecho al rol user:

Como administrador con acceso a la configuración personal del usuario, puedes llevar a cabo acciones de desactivación en nombre del usuario, incluso si el permiso descrito anteriormente no está presente. Puedes encontrar esta configuración en Setup > Users > Users y luego en las propiedades del perfil del usuario. Con esto, por ejemplo, puedes silenciar muy rápidamente las notificaciones de un compañero de vacaciones, sin necesidad de alterar la configuración real.

Gran parte de la complejidad del sistema de notificaciones de Checkmk se debe a sus numerosas opciones de ajuste, con las que se pueden evitar notificaciones sin importancia. Además, el núcleo de monitorización tiene una inteligencia integrada que suprime determinadas notificaciones por defecto. En este capítulo queremos tratar todos estos aspectos.

Cuando un host o un servicio se encuentra en un tiempo de mantenimiento programado, se suprimirán las notificaciones del objeto. Ésta es -junto con una evaluación correcta de las disponibilidades- la razón más importante para la provisión real de tiempos de mantenimiento en la monitorización. Los siguientes detalles son relevantes al respecto:

Puedes definir un periodo de notificación para cada host y servicio durante la configuración. Se trata de un periodo de tiempo que define el marco temporal en el que debe limitarse la notificación.

La configuración se realiza utilizando el Monitoring Configuration > Notification period for hosts, o respectivamente el conjunto de reglas Notification period for services, que puedes encontrar rápidamente mediante la búsqueda en el Menú de configuración. Un objeto que no se encuentre actualmente en un periodo de notificación se marcará con un icono de pausa gris .

No se notificarán los eventos de monitorización de un objeto que no esté actualmente en su periodo de notificación. Dichas notificaciones se "reemitirán" cuando el periodo de notificación vuelva a estar activo, si el host/servicio sigue en estado problemático. Sólo se notificará el estado más reciente, aunque se hayan producido múltiples cambios en el estado del objeto durante el tiempo transcurrido fuera del periodo de notificación.

Por cierto, en las reglas de notificación también es posible restringir una notificación a un periodo de tiempo concreto. De esta forma puedes restringir adicionalmente los intervalos de tiempo. Sin embargo, ¡las notificaciones que se hayan descartado debido a una regla con condiciones de tiempo no se repetirán automáticamente más adelante!

Si un host ha fallado por completo, o al menos es inaccesible para la monitorización, es obvio que sus servicios ya no se pueden monitorizar. Los checksactivos registrarán entonces, por regla general, CRIT o UNKNOWN, ya que estarán intentando acceder activamente al host y, por tanto, se encontrarán con un error. En tal situación, todos los demás checks -por tanto, la gran mayoría- se omitirán y, por tanto, permanecerán en su estado anterior. Éstos se marcarán con el icono de tiempo stale.

Naturalmente, sería muy engorroso que todas las comprobaciones activas en tal estado notificaran sus problemas. Por ejemplo, si un servidor web no es accesible -y esto ya se ha notificado- no sería muy útil generar adicionalmente un correo electrónico para cada uno de sus servicios HTTP dependientes.

Para minimizar estas situaciones, como principio básico, el núcleo de monitorización sólo genera notificaciones para los servicios si el host está en estado UP. Ésta es también la razón por la que la accesibilidad al host se verifica por separado. Si no se configura de otro modo, esta verificación se conseguirá con un Smart Ping o ping.

Si utilizas Checkmk Raw (o una de las ediciones comerciales con núcleo Nagios), en casos aislados puede ocurrir, no obstante, que un problema en el host genere una notificación para un servicio activo. El motivo es que Nagios considera que los resultados de las comprobaciones del host siguen siendo válidos durante un breve periodo de tiempo en el futuro. Si sólo han transcurrido unos segundos entre el último ping con éxito al servidor y la siguiente comprobación activa, Nagios puede seguir evaluando el host como UP aunque en realidad esté DOWN. En cambio, el Checkmk Micro Core (CMC) mantendrá la notificación del servicio en modo "espera" hasta que se haya verificado el estado del host, minimizando así de forma fiable las notificaciones no deseadas.

Imagina que falla un importante router de la red de una empresa con cientos de hosts. Todos sus hosts dejarán de estar disponibles para la monitorización y pasarán a estar DOWN. Por tanto, se activarán cientos de notificaciones. Esto no es bueno.

Para evitar estos problemas, el router puede definirse como host padre para sus hosts. Si hay hosts redundantes, también pueden definirse varios padres. En cuanto todos los padres entren en estado DOWN, los hosts que ya no estén accesibles se marcarán con el estado UNREACH y se suprimirán sus notificaciones. El problema con el propio router seguirá notificándose, por supuesto.

Por cierto, la CMC funciona internamente de un modo ligeramente distinto a Nagios. Para reducir las falsas alarmas, pero seguir procesando notificaciones auténticas, presta mucha atención a los tiempos exactos de los correspondientes checks de host. Si falla un check de host, el núcleo esperará al resultado del check de host en el host padre antes de generar una notificación. Esta espera es asíncrona y no tiene ningún efecto en la monitorización general. De este modo, las notificaciones de los hosts pueden sufrir retrasos mínimos.

Con los conjuntos de reglas Enable/disable notifications for hosts, o Enable/disable notifications for services, respectivamente, puedes especificar host y servicios para los que, en general, no deben emitirse notificaciones. Como ya se ha dicho, el núcleo suprime las notificaciones. Una regla de notificación posterior que se "suscriba" a las notificaciones de dichos servicios no será efectiva, ya que las notificaciones simplemente no se generan.

También es posible desactivar temporalmente las notificaciones para host o servicios individuales mediante un comando.

Sin embargo, esto requiere que el permiso Commands on host and services > Enable/disable notifications esté asignado al rol de usuario. Por defecto, este no es el caso para ningún rol.

Con el permiso asignado, puedes desactivar (y posteriormente activar) las notificaciones de hosts y servicios con el comando Commands > Notifications:

Dichos host o servicios se marcarán con un icono.

Dado que los comandos -a diferencia de las reglas- no requieren permisos de configuración ni activar cambios, pueden ser una solución rápida para reaccionar rápidamente ante una situación.

Importante: A diferencia de los tiempos de inactividad programados, las notificaciones desactivadas no influyen en las evaluaciones de disponibilidad. Si durante una interrupción no planificada sólo quieres desactivar las notificaciones sin querer distorsionar las estadísticas de disponibilidad, ¡no debes registrar un tiempo de mantenimiento programado!

En el snap-in Master control de la barra lateral encontrarás un interruptor master para Notifications:

Este interruptor es increíblemente útil si planeas hacer cambios mayores en el sistema, durante los cuales un error podría, dadas las circunstancias, forzar a muchos servicios a entrar en estado CRIT. Puedes utilizar el interruptor para evitar molestar a tus colegas con una avalancha de correos electrónicos inútiles. Recuerda volver a activar las notificaciones cuando hayas terminado.

Cada site de una monitorización distribuida tiene uno de estos conmutadores. Desactivar las notificaciones del site central sigue permitiendo que los sites remotos activen las notificaciones, aunque éstas se dirijan y envíen desde el site central.

Importante: Las notificaciones que se hubieran activado durante el tiempo en que las notificaciones estuvieron desactivadas no se repetirán más tarde cuando se vuelvan a activar.

Es posible que tengas servicios que de vez en cuando entran en estado de problema durante periodos cortos, pero las paradas son muy breves y no son críticas para ti. En estos casos, las notificaciones son muy molestas, pero se suprimen fácilmente. Los conjuntos de reglas Delay host notifications y Delay service notifications sirven para esta situación.

Aquí especificas un tiempo en minutos, y la notificación se retrasará hasta que haya transcurrido ese tiempo. Si el estado OK / UP vuelve a producirse antes de ese momento, no se activará ninguna notificación. Naturalmente, esto también significa que se retrasará la notificación de un verdadero problema.

Obviamente, aún mejor que retrasar las notificaciones sería eliminar la causa real de los problemas esporádicos, pero eso es, por supuesto, otra historia...

Otro método muy similar para retrasar las notificaciones es permitir múltiples intentos de check cuando un servicio entra en estado problemático. Esto se consigue con el conjunto de reglas Maximum number of check attempts for hosts, o respectivamente, Maximum number of check attempts for service.

Si estableces aquí un valor de 3, por ejemplo, un check con resultado CRIT no desencadenará en un primer momento una notificación. Esto se denomina CRIT soft state. El hard state sigue siendo OK. Sólo si tres intentos sucesivos devuelven un estado no OK, el servicio pasará al hard state y se desencadenará una notificación.

A diferencia de las notificaciones diferidas, aquí tienes la opción de definir vistas para que no se muestren estos problemas. También se puede construir una Agregación BI para que sólo se incluyan los hard states, no los soft.

Cuando un host o un servicio cambia frecuentemente de estado en poco tiempo, se considera que está aleteando. Se trata de un estado real. El principio en este caso es la reducción de notificaciones excesivas durante las fases en las que un servicio no funciona (del todo) de forma estable. Estas fases también pueden evaluarse especialmente en las estadísticas de disponibilidad.

Los objetos inestables se marcan con el icono . Mientras un objeto sea inestable, los cambios de estado sucesivos no activan más notificaciones. Sin embargo, se activará una notificación cada vez que el objeto entre o salga del estado inestable.

El reconocimiento del estado inestable por parte del sistema puede verse influido de las siguientes formas:

Muestra la ayuda contextualizada con Help > Show inline help para más detalles sobre los valores personalizables.

Para algunos sistemas, puede tener sentido no limitarse a una única notificación cuando un problema persiste durante un periodo de tiempo más largo, por ejemplo, para hosts cuya etiqueta del host Criticality esté configurada como Business critical.

Para empezar, te mostraremos cómo ver el historial de notificaciones a nivel de host y de servicio en Checkmk para poder seguir el proceso de notificación.

Un evento de monitorización que hace que Checkmk active una notificación es, por ejemplo, el cambio de estado de un servicio. Puedes activar manualmente este cambio de estado con el comando Fake check results para realizar pruebas.

Para una prueba de notificación, puedes mover un servicio del estado OK a CRIT de esta forma. Si ahora visualizas las notificaciones de este servicio en la página de detalles del servicio con Service > Service Notifications, verás las siguientes entradas:

La entrada más reciente está al principio de la lista. Sin embargo, la primera entrada está al final, así que veamos las entradas individuales de abajo a arriba:

Para ayudar a la correcta comprensión de los contextos de las distintas opciones de configuración y condiciones básicas, y para permitir un diagnóstico preciso del problema cuando una notificación aparece o no como se esperaba, describiremos aquí todos los detalles del proceso de notificación, incluyendo todos los componentes implicados.

Nota: El historial de notificaciones que hemos mostrado anteriormente para un servicio también puede mostrarse para un host: en la página de detalles del host en el menú Host para el propio host ( elemento de menúNotifications of host ) y también para el host con todos sus servicios (Notifications of host & services).

En el sistema de notificación Checkmk intervienen los siguientes componentes:

Una vez que el núcleo ha generado una notificación raw, ésta se ejecuta a través de la cadena de reglas de notificación, lo que da como resultado una tabla de notificaciones. Junto a los datos de la notificación raw, cada notificación contiene la siguiente información adicional:

En una entrega síncrona, por cada entrada de la tabla se ejecutará un script de notificación apropiado. En una entrega asíncrona, la notificación se pasará como un archivo al spooler de notificación.

Una potente función complementaria de las ediciones comerciales es el spooler de notificación, que permite una entrega asíncrona de las notificaciones. ¿Qué significa asíncrona en este contexto?

Una entrega sincrónica es entonces factible si el script de notificación se ejecuta rápidamente y, sobre todo, no puede dar lugar a algún tipo de timeout. Con los métodos de notificación que acceden a los spoolers existentes, esto es un hecho. Los servicios de spool del sistema pueden utilizarse especialmente con el correo electrónico y los SMS. El script de notificación pasa un archivo al spooler: con este procedimiento no puede producirse ningún estado de espera.

Cuando utilices la entrega rastreable a través de SMTP u otros scripts que establezcan conexiones de red, debes emplear siempre la entrega asíncrona. Esto también se aplica a los scripts que envían mensajes de texto (SMS) a través de HTTP por internet. Los timeout al establecer una conexión con un servicio de red pueden tardar hasta varios minutos, provocando un atasco como el descrito anteriormente.

La buena noticia es que la entrega asíncrona está activada por defecto en Checkmk. Por un lado, el spooler de notificación (mknotifyd) también se inicia cuando se inicia el site, lo que puedes comprobar con el siguiente comando:

Por otro lado, la entrega asíncrona (Asynchronous local delivery by notification spooler) está seleccionada en Global settings > Notifications > Notification Spooling:

Todo el que trabaja con monitorización ha experimentado algún problema aislado que desencadena una auténtica avalancha de notificaciones (sucesivas). El principio del padre (host ) es una forma de reducirlas en determinadas circunstancias, pero desgraciadamente no ayuda en todos los casos.

Puedes tomar un ejemplo del propio proyecto Checkmk: una vez al día creamos paquetes de instalación de Checkmk para cada distribución de Linux compatible. Nuestra propia monitorización de Checkmk está configurada de modo que tenemos un servicio que sólo está OK si se ha construido correctamente el número correcto de paquetes. A veces puede ocurrir que un error general en el software obstaculice el empaquetado, provocando que 43 servicios entren en estado de CRIT simultáneamente.

Hemos configurado las notificaciones de forma que, en tal caso, sólo se envíe un único correo electrónico con una lista de las 43 notificaciones en secuencia, lo que, naturalmente, es más claro que 43 correos electrónicos individuales, y también reduce el riesgo de que "en el fragor de la batalla" se pase por alto un 44º correo electrónico perteneciente a otro problema muy distinto.

El modo de funcionamiento de esta notificación masiva es muy sencillo. Cuando se produce una notificación, al principio se retendrá durante un breve periodo de tiempo. Las notificaciones posteriores que se produzcan durante este tiempo se añadirán inmediatamente en el mismo correo electrónico. Esta recogida puede definirse para cada regla. Así, por ejemplo, durante el día puedes operar con correos electrónicos individuales, pero durante la noche con una notificación masiva. Si se activa una notificación masiva, generalmente se te ofrecerán las siguientes opciones:

El tiempo de espera puede configurarse como se desee. En muchos casos, basta con un minuto, ya que para entonces, como muy tarde, deberían haber aparecido todos los problemas relacionados. Por supuesto, puedes establecer un tiempo mayor, pero eso provocará un retraso fundamental en las notificaciones.

Como, naturalmente, no tiene sentido meterlo todo en el mismo saco, puedes especificar qué grupos de problemas deben notificarse colectivamente. La opción Host se utiliza con mucha frecuencia, ya que garantiza que sólo se agrupen las notificaciones del mismo host.

Aquí tienes algunos datos adicionales sobre las notificaciones masivas:

¿Qué ocurre cuando una notificación está dentro del periodo de notificación, pero la notificación masiva que la contiene -y que llega algo más tarde- está fuera del periodo de notificación? La situación inversa también es posible...

Aquí se aplica un principio muy simple: todas las configuraciones que restringen las notificaciones a periodos de tiempo sólo son válidas para la notificación real. La notificación masiva posterior siempre se entregará independientemente de todos los periodos de tiempo.

La monitorización sólo es útil cuando se puede confiar en ella. Para ello, es necesario que las notificaciones se reciban de forma fiable y rápida. Por desgracia, la entrega por correo electrónico no es del todo ideal. El envío suele procesarse pasando el correo electrónico al servidor SMTP local, que intenta entregarlo de forma autónoma y asíncrona.

Si se produce un error temporal (por ejemplo, si no se puede acceder al servidor SMTP receptor), el correo electrónico se pondrá en cola y más tarde se hará un nuevo intento. Este "más tarde" será, por regla general, al cabo de 15-30 minutos. Para entonces, ¡la notificación podría llegar demasiado tarde!

Si realmente no se puede entregar el correo electrónico, el servidor SMTP crea un bonito mensaje de error en su archivo de registro e intenta generar un correo electrónico de error para el "remitente". Pero el sistema de monitorización no es un remitente real y tampoco puede recibir correos electrónicos, por lo que tales errores simplemente desaparecen y entonces no hay notificaciones.

Importante: ¡las notificaciones rastreables no están disponibles para las notificaciones masivas!

Las ediciones comerciales ofrecen la posibilidad de un envío rastreable mediante SMTP. Esto lo hace intencionadamente sin la ayuda del servidor de correo local. En su lugar, el propio Checkmk envía el correo electrónico a tu smarthost mediante SMTP, y luego evalúa él mismo la respuesta SMTP.

De este modo, no sólo se tratan los errores SMTP de forma inteligente, sino que también se documenta con precisión una entrega correcta. Es un poco como una carta certificada: Checkmk recibe un recibo del smarthost SMTP (servidor receptor) que verifica que el correo electrónico ha sido aceptado, incluyendo un ID de correo.

Puedes seleccionar y configurar la entrega rastreable vía SMTP para el método de notificación correo electrónico HTML introduciendo el smarthost (con nombre y número de puerto) y los datos de acceso y el método de encriptación:

En el historial del servicio en cuestión, podrás hacer un seguimiento exacto de la entrega. Aquí tienes un ejemplo en el que un servicio -con fines de prueba- se configuró manualmente como CRIT. La captura de pantalla siguiente muestra las notificaciones de este servicio, que puedes visualizar en la página de detalles del servicio con Service > Service Notifications:

Aquí verás los cuatro pasos individuales en la secuencia cronológica de abajo a arriba, como ya los hemos presentado en el capítulo sobre el historial de notificaciones. La diferencia importante es que ahora puedes ver en la entrada superior que el correo electrónico se entregó correctamente al smarthost y su respuesta es success.

También puedes seguir los pasos individuales en el archivo notify.log. Las siguientes líneas pertenecen al último paso y contienen la respuesta del servidor SMTP:

El Message-ID 1BE667EE7D6 aparecerá en el archivo de registro del smarthost. Allí -si te preocupa- podrás investigar dónde ha llegado el correo electrónico. En cualquier caso, podrás demostrar que, y cuándo, el correo electrónico se envió correctamente desde Checkmk.

Repitamos la prueba anterior, pero esta vez con una contraseña falsamente configurada para la transferencia SMTP al smarthost. Aquí puedes ver en texto plano el mensaje de error SMTP Error: authentication failed del smarthost:

¿Qué se puede hacer con las notificaciones fallidas? Una vez más, notificar por correo electrónico no parece una buena solución. En su lugar, Checkmk muestra una clara advertencia con color de fondo rojo en la Vista general:

Aquí puedes

Importante: Ten en cuenta que la entrega directa por SMTP en situaciones de error puede hacer que el script de notificación se ejecute durante mucho tiempo y provocar un timeout. Por este motivo, te recomendamos encarecidamente que utilices el spooler de notificación y que selecciones una entrega asíncrona de notificaciones.

La conducta con errores repetibles (como un timeout SMTP) puede definirse con Global settings > Notifications > Notification spooler configuration por método de notificación:

Junto a un timeout opcional (el predeterminado es de 1 minuto) y un número máximo de reintentos, también se puede definir si se permite que el script se ejecute varias veces en paralelo y envíe así múltiples notificaciones (Maximum concurrent executions). Si el script de notificación es muy lento, puede tener sentido una ejecución en paralelo; sin embargo, el script debe estar programado de modo que las ejecuciones múltiples se ejecuten limpiamente (y, por ejemplo, que el script no se reserve ciertos datos para sí mismo).

Un envío múltiple en paralelo a través de SMTP no plantea problemas, ya que el servidor de destino puede gestionar varias conexiones en paralelo, lo que no ocurre cuando el envío se realiza directamente desde un SMS a través de un módem sin un spooler adicional, por lo que en este caso se debe mantener la configuración 1.

Hasta la fecha, sólo se ha implementado una entrega síncrona que incluya mensajes de error y trazabilidad para los correos electrónicos HTML. En el capítulo sobre cómo escribir tus propios scripts encontrarás cómo devolver un estado de error en un script de notificación escrito por ti mismo.

La notificación puede producirse de múltiples e individuales maneras. Ejemplos típicos son:

Por esta razón, Checkmk proporciona una interfaz muy sencilla que te permite escribir tus propios scripts de notificación, que pueden escribirse en cualquier lenguaje de programación compatible con Linux, aunque Shell, Perl y Python tienen juntos el 95 % del "mercado".

Los scripts estándar incluidos en Checkmk se encuentran en ~/share/check_mk/notifications. Este directorio es un componente del software y no debe modificarse. En su lugar, guarda tus propios scripts en ~/local/share/check_mk/notifications. Asegúrate de que tus scripts son ejecutables (chmod +x). Entonces se encontrarán automáticamente y estarán disponibles para su selección en las reglas de notificación.

Si deseas personalizar un script estándar, simplemente cópialo de ~/share/check_mk/notifications a ~/local/share/check_mk/notifications y realiza allí tus cambios en la copia. Si conservas el nombre original, tu script será sustituido automáticamente por la versión estándar y no será necesario realizar ningún cambio en las reglas de notificación existentes.

Con el software se incluyen algunos scripts de ejemplo más en ~/share/doc/check_mk/treasures/notifications. Puedes utilizarlos como plantillas para la personalización. La configuración generalmente se realizará directamente en el script -en los comentarios encontrarás consejos al respecto.

En el caso de una notificación, se llamará a tu script con los permisos del usuario del site. En las variables del entorno, (las que empiezan por NOTIFY_), recibirá toda la información sobre el host/servicio afectado, el evento de monitorización, los contactos a notificar y los parámetros especificados en la regla de notificación.

Los textos que el script escriba en la salida estándar (con print, echo, etc.), aparecerán en el archivo de registro del módulo de notificación ~/var/log/notify.log.

Los script de notificación tienen la opción de utilizar un código de salida para comunicar si se ha producido un error replicable o final:

Además, en todos los casos, la salida estándar del script de notificación, junto con el estado, se introducirá en el historial de notificaciones del host/servicio y, por tanto, será visible en la GUI.

Importante: ¡Las notificaciones rastreables no están disponibles para las notificaciones masivas!

El tratamiento de los errores de notificación desde el punto de vista del usuario se explicará en el capítulo sobre el envío rastreable a través de SMTP.

Como ejemplo, puedes crear un script que escriba toda la información sobre la notificación en un archivo. El lenguaje de codificación es el shell de Linux Bash:

A continuación, haz que el script sea ejecutable:

Aquí tienes un par de explicaciones sobre el script:

Para que el script sea utilizado, debes definirlo como un método en una regla de notificación. Los scripts escritos por ti mismo no tienen declaración de parámetros, por lo que faltarán todos los checkbox como los que se ofrecen, por ejemplo, en el método HTML Email. En su lugar, puedes introducir una lista de textos como parámetros que pueden estar disponibles como NOTIFY_PARAMETER_1, NOTIFY_PARAMETER_2, etc, para el script. Para una prueba, proporciona los parámetros Fröhn, Klabuster y Feinbein:

Ahora para probar, establece el servicio CPU load en el host myserver a CRIT- con el comando Fake check results. En el archivo de registro del módulo de notificación ~/var/log/notify.log verás entonces la ejecución del script incluyendo los parámetros y el archivo spool generado.:

El archivo ~/tmp/foobar.out contendrá ahora una lista alfabética de todas las variables del entorno Checkmk que incluyen información relativa a la notificación. Aquí puedes orientarte con qué valores están disponibles para tu script. He aquí las diez primeras líneas:

También puedes encontrar los parámetros:

En el ejemplo anterior has visto una serie de variables del entorno que se pasarán al script. Exactamente qué variables están disponibles depende del tipo de notificación, de la versión y edición de Checkmk y del core de monitorización utilizado(CMC o Nagios). Junto al truco con el comando env hay otras dos formas de obtener una lista completa de todas las variables:

A continuación hay una lista de las variables más importantes:

Si tu script debe soportar notificaciones masivas, tendrá que estar especialmente preparado, ya que el script debe entregar múltiples notificaciones simultáneamente. Por esta razón, una entrega utilizando variables del entorno tampoco funciona de forma práctica.

Dale un nombre a tu script en la tercera línea de la cabecera, como se indica a continuación: el módulo de notificación enviará entonces las notificaciones a través de la entrada estándar:

A través de la entrada estándar, el script recibirá bloques de variables. Cada línea tiene la forma: NAME=VALUE. Los bloques están separados por líneas en blanco. El carácter ASCII con el código 1 (\a) se utiliza para representar nuevas líneas dentro del texto.

El primer bloque contiene una lista de variables generales (por ejemplo, parámetros de llamada). Cada bloque posterior reúne las variables en una notificación.

La mejor recomendación es que lo pruebes tú mismo con una prueba sencilla que escriba los datos completos en un archivo para que puedas ver cómo se envían los datos. Para ello, puedes utilizar el siguiente script de notificación:

Prueba el script como se ha descrito anteriormente y activa además el Notification Bulking en la regla de notificación.

Tal y como se entrega, Checkmk ya proporciona toda una serie de scripts para conectarse a servicios de mensajería instantánea, plataformas de gestión de incidencias y sistemas de tickets populares y ampliamente utilizados. Puedes averiguar cómo utilizar estos scripts en los siguientes artículos:

Los archivos de registro del servidor SMTP son archivos de sistema y sus rutas absolutas se enumeran a continuación. La ubicación exacta de los archivos de registro dependerá de tu distribución de Linux.