 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
En Checkmk, una notificación significa que se informa activamente a los usuarios en caso de problemas u otros eventos en la monitorización. Esto se suele hacer mediante correos electrónicos. Sin embargo, también hay muchos otros métodos, como enviar SMS o reenviar a un sistema de tickets. Checkmk ofrece una interfaz sencilla para escribir scripts para tus propios métodos de notificación.
El punto de partida de cualquier notificación a un usuario es un evento notificado por el core de monitorización. En este artículo lo llamamos «evento de monitorización» para evitar confusiones con los eventos procesados por la Consola de eventos. Un evento de monitorización siempre está relacionado con un host o servicio concreto. Los posibles tipos de eventos de monitorización son:
Un cambio de estado, p. ej., OK → WARN
El cambio entre un estado estable y uno inestable (inestable) de
.El inicio o el final de un tiempo de mantenimiento programado
.El reconocimiento de un problema por parte de un usuario.
Una notificación activada manualmente mediante un comando de
.La ejecución de un alert handler de
.Un evento enviado para su notificación desde la Consola de eventos de
.
Checkmk utiliza un sistema basado en reglas que te permite crear notificaciones de usuario a partir de estos eventos de monitorización, y esto también se puede usar para implementar requisitos muy exigentes. Una simple notificación por correo electrónico —que en muchos casos es totalmente satisfactoria— se configura rápidamente.
Este artículo trata principalmente de los conceptos básicos y las preguntas generales sobre las notificaciones.
Si, por el contrario, prefieres empezar directamente con la implementación: Checkmk distingue generalmente entre dos formas de definir las notificaciones. Por un lado, las reglas para las notificaciones se definen de forma global. Estas reglas se aplican a todos los usuarios y grupos afectados en función del evento. La creación de estas notificaciones se describe en Configuración de notificaciones por reglas.
Al mismo tiempo, cada usuario tiene la opción de modificar la configuración de las notificaciones de forma individual. Por ejemplo, una persona de contacto puede desactivar el envío de notificaciones a su propia bandeja de entrada mientras está de vacaciones. Puedes leer cómo se pueden implementar estos ajustes personales en el artículo «Reglas de notificación personales».
2. ¿Notificar o no notificar (todavía)?
Las notificaciones son básicamente opcionales, y Checkmk se puede seguir utilizando de forma eficiente sin ellas. Algunas grandes organizaciones cuentan con una especie de panel de control en el que un equipo de operaciones tiene la interfaz de Checkmk bajo observación constante, por lo que las notificaciones adicionales son innecesarias. Si tu entorno de Checkmk aún está en construcción, debes tener en cuenta que las notificaciones solo serán de ayuda para tus compañeros cuando no se produzcan Falsas alarmas (falsos positivos), o solo de forma ocasional. Primero hay que familiarizarse con los valores umbral y el resto de ajustes, para que todos los estados estén en «OK» / «UP» —o, en otras palabras: que todo esté «en verde».
La aceptación del nuevo sistema de monitorización se desvanecerá rápidamente si cada día la bandeja de entrada se inunda con cientos de correos electrónicos inútiles.
El siguiente procedimiento ha demostrado ser eficaz para lograr un ajuste preciso en las notificaciones:
Paso 1: Realiza un ajuste preciso en la monitorización, por un lado, solucionando cualquier problema real que Checkmk haya detectado recientemente y, por otro lado, eliminando las Falsas alarmas. Hazlo hasta que todo esté «normalmente» OK / UP. Consulta la Guía para principiantes para ver algunas recomendaciones sobre cómo reducir las Falsas alarmas típicas.
Paso 2: A continuación, configura las notificaciones para que solo estén activas para ti. Reduce el «ruido» causado por problemas esporádicos y de corta duración. Para ello, ajusta los valores de umbral, utiliza la monitorización predictiva si es necesario, aumenta el número de intentos de comprobación o prueba con notificaciones retrasadas. Y, por supuesto, si hay problemas reales, intenta controlarlos.
Paso 3: Una vez que tu bandeja de entrada esté razonablemente tranquila, activa las notificaciones para tus compañeros. Crea grupos de contacto eficientes para que cada contacto solo reciba las notificaciones que le sean relevantes.
Estos procedimientos darán como resultado un sistema que proporciona información relevante que ayuda a reducir las interrupciones del servicio.
3. Cuándo se generan las notificaciones y cómo gestionarlas
3.1. Introducción
Gran parte de la complejidad del sistema de notificaciones de Checkmk se debe a sus numerosas opciones de configuración, con las que se pueden evitar las notificaciones sin importancia. En la mayoría de los casos, se tratará de situaciones en las que las notificaciones ya se retrasan o se suprimen cuando se producen. Además, el core de monitorización cuenta con una inteligencia integrada que suprime ciertas notificaciones de forma predeterminada. Nos gustaría abordar todos estos aspectos en este capítulo.
3.2. Tiempo de mantenimiento programado
Cuando un host o un servicio se encuentra en un tiempo de mantenimiento programado, se suprimirán las notificaciones del objeto. Esta es, junto con una evaluación correcta de la disponibilidad, la razón más importante para la inclusión efectiva de los tiempos de mantenimiento en la monitorización. Los siguientes detalles son relevantes al respecto:
Si se marca un host como en tiempo de mantenimiento programado, todos sus servicios también entrarán automáticamente en tiempo de mantenimiento programado, sin necesidad de introducir una entrada explícita para ellos.
Si un objeto entra en un estado de problema durante un tiempo de mantenimiento programado, cuando este termine según lo previsto, este problema se notificará de forma retroactiva justo al final del tiempo de mantenimiento.
El inicio y el final de un tiempo de mantenimiento programado son en sí mismos un evento de monitorización que se notificará.
3.3. Periodos de notificación
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 mediante el conjunto de reglas «Monitoring Configuration > Notification period for hosts» o, respectivamente, «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 aparecerá marcado con un icono de pausa gris 
.
Los eventos de monitorización de un objeto que no se encuentre actualmente en su periodo de notificación no se notificarán. Dichas notificaciones se «reemitirán» cuando el periodo de notificación vuelva a estar activo, siempre que el host o servicio siga en estado de problema. Solo se notificará el estado más reciente, incluso si se han producido múltiples cambios en el estado del objeto durante el tiempo 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 específico. 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 tarde!
3.4. El estado del host en el que se ejecuta un servicio
Si un host ha fallado por completo, o al menos es inaccesible para la monitorización, entonces, obviamente, sus servicios ya no se pueden monitorizar.
Las comprobaciones activas registrarán entonces, por regla general, «CRIT» o «UNKNOWN», ya que intentarán acceder activamente al host y, por lo tanto, encontrarán un error.
En tal situación, todas las demás comprobaciones —es decir, la gran mayoría— se omitirán y, por lo tanto, permanecerán en su estado anterior.
Estas se marcarán con el icono de tiempo «stale» 
.
Naturalmente, sería muy engorroso que todas las comprobaciones activas en ese estado notificaran sus problemas. Por ejemplo, si no se puede acceder a un servidor web —y esto ya se ha notificado—, no sería muy útil generar además un correo electrónico para cada uno de sus servicios HTTP dependientes.
Para minimizar estas situaciones, como principio básico, el core de monitorización solo genera notificaciones para los servicios si el host se encuentra en el estado «UP». Esta es también la razón por la que se verifica por separado la accesibilidad del host. Si no se configura de otra manera, esta verificación se realizará mediante un Smart Ping o un ping.
Si utilizas Checkmk Community (o una de las ediciones comerciales con un núcleo Nagios), en casos aislados puede ocurrir, no obstante, que un problema en el host
genere una notificación para un servicio activo.
La razón 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 han transcurrido tan solo unos segundos entre el último ping exitoso al servidor y la siguiente comprobación activa, Nagios puede seguir evaluando el host como «UP» aunque, de hecho, esté «DOWN».
Por el contrario, el Checkmk Micro Core (CMC) mantendrá la notificación del servicio en modo «standby» hasta que se haya verificado el estado del host, minimizando así de forma fiable las notificaciones indeseadas.
3.5. Hosts principales
Imagina que falla un router de red importante para una sede de la empresa con cientos de hosts. Todos sus hosts dejarán entonces de estar disponibles para la monitorización y pasarán a estar en estado «DOWN». Por lo tanto, se activarán cientos de notificaciones. No es nada bueno.
Para evitar este tipo de problemas, el router se puede definir como padre para sus hosts. Si hay hosts redundantes, también se pueden definir varios padres. En cuanto todos los padres entren en estado «DOWN», los hosts a los que ya no se pueda acceder se marcarán con el estado «UNREACH» y se suprimirán sus notificaciones. Por supuesto, el problema con el propio router seguirá notificándose.
Por cierto, el CMC funciona internamente de una manera ligeramente diferente a Nagios.
Para reducir las falsas alarmas, pero seguir procesando las notificaciones auténticas, el CMC presta mucha atención a las horas exactas de las comprobaciones de los hosts relevantes.
Si falla la comprobación de un host, el core esperará el resultado de la comprobación del host padre antes de generar una notificación.
Esta espera es asíncrona y no afecta a la monitorización general.
De este modo, las notificaciones de los hosts pueden sufrir retrasos mínimos.
4. Control de las notificaciones
4.1. El principio
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. Sin duda, esto tiene sentido al principio, pero en la práctica surgen muchos otros requisitos, por ejemplo:
La supresión de notificaciones específicas y menos útiles.
La «suscripción» a notificaciones de servicios para los que no eres contacto.
Una notificación puede enviarse por correo electrónico, SMS o buscapersonas, dependiendo de la hora del día.
La escalada de problemas cuando no se ha recibido Reconocimiento tras un plazo determinado.
La opción de no enviar notificaciones para los estados «WARN» o «UNKNOWN».
y mucho más…
Checkmk te ofrece la máxima flexibilidad a la hora de implementar estos requisitos a través de su mecanismo basado en reglas.
En la configuración de notificaciones, gestionas la secuencia 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 secuencia 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:
Una selección de contactos (¿A quién se debe notificar?).
Un método de notificación (¿Cómo notificar?), p. ej., correo electrónico HTML, y, opcionalmente, parámetros adicionales para el método elegido.
Importante: A diferencia de las reglas para hosts y servicios, aquí la evaluación continúa incluso después de que se haya cumplido la regla aplicable. Las reglas posteriores pueden añadir más notificaciones. Las notificaciones generadas por reglas anteriores también se pueden eliminar.
El resultado final de la evaluación de la regla será una tabla con una estructura similar a esta:
| Quién (contacto) | Cómo (método) | Parámetros del método de procedimiento |
|---|---|---|
Harry Hirsch |
Correo electrónico |
|
Bruno Weizenkeim |
Correo electrónico |
|
Bruno Weizenkeim |
SMS |
Ahora, para cada entrada de esta tabla, se ejecutará el script de notificación que realmente envía la notificación al usuario según el método.
4.2. Desactivar las notificaciones
Desactivación mediante reglas
Con los conjuntos de reglas «Enable/disable notifications for hosts» o, respectivamente, «Enable/disable notifications for services», puedes especificar los hosts y servicios para los que, por lo general, no se deben enviar notificaciones. Como se ha mencionado anteriormente, el core suprime entonces las notificaciones. Una regla de notificación posterior que se «suscriba» a las notificaciones de dichos servicios no tendrá efecto, ya que las notificaciones simplemente no se generan.
Desactivación mediante comandos
También es posible desactivar temporalmente las notificaciones para hosts o servicios individuales mediante un comando.
Sin embargo, esto requiere que se asigne el permiso Commands on host and services > Enable/disable notifications al rol de usuario. Por defecto, esto no ocurre en ningún rol.
Con el permiso asignado, puedes desactivar (y más tarde activar) las notificaciones de hosts y servicios con el comando «Commands > Notifications»:
Dichos hosts o servicios aparecerán entonces marcados con un icono de «
».
Dado que los comandos —a diferencia de las reglas— no requieren ni permisos de configuración ni el proceso de activar cambios, pueden ser una solución rápida para reaccionar de inmediato ante una situación.
Importante: A diferencia de los tiempos de mantenimiento programados de , las notificaciones desactivadas no influyen en las evaluaciones de disponibilidad.
Si durante una interrupción no planificada solo quieres desactivar las notificaciones sin alterar las estadísticas de disponibilidad,
¡no debes registrar un tiempo de mantenimiento programado!
Desactivación global
En el snap-in de Master control, en la barra lateral, encontrarás un switch master para Notifications:
Este switch es increíblemente útil si tienes previsto realizar cambios importantes en el sistema, durante los cuales un error podría, dadas las circunstancias, forzar a muchos servicios a entrar en estado de «CRIT». Puedes usar el switch para evitar molestar a tus compañeros con una avalancha de correos electrónicos inútiles. Recuerda volver a habilitar las notificaciones cuando hayas terminado.
Cada sitio de una monitorización distribuida tiene uno de estos switches. Desactivar las notificaciones del sitio central sigue permitiendo que los sitios remotos activen notificaciones, aunque estas se dirijan y se envíen desde el sitio central.
Importante: Las notificaciones que se habrían activado durante el tiempo en que las notificaciones estaban desactivadas no se repetirán más tarde cuando se vuelvan a activar.
4.3. Retrasar las notificaciones
Es posible que tengas servicios que ocasionalmente entren en un estado de problema durante breves periodos, pero las interrupciones son muy breves y no son críticas para ti. En tales casos, las notificaciones son muy molestas, pero se pueden suprimir 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 de «OK» / «UP» se repite antes de que termine ese tiempo, no se activará ninguna notificación. Naturalmente, esto también significa que la notificación de un problema real se retrasará.
Obviamente, aún mejor que retrasar las notificaciones sería eliminar la causa real de los problemas esporádicos, pero eso, por supuesto, es otra historia…
4.4. Intentos de check repetidos
Otro método muy similar para retrasar las notificaciones es permitir múltiples intentos de comprobación cuando un servicio entra en estado de problema. 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, una check con un resultado de «CRIT» no activará inicialmente ninguna notificación.
Esto se conoce como un soft state «CRIT».
El hard state sigue siendo «OK».
Solo si tres intentos sucesivos devuelven un estado que no sea «OK», el servicio switchará al hard state y se activará una notificación.
A diferencia de las notificaciones retrasadas, aquí tienes la opción de definir vistas de tabla para que no se muestren esos problemas. También se puede crear una Agregación BI para que solo se incluyan los estados «hard», y no los «soft states».
4.5. Hosts y servicios inestables
Cuando un host o un servicio cambia de estado con frecuencia en un breve periodo de tiempo, se considera que es inestable. Este es un estado real. El principio aquí es reducir el exceso de notificaciones durante las fases en las que un servicio no funciona (del todo) de forma estable. Estas fases también se pueden evaluar específicamente en las estadísticas de disponibilidad.
Los objetos inestables se marcan con el icono .
Mientras un objeto esté inestable, los cambios de estado sucesivos no activarán más notificaciones.
Sin embargo, se activará una notificación cada vez que el objeto entre o salga del estado inestable.
El reconocimiento de estados inestables por parte del sistema se puede ajustar de las siguientes maneras:
El Master control tiene un switch principal para controlar la detección de estados inestables (Flap Detection).
Puedes excluir objetos de la detección utilizando el Enable/disable flapping detection for hosts o, respectivamente, el conjunto de reglas Enable/disable flapping detection for services.
En las ediciones comerciales, con Global settings > Monitoring core > Tuning of flap detectionpuedes definir los parámetros para la detección de inestable y ajustarlos para que sean más o menos sensibles:
Consulta la ayuda contextualizada de «Help > Show inline help» para obtener más detalles sobre los valores personalizables.
5. La ruta de una notificación de principio a fin
5.1. El historial de notificaciones
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» con fines de prueba.
Para una prueba de notificación, puedes cambiar un servicio del estado «OK» a «CRIT» de esta manera. 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á en la parte superior de la lista. Sin embargo, la primera entrada está en la parte inferior, así que veamos las entradas individuales de abajo hacia arriba:
El core de monitorización registra el evento de monitorización del cambio de estado. El icono
de la primera columna indica el estado (CRIT en el ejemplo).El core de monitorización genera una notificación raw de
.
El core la pasa al módulo de notificaciones, que evalúa las reglas de notificación aplicables.La evaluación de las reglas da como resultado una notificación de usuario de
al usuario hhmediante el métodomail.El resultado de la notificación
indica que el correo electrónico se ha entregado correctamente al servidor SMTP para su envío.
Para ayudarte a entender bien los contextos de todas las opciones de configuración y condiciones básicas, y para que puedas diagnosticar con precisión cualquier problema cuando una notificación aparezca o no aparezca como esperabas, aquí te describiremos todos los detalles del proceso de notificación, incluyendo todos los componentes involucrados.
 |
El historial de notificaciones que hemos mostrado anteriormente para un servicio también se puede visualizar para un host: en la página de detalles del host, en el menú Host del propio host (elemento de menú Notifications of host) y también para el host con todos sus servicios (Notifications of host & services). |
5.2. Los componentes
Los siguientes componentes forman parte del sistema de notificaciones de Checkmk:
| Componente | Función | Archivo de registro |
|---|---|---|
Nagios |
El core de monitorización de Checkmk Community, que detecta eventos de monitorización y genera notificaciones raw. |
|
El core de monitorización de las ediciones comerciales que realiza la misma función que Nagios en Checkmk Community. |
|
|
Módulo de notificaciones |
Procesa las reglas de notificación para crear una notificación de usuario a partir de una notificación raw. Ejecuta los scripts de notificación. |
|
Spooler de notificación (solo ediciones comerciales) |
Entrega asíncrona de notificaciones y notificaciones centralizadas en entornos distribuidos. |
|
Script de notificación |
Para cada método de notificación hay un script que realiza el proceso del envío real (por ejemplo, genera y envía un correo electrónico en HTML). |
|
5.3. El core de monitorización
Notificaciones raw
Como se ha descrito anteriormente, cada notificación comienza con un evento de monitorización en el core de monitorización.
Si se han cumplido todas las condiciones y se puede dar «luz verde» a una notificación, el core genera una notificación raw dirigida al contacto de ayuda interno de check-mk-notify.
La notificación raw aún no contiene detalles de los contactos reales ni del método de notificación.
La notificación raw tiene este aspecto en el historial de notificaciones del servicio:
El icono es un altavoz gris claro de
check-mk-notifyse indica como contacto.check-mk-notifyse indica como comando de notificación.
A continuación, la notificación raw pasa al módulo de notificaciones de Checkmk, que procesa las reglas de notificación.
Nagios (cmk --notify) ejecuta este módulo como un programa externo.
El CMC mantiene el módulo en espera como un proceso auxiliar permanente (ayudante de notificaciones), lo que reduce la creación de procesos y ahorra tiempo de máquina.
Diagnóstico de errores en el core de monitorización de Nagios
El núcleo de Nagios utilizado en 
Checkmk Community registra todos los eventos de monitorización en ~/var/log/nagios.log.
Este archivo es, al mismo tiempo, la ubicación donde se almacena el historial de notificaciones, al que también se accede a través de la
GUI si, por ejemplo, deseas ver las notificaciones de un host o un servicio.
Sin embargo, más interesantes son los mensajes que encontrarás en el archivo ~/var/nagios/debug.log, que recibirás si configuras la variable debug_level
como 32 en etc/nagios/nagios.d/logging.cfg.
Tras un reinicio del core…
… encontrarás información útil sobre los motivos por los que se crearon o suprimieron las notificaciones:
[1592405483.152931] [032.0] [pid=18122] ** Service Notification Attempt ** Host: 'localhost', Service: 'backup4', Type: 0, Options: 0, Current State: 2, Last Notification: Wed Jun 17 16:24:06 2020
[1592405483.152941] [032.0] [pid=18122] Notification viability test passed.
[1592405485.285985] [032.0] [pid=18122] 1 contacts were notified. Next possible notification time: Wed Jun 17 16:51:23 2020
[1592405485.286013] [032.0] [pid=18122] 1 contacts were notified.Diagnóstico de errores en el core de monitorización de CMC
En las ediciones comerciales, puedes encontrar un protocolo del core de monitorización en el archivo de registro~/var/log/cmc.log
.
En la instalación estándar, este archivo no contiene información sobre las notificaciones.
Sin embargo, puedes activar una función de registro muy detallada conGlobal settings > Monitoring Core > Logging of the notification mechanics.
. El core proporcionará entonces información sobre por qué —o por qué no (todavía)— un evento de monitorización le indica que envíe una notificación al sistema de notificaciones:
Nota: Activar el registro de notificaciones puede generar muchos mensajes. Sin embargo, resulta útil cuando más adelante te preguntas por qué no se generó una notificación en una situación concreta.
5.4. Evaluación de reglas por el módulo de notificaciones
Una vez que el core ha generado una notificación raw, esta recorre la cadena de reglas de notificación, lo que da como resultado una tabla de notificaciones. Además de los datos de la notificación raw, cada notificación contiene la siguiente información adicional:
El contacto al que se va a notificar
El método de notificación
Los parámetros de este método
En una entrega sincrónica, para cada entrada de la tabla se ejecutará ahora un script de notificación adecuado. En una entrega asincrónica, la notificación se pasará como un archivo al spooler de notificación.
Análisis de la secuencia de reglas
Cuando creas regímenes de reglas más complejos, seguramente surgirá la pregunta de qué reglas se aplicarán a una notificación específica. Para esto, Checkmk ofrece una función de análisis integrada en Setup > Setup > Analyze recent notifications.
En el modo de análisis, por defecto se mostrarán las últimas diez notificaciones raw generadas por el sistema y procesadas a través de las reglas:
Si necesitas analizar un mayor número de notificaciones raw, puedes aumentar fácilmente el número almacenado para el análisis a través de Global settings > Notifications > Store notifications for rule analysis:
Para cada una de estas notificaciones raw, tendrás a tu disposición tres acciones:
|
Comprueba la secuencia de reglas, en la que se verificará si se han cumplido todas las condiciones de cada regla para el evento de monitorización seleccionado. Se mostrará la tabla de notificaciones resultante junto con las reglas. |
|
Muestra el contexto completo de la notificación. |
|
Repite esta notificación raw como si acabara de aparecer. Por lo demás, la visualización es la misma que en el análisis. Con esto no solo puedes check las condiciones de la regla, sino también ver cómo se ve visualmente una notificación. |
Diagnóstico de errores
Si has realizado la prueba de la secuencia de reglas (
), puedes ver qué reglas 
se han aplicado o 
no se han aplicado a un evento de monitorización:
Si no se ha aplicado una regla, pasa el ratón por encima del círculo gris para ver la sugerencia (texto al pasar el ratón):
Sin embargo, este texto al pasar el ratón utiliza abreviaturas para indicar las causas por las que no se ha aplicado una regla. Estas se refieren a las condiciones Host events o Service events de la regla.
| Tipos de eventos de host | ||
|---|---|---|
Abreviatura |
Significado |
Descripción |
|
UP ➤ DOWN |
El estado del host ha cambiado de «UP» a «DOWN» |
|
UP ➤ UNREACHABLE |
El estado del host ha cambiado de UP a UNREACH |
|
DOWN ➤ UP |
El estado del host ha cambiado de DOWN a UP |
|
DOWN ➤ UNREACHABLE |
El estado del host ha cambiado de DOWN a UNREACH |
|
UNREACHABLE ➤ DOWN |
El estado del host ha cambiado de UNREACH a DOWN |
|
UNREACHABLE ➤ UP |
El estado del host ha cambiado de UNREACH a UP |
|
any ➤ UP |
El estado del host ha cambiado de cualquier estado a UP |
|
any ➤ DOWN |
El estado del host ha cambiado de cualquier estado a DOWN |
|
any ➤ UNREACHABLE |
El estado del host ha cambiado de cualquier estado a UNREACH |
|
Start or end of flapping state |
|
|
Start or end of a scheduled downtime |
|
|
Acknowledgment of problem |
|
|
Alert handler execution, successful |
|
|
Alert handler execution, failed |
|
| Tipos de eventos de servicio | ||
|---|---|---|
Abreviatura |
Significado |
Descripción |
|
OK ➤ WARN |
El estado del servicio ha cambiado de «OK» a «WARN» |
|
OK ➤ OK |
El estado del servicio ha cambiado de «OK» a «OK» |
|
OK ➤ CRIT |
El estado del servicio ha cambiado de «OK» a «CRIT» |
|
OK ➤ UNKNOWN |
El estado del servicio ha cambiado de «OK» a «UNKNOWN» |
|
WARN ➤ OK |
El estado del servicio ha cambiado de «WARN» a «OK» |
|
WARN ➤ CRIT |
El estado del servicio ha cambiado de «WARN» a «CRIT» |
|
WARN ➤ UNKNOWN |
El estado del servicio ha cambiado de «WARN» a «UNKNOWN» |
|
CRIT ➤ OK |
El estado del servicio ha cambiado de «CRIT» a «OK» |
|
CRIT ➤ WARN |
El estado del servicio ha cambiado de «CRIT» a «WARN» |
|
CRIT ➤ UNKNOWN |
El estado del servicio ha cambiado de «CRIT» a «UNKNOWN» |
|
UNKNOWN ➤ OK |
El estado del servicio ha cambiado de UNKNOWN a OK |
|
UNKNOWN ➤ WARN |
El estado del servicio ha cambiado de UNKNOWN a WARN |
|
UNKNOWN ➤ CRIT |
El estado del servicio ha cambiado de UNKNOWN a CRIT |
|
any ➤ OK |
El estado del servicio ha cambiado de cualquier estado a «OK» |
|
any ➤ WARN |
El estado del servicio ha cambiado de cualquier estado a «WARN» |
|
any ➤ CRIT |
El estado del servicio ha cambiado de cualquier estado a «CRIT» |
|
any ➤ UNKNOWN |
El estado del servicio ha cambiado de cualquier estado a UNKNOWN |
Basándote en estas pistas, puedes check y revisar tus reglas.
Otra opción de diagnóstico importante es el archivo de registro «~/var/log/notify.log».
Durante las pruebas con las notificaciones, el popular comando «tail -f» resulta útil para esto:
Con Global settings > Notifications > Notification log level puedes controlar el nivel de detalle de las notificaciones en tres niveles. Configúralo en Full dump of all variables and command y, en el archivo de registro, encontrarás una lista completa de todas las variables disponibles para el script de notificación:
Por ejemplo, la lista aparecerá así (extracto):
2025-04-09 08:47:39,186 [10] [cmk.base.notify] Raw context:
CONTACTS=hh
HOSTACKAUTHOR=
HOSTACKCOMMENT=
HOSTADDRESS=127.0.0.1
HOSTALIAS=localhost
HOSTATTEMPT=1
HOSTCHECKCOMMAND=check-mk-host-smart5.5. Entrega asíncrona a través del spooler de notificación
Una potente función adicional de las ediciones comerciales es el spooler de notificación.
Esto permite el envío asíncrono de notificaciones.
¿Qué significa «asíncrono» en este contexto?
Entrega sincrónica: El módulo de notificaciones espera hasta que el script de notificación haya terminado de ejecutarse. Si la ejecución tarda mucho tiempo, se acumularán más notificaciones. Si se detiene la monitorización, estas notificaciones se pierden. Además, si se generan muchas notificaciones en un breve periodo de tiempo, puede acumularse un retraso hasta el core de monitorización, lo que provocaría que la monitorización se bloquee.
Entrega asíncrona: Cada notificación se guardará en un archivo spool en
~/var/check_mk/notify/spool. No se acumularán atascos. Si se detiene la monitorización, los archivos spool se conservarán y las notificaciones se podrán entregar correctamente más tarde. El spooler de notificación se encarga del procesamiento de los archivos spool.
La entrega sincrónica es viable si el script de notificación se ejecuta rápidamente y, sobre todo, no puede provocar ningún tipo de timeout. Con métodos de notificación que acceden a spoolers existentes, esto es un hecho. Los servicios de spool del sistema se pueden utilizar especialmente con correo electrónico y SMS. El script de notificación pasa un archivo al spooler; con este procedimiento no se produce ningún estado de espera.
Cuando utilices la entrega rastreable a través de SMTP u otros scripts que establezcan conexiones de red, siempre debes emplear 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 tiempos de timeout al establecer una conexión con un servicio de red pueden durar hasta varios minutos, lo que provoca un atasco como el descrito anteriormente.
La buena noticia es que la entrega asíncrona está habilitada por defecto en Checkmk.
Por un lado, el spooler de notificación (mknotifyd) también se inicia al arrancar el site, lo cual 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:
Diagnóstico de errores
El spooler de notificación mantiene su propio archivo de registro: ~/var/log/mknotifyd.log.
Este tiene tres niveles de registro que se pueden configurar en Global settings > Notifications > Notification Spooler Configuration con el parámetro Verbosity of logging.
El valor predeterminado es Normal logging (only startup, shutdown and errors.
En el nivel medio, Verbose logging (i.e. spooled notifications),, se puede ver el procesamiento de los archivos spool:
2025-04-09 08:47:37,928 [15] [cmk.mknotifyd] processing spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/dad64e2e-b3ac-4493-9490-8be969a96d8d
2025-04-09 08:47:37,928 [20] [cmk.mknotifyd] running cmk --notify --log-to-stdout spoolfile /omd/sites/mysite/var/check_mk/notify/spool/dad64e2e-b3ac-4493-9490-8be969a96d8d
2025-04-09 08:47:39,848 [20] [cmk.mknotifyd] got exit code 0
2025-04-09 08:47:39,850 [20] [cmk.mknotifyd] processing spoolfile dad64e2e-b3ac-4493-9490-8be969a96d8d successful: success 250 - b'2.4.0 Ok: queued as 1D4FF7F58F9'
2025-04-09 08:47:39,850 [20] [cmk.mknotifyd] sending command LOG;SERVICE NOTIFICATION RESULT: hh;mysrv;CPU load;OK;mail;success 250 - b'2.4.0 Ok: queued as 1D4FF7F58F9';success 250 - b'2.0.0 Ok: queued as 1D4FF7F58F9'6. Entrega con seguimiento mediante SMTP
6.1. El correo electrónico no es fiable
La monitorización solo es útil cuando puedes confiar en ella.
Para eso, es necesario que las notificaciones se reciban de forma fiable y rápida.
Por desgracia, el envío de correos electrónicos no es del todo ideal.
El envío suele procesarse pasando el correo al servidor SMTP local.
Este intenta entregar el correo de forma autónoma y asíncrona.
Si se produce un error temporal (por ejemplo, un caso en el que no se puede contactar con el servidor SMTP receptor), el correo electrónico se pondrá en una cola y más tarde se realizará un nuevo intento. Este «más tarde» suele ser después 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 de error para el «remitente». Pero el sistema de monitorización no es un remitente real y tampoco puede recibir correos electrónicos. De ahí que esos errores simplemente desaparezcan y, por lo tanto, no haya notificaciones.
6.2. Usar SMTP en una conexión directa permite el análisis de errores
Las ediciones comerciales ofrecen la posibilidad de un envío rastreable a través de SMTP. Esto se 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 a través de SMTP y, a continuación, evalúa él mismo la respuesta SMTP.
De esta manera, no solo 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 acuse de recibo del smarthost SMTP (servidor receptor) que verifica que el correo electrónico ha sido aceptado, incluyendo un ID de correo.
El proceso práctico para configurar notificaciones con entrega rastreable a través de SMTP se describe en las reglas de notificación globales y en las reglas de notificación personales.
6.3. SMS y otros métodos de notificación
Hasta la fecha, la entrega sincrónica, que incluye mensajes de error y trazabilidad, solo se ha implementado para los correos electrónicos HTML. En el capítulo sobre cómo escribir tus propios scripts de notificación encontrarás cómo devolver un estado de error en un script de notificación escrito por ti mismo.
7. Notificaciones en sistemas distribuidos
En entornos distribuidos —es decir, aquellos con más de un sitio de Checkmk— surge la pregunta de qué hacer con las notificaciones generadas en sitios remotos. En tal situación, hay básicamente dos posibilidades:
Entrega local
Entrega centralizada en el site central (solo ediciones comerciales)
Puedes encontrar información detallada sobre este tema en el artículo sobre monitorización distribuida.
8. Scripts de notificación
8.1. El principio
Las notificaciones pueden realizarse de múltiples y diversas formas. Algunos ejemplos típicos son:
Transferencia de notificaciones a un ticket o a un sistema de notificaciones externo
El envío de un SMS a través de diversos servicios de internet
Llamadas telefónicas automáticas
Reenvío a un sistema de monitorización superior o global
Por este motivo, Checkmk ofrece una interfaz muy sencilla que te permite escribir tus propios scripts de notificación. Estos se pueden escribir en cualquier lenguaje de programación compatible con Linux, aunque Shell, Perl y Python suman el 95 % del «mercado».
Los scripts estándar incluidos con Checkmk se encuentran en ~/share/check_mk/notifications.
Este directorio forma parte del software y no está pensado para ser modificado.
En su lugar, guarda tus propios scripts en ~/local/share/check_mk/notifications.
Asegúrate de que tus scripts sean ejecutables (chmod +x).
Así 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í los cambios en la copia.
Si mantienes el nombre original, tu script sustituirá automáticamente a la versión estándar y no será necesario realizar cambios en las reglas de notificación existentes.
En caso de notificación, tu script se ejecutará con los permisos del usuario del site.
En las variables del entorno que comienzan por NOTIFY_, el script recibirá toda la información sobre el host/servicio afectado, el evento de monitorización, los contactos a los que se debe notificar y los parámetros especificados en la regla de notificación.
Los textos que el script escribe en la salida estándar (con print, echo, etc.) aparecen en el archivo de registro del módulo de notificaciones ~/var/log/notify.log.
8.2. Notificaciones rastreables
Los scripts de notificación tienen la opción de usar un código de salida para indicar si se ha producido un error replicable o definitivo:
| Código de salida | Descripción |
|---|---|
|
El script se ha ejecutado correctamente. |
|
Se ha producido un error temporal. La ejecución debe volver a intentarse repetidamente tras una breve espera, hasta que se haya alcanzado el número máximo de intentos configurado. Ejemplo: no se puede establecer una conexión HTTP con un servicio de SMS. |
|
Se ha producido un error definitivo. No se volverá a intentar la notificación. Se mostrará un error de notificación en la GUI. El error se mostrará en el historial del host o del servicio. Ejemplo: el servicio SMS registra un error de «autenticación inválida». |
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 o del servicio y, por lo tanto, será visible en la GUI.
Importante: ¡Las notificaciones rastreables no están disponibles para notificaciones masivas!
El tratamiento de los errores de notificación desde la vista del usuario se explicará en el capítulo sobre la entrega rastreable a través de SMTP.
8.3. Un ejemplo de script sencillo
A modo de ejemplo, puedes crear un script que escriba toda la información sobre la notificación en un archivo. El lenguaje de programación es el shell Bash de Linux:
A continuación, haz que el script sea ejecutable:
Aquí tienes un par de explicaciones sobre el script:
En la primera línea hay un
#!y la ruta al intérprete del lenguaje del script (en este caso,/bin/bash).En la segunda línea, después del carácter de comentario
#, está el título del script. Por lo general, este se mostrará al seleccionar el método de notificación.El comando `
env` mostrará todas las variables del entorno recibidas por el script.Con
grep NOTIFY_, las variables de Checkmk se filtrarán…… y ordenadas alfabéticamente con
sort.> $OMD_ROOT/tmp/foobar.outescribe el resultado en el archivo «~/tmp/foobar.out» dentro del directorio del site.En realidad, el `
exit 0` sería superfluo en esta ubicación, ya que el shell siempre toma el código de salida del último comando. Aquí es `echo` y siempre se ejecuta correctamente, pero es mejor ser explícito.
8.4. Probar el script de ejemplo
Para que se utilice el script, 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 todas las checkboxes como las que se ofrecen, por ejemplo, en el método HTML Email.
En su lugar, puedes introducir una lista de textos como parámetros que estarán disponibles para el script como NOTIFY_PARAMETER_1, NOTIFY_PARAMETER_2, etc.
Para una prueba, proporciona los parámetros Fröhn, Klabuster y Feinbein:
Ahora, para probarlo, configura 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, incluidos los parámetros y el archivo spool generado.:
2021-08-25 13:01:23,887 [20] [cmk.base.notify] Executing 1 notifications:
2021-08-25 13:01:23,887 [20] [cmk.base.notify] * notifying hh via foobar, parameters: Fröhn, Klabuster, Feinbein, bulk: no
2021-08-25 13:01:23,887 [20] [cmk.base.notify] Creating spoolfile: /omd/sites/mysite/var/check_mk/notify/spool/e1b5398c-6920-445a-888e-f17e7633de60El archivo ~/tmp/foobar.out contendrá ahora una lista alfabética de todas las variables del entorno de Checkmk que incluyen información relativa a la notificación.
Aquí puedes ver qué valores están disponibles para tu script.
Aquí tienes las primeras diez líneas:
Los parámetros también se pueden encontrar:
8.5. Variables del entorno
En el ejemplo anterior has visto varias variables del entorno que se pasarán al script.
Las variables concretas que están disponibles dependen del tipo de notificación, la versión y edición de Checkmk y el core de monitorización utilizado (CMC o Nagios).
Además del truco con el comando `env`, hay otras dos formas de obtener una lista completa de todas las variables:
Cambiando el nivel de registro de
~/var/log/notify.loga través de Global settings > Notifications > Notification log level.Para las notificaciones de HTML Email, hay una checkbox Information to be displayed in the email body con la opción «Complete variable list (for testing)».
A continuación tienes una lista de las variables más importantes:
| Variable del entorno | Descripción |
|---|---|
|
Directorio de inicio del site, p. ej., |
|
Nombre del site, p. ej., |
|
Para las notificaciones del host, la palabra |
|
Nombre de usuario (inicio de sesión) del contacto. |
|
La dirección de correo electrónico del contacto. |
|
Entrada en el campo Pager del perfil de usuario del contacto. Como el campo no suele estar reservado para un fin específico, puedes usarlo simplemente para cada usuario con el fin de guardar la información necesaria para las notificaciones. |
|
Fecha de la notificación en formato ISO-8601, p. ej., |
|
Fecha y hora en el formato predeterminado del sistema Linux sin localizar, p. ej., |
|
Fecha y hora en formato ISO, p. ej., |
|
Nombre del host afectado. |
|
Salida del check plugin del host, p. ej., |
|
Una de estas palabras: |
|
Tipo de notificación tal y como se describe en la introducción de este artículo
. Se expresará mediante una de las siguientes palabras: |
|
Todos los parámetros del script separados por espacios. |
|
El primer parámetro del script. |
|
El segundo parámetro del script, etc. |
|
Nombre del servicio en cuestión. Esta variable no aparece en las notificaciones de host. |
|
Salida del check plugin del servicio (no para notificaciones de host) |
|
Una de estas palabras: |
8.6. Notificaciones masivas
Si tu script debe admitir notificaciones masivas, tendrá que estar especialmente preparado, ya que el script debe enviar varias notificaciones a la vez. Por este motivo, el envío mediante variables del entorno tampoco funciona en la práctica.
Ponle un nombre a tu script en la tercera línea del encabezado como se muestra a continuación: el módulo de notificaciones 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 el formato: 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 saltos de línea dentro del texto.
El primer bloque contiene una lista de variables generales (por ejemplo, parámetros de llamada). Cada bloque posterior ensambla las variables en una notificación.
Lo mejor 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. Puedes usar el siguiente script de notificación para este fin:
Prueba el script tal y como se ha descrito anteriormente y, además, activa la opción «Notification Bulking» en la regla de notificación.
8.7. Scripts de notificación incluidos
Tal y como se entrega, Checkmk ya ofrece toda una gama de scripts para realizar la conexión a servicios de mensajería instantánea populares y ampliamente utilizados, plataformas de gestión de incidencias y sistemas de tickets. Puedes averiguar cómo usar estos scripts en los siguientes artículos:
9. Archivos y directorios
9.1. Rutas de Checkmk
| Ruta de archivo | Función |
|---|---|
|
El archivo de registro de CMC. Si tienes activada la depuración de notificaciones, aquí encontrarás información precisa sobre por qué se generaron o no las notificaciones. |
|
El archivo de registro del módulo de notificaciones. |
|
El archivo de registro del spooler de notificación. |
|
El estado actual del spooler de notificación. Esto es relevante principalmente para las notificaciones en entornos distribuidos. |
|
El archivo de registro de depuración de Nagios. Switch los mensajes de depuración en |
|
Ubicación de almacenamiento de los archivos spool que procesará el spooler de notificación. |
|
En caso de errores temporales, el spooler de notificación mueve los archivos aquí y vuelve a intentarlo tras unos minutos. |
|
Los archivos spool defectuosos se moverán aquí. |
|
Scripts de notificación que vienen de serie con Checkmk. No hagas ningún cambio aquí. |
|
Ubicación de almacenamiento para tus scripts de notificación definidos por el usuario. Si deseas personalizar un script estándar, cópialo de |
9.2. Archivos de registro del servidor SMTP
Los archivos de registro del servidor SMTP son archivos del sistema y sus rutas absolutas se enumeran a continuación. La ubicación exacta donde se almacenan los archivos de registro dependerá de tu distribución de Linux.
| Ruta | Función |
|---|---|
|
Archivo de registro del servidor SMTP en Debian y Ubuntu |
|
Archivo de registro del servidor SMTP en SUSE Linux Enterprise Server (SLES) |
|
Archivo de registro del servidor SMTP en Red Hat Enterprise Linux (RHEL) |