 |
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
Tras el artículo sobre los conceptos básicos de las notificaciones, en el que se describen los fundamentos de las notificaciones, este artículo trata ahora de las notificaciones por correo electrónico y de la creación de notificaciones mediante reglas.
2. La vista general de las notificaciones
A través de Setup > Events > Notification puedes acceder a la página de vista general de notificaciones. Aquí se recopila toda la información importante sobre este tema:
Un sistema de notificaciones que funcione se basa en la interacción de varios componentes que deben configurarse. Esta página de vista general te ahorra tener que buscar las reglas, parámetros, etc. individuales en las distintas áreas de Checkmk. Desde aquí puedes acceder a todos los aspectos relacionados con el tema de las notificaciones.
2.1. Estado de las notificaciones
En la parte izquierda de la página aparece una vista general del estado actual de las notificaciones:
Se muestran:
Failed notifications |
Número de notificaciones fallidas. Si hay notificaciones fallidas, se muestra un enlace a la vista general correspondiente más abajo. |
Total sent notifications |
Número de notificaciones enviadas. Si hay notificaciones fallidas, se muestra a continuación un enlace a Notifications of host & services, filtrado por los últimos 7 días. Puedes utilizarlo para ver con más detalle qué notificaciones se han enviado. |
Core status of notifications |
Muestra en cuántos sitios de Checkmk están activas las notificaciones. Si están desactivadas en un sitio, por ejemplo, a través del snap-in de Control maestro, se muestra el nombre del sitio. Esto te permite comprobar si esto era lo previsto. |
2.2. Reglas de notificación
A la derecha de las pantallas de estado encontrarás enlaces a todas las reglas de notificación existentes en Checkmk:
Desde aquí puedes acceder a las reglas para optimizar tus notificaciones, así como a todas las demás reglas relacionadas con las notificaciones.
 |
Es posible que ya te resulten familiares las reglas que se muestran aquí por haberlas visto en otros lugares de Checkmk. Aquí no se han creado nuevas reglas, solo se han resumido claramente las existentes. |
2.3. Regla de notificación global y predefinida
La última parte de la página de vista general consiste en la regla global existente.
Si acabas de instalar Checkmk, habrá una sola regla predefinida:
Dicha regla tiene la siguiente estructura:
Condición |
Todos los cambios de estado de los hosts a DOWN y UP, y de los servicios a CRIT, WARN y OK. |
Método |
Envía un correo electrónico en formato HTML (con gráficos de métricas incrustados). |
Contacto |
Todos los contactos del host/servicio afectado. |
Como siempre, puedes realizar la edición de la regla 
, clonarla 
, eliminarla 
o crear una nueva regla.
Una vez que tengas más de una regla, puedes cambiar su orden de procesamiento arrastrando y soltando las reglas con el icono 
.
|
Los cambios en las reglas de notificación no requieren activación, sino que entran en vigor de inmediato. |
3. Notificaciones sencillas por correo electrónico
Pero antes de pasar a notificaciones más complejas, empieza con una forma muy sencilla de notificación: un simple correo electrónico.
Una notificación por correo electrónico enviada por Checkmk en formato HTML tiene un aspecto similar a este:
Como se puede ver en el ejemplo, el correo electrónico también contiene las métricas actuales del servicio afectado.
Antes de recibir un correo electrónico de este tipo de Checkmk, es necesario realizar algunos preparativos, tal y como se describe a continuación.
3.1. Requisitos previos
En la configuración por defecto de Checkmk, un usuario recibirá notificaciones por correo electrónico cuando se cumplan los siguientes requisitos previos:
El servidor Checkmk tiene una configuración operativa para enviar correos electrónicos.
Se ha configurado una dirección de correo electrónico para el usuario.
El usuario es miembro de un grupo de contacto y, por lo tanto, es un contacto.
Se produce un evento de monitorización en un host o servicio asignado a este grupo de contacto, lo que activa una notificación.
3.2. Configuración del envío de correo en Linux
Para que el envío de correos electrónicos funcione correctamente, tu servidor Checkmk debe tener una configuración de servidor SMTP operativa. Dependiendo de tu distribución de Linux, esta podría utilizar, por ejemplo, Postfix, Qmail, Exim o Nullmailer. La configuración se implementará con los recursos de tu distribución de Linux.
La configuración se limita generalmente a registrar un «smarthost» (también conocido como servidor de retransmisión SMTP) al que se dirigirán todos los correos electrónicos. Este será entonces el servidor de correo SMTP interno de tu empresa. Por regla general, los smarthosts no requieren autenticación en una LAN, lo que simplifica las cosas. En algunas distribuciones, se te preguntará por el smarthost durante la instalación. Con el dispositivo Checkmk, puedes 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 de este comando en Linux, para garantizar la 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 probar esto es como usuario del site, ya que los scripts de notificación se ejecutarán más adelante con los mismos permisos.
El contenido del correo electrónico se lee desde 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 comandos:
El correo electrónico debería enviarse sin demora.
Si esto no funciona, puedes encontrar información en el archivo de registro del servidor SMTP en el directorio /var/log (consulta Archivos y directorios).
3.3. Dirección de correo electrónico y grupos de contacto
La dirección de correo electrónico y los grupos de contacto de un usuario se definen en la administración de usuarios:
En un site de Checkmk recién creado, inicialmente solo existe el grupo de contacto Everything. Los miembros de este grupo son automáticamente responsables de todos los hosts y servicios, y recibirán notificaciones por correo electrónico de todos los eventos de monitorización relevantes.
3.4. Casos especiales: sistema de tickets, mensajería y motor de eventos
En lugar de correo electrónico o SMS, también puedes enviar notificaciones a un sistema de tickets (como Jira o ServiceNow), un servicio de mensajería (Slack, Mattermost) o una consola de eventos (Consola de eventos).
Existe un método de notificación independiente para cada uno de estos casos especiales, que se puede seleccionar en la regla de notificación. Sin embargo, debes tener en cuenta los dos puntos siguientes al crear la regla:
Al seleccionar contactos, asegúrate de que las notificaciones solo se envíen a un contacto, por ejemplo, seleccionando un único usuario. Con los métodos de notificación para sistemas de tickets, etc., la selección de contactos solo sirve para especificar que se envían notificaciones. Sin embargo, las notificaciones no se envían al usuario seleccionado, sino al sistema de tickets. Ten en cuenta que una selección de contactos a través de grupos de contacto, todos los contactos de un objeto o similares suele generar varias notificaciones idénticas para un evento, que luego terminan en el sistema de tickets dos, tres o incluso más veces.
Si se cumple el primer punto, pero el usuario aparece en varias reglas de notificación para el mismo método, solo se aplica la última regla en cada caso. Por lo tanto, es recomendable crear un usuario funcional independiente para cada una de estas reglas de notificación.
3.5. Ajustes precisos de los correos electrónicos HTML
Al enviar correos electrónicos HTML, es posible que desees añadir información adicional o definir de forma flexible una dirección de respuesta (Reply to) a un contacto específico para cualquier consulta. Para ello, existe la regla «Setup > Notifications > Parameters for notification methods > HTML Email» y, en las reglas de notificación, el método de notificación por 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 en HTML.
Ten en cuenta que, en el campo Custom HTML section (e.g. title, description…), por motivos de seguridad solo se permite un pequeño conjunto de tags HTML. Estos son:
| Tag | Función | Consejos |
|---|---|---|
|
Permitida cuando se combina con los atributos |
|
|
||
|
||
|
||
|
Obsoleto. ¡No uses esta tag! |
|
|
||
|
||
|
||
|
En desuso. ¡No uses este tag! |
|
|
Se conservan los espacios y las sangrías. |
|
|
||
|
||
|
||
|
Úsalo solo en las siguientes listas: |
|
|
||
|
Como es habitual con todas las reglas de Checkmk, es posible una aplicación muy detallada, de modo que puedes personalizar un conjunto detallado de notificaciones para hosts y servicios según sea necesario.
4. Control de las notificaciones mediante reglas
Además de las simples notificaciones por correo electrónico, con Checkmk también puedes configurar sistemas de notificación más complejos.
4.1. Creación simplificada de reglas
Para facilitar la creación de reglas de notificación, Checkmk tiene aquí un aspecto diferente al que estás acostumbrado en otras áreas. Con «Setup > Events > Notifications > Add notification rule» puedes empezar a crear notificaciones:
Ahora tendrás que tomar una decisión.
Si seleccionas «Guided mode,», se te guiará, sección por sección, a través de la creación de una regla de notificación. Cada sección trata específicamente un aspecto de la notificación. Rellena la sección correspondiente con los datos relevantes para tu entorno. Las descripciones de los temas individuales se pueden encontrar más adelante en este artículo. Una vez que hayas realizado la edición de una sección, haz clic en «Next step…». A continuación, se verificarán tus datos, siempre que sean técnicamente obligatorios. Si, por ejemplo, faltan datos técnicamente relevantes, como la dirección de correo electrónico que se va a utilizar, recibirás un mensaje de error. Una vez que hayas introducido correctamente los datos básicos esenciales, pasarás a la siguiente sección y, finalmente, al final, donde habrás preparado una regla de notificación completa. A continuación, completa la creación con «Apply & test notification rule» o «Apply & create another rule».
También puedes usar la Overview mode. Esto resulta especialmente útil para editar de forma selectiva parámetros concretos de una regla de notificación ya existente, así como si ya estás muy familiarizado con la creación de reglas y no necesitas que te guíen. En Overview mode ves todas las secciones de edición a la vez y puedes editar todos los campos y opciones directamente. La verificación técnica se lleva a cabo una sola vez y en todas las secciones en cuanto hagas clic en Apply & test notification rule o Apply & create another rule.
4.2. Estructura de las reglas de notificación
A continuación, te presentamos la estructura general de las reglas de notificación con las definiciones de condiciones, tipos de eventos, filtros, métodos de notificación, contactos y propiedades generales.
Condiciones
Las condiciones determinan cuándo se aplicará una regla. Son la base de todas las reglas. Para entenderlo bien, es importante recordar que el origen es siempre un evento de monitorización en un host o servicio concreto.
Las condiciones se refieren
los atributos estáticos del objeto —por ejemplo, si el nombre del servicio contiene el texto «
/tmp» o si un host está en un grupo del host específico—el estado actual o el cambio de estado, por ejemplo, si el servicio acaba de cambiar de OK a CRIT,
o con cosas completamente diferentes, por ejemplo, si el periodo de tiempo «horario laboral» está activo en este momento.
Hay dos puntos importantes que debes tener en cuenta al establecer las condiciones:
Si no se han definido condiciones, la regla se aplicará a todos los eventos de monitorización.
En cuanto selecciones aunque sea una sola condición, la regla solo se aplicará si se cumplen todas las condiciones. Todas las condiciones seleccionadas se enlazan con «Y». Solo hay una excepción a esta importante regla, que comentaremos más adelante y no vamos a tener en cuenta ahora.
Esto significa que debes prestar mucha atención a si las condiciones que has elegido pueden cumplirse al mismo tiempo, de modo que se active una notificación para el caso deseado.
Definición de tipos de eventos
En el siguiente ejemplo de la estructura de una regla de notificación, dos cambios de estado deberían activar notificaciones:
Los hosts que pasan al estado «DOWN» y
Los servicios que pasan al estado «CRIT».
Esto se define en el paso 1:
La excepción a la operación AND
En Checkmk se aplica generalmente lo siguiente: Solo si un evento de monitorización cumple todas las condiciones configuradas, se aplicará la regla de notificación. Hay una excepción importante a esta regla general: para las condiciones «Host events» y «Service events».
Si seleccionas solo «Host events», la regla no coincidirá con ningún evento de servicio. Lo mismo se aplica a la selección de eventos de «Service events» y de host. Sin embargo, si activas ambas condiciones, la regla coincidirá si un evento se define en cualquiera de las dos condiciones. En este caso excepcional, estas condiciones no se vincularán con un «AND» lógico, sino con un «OR». De esta manera, puedes gestionar fácilmente las notificaciones de host y servicio con una sola regla.
Configuración de filtros de host y servicio
En el paso 2, utilizas varios filtros para determinar los hosts y servicios a los que debe aplicarse la regla de notificación.
Supongamos que configuras el filtro para que solo se envíe una notificación si se produce un evento de monitorización para un servicio que empiece por el nombre NTP en un host de la carpeta Main:
El resultado de esta regla de notificación con las tres condiciones individuales (cambios de estado, nombre del servicio, carpeta) sería que las notificaciones solo se enviarían si un servicio pasara a CRIT, y los cambios de estado del host se ignorarían porque ningún evento de monitorización contendría el cambio de estado de un host y el nombre del servicio con NTP.
Otro consejo sobre la opción Contact group filters de la imagen anterior: La condición que se comprueba aquí es si el host/servicio en cuestión tiene una asignación de contacto determinada. Esto se puede usar para implementar funciones como «Las notificaciones de host del grupo de contacto Linux nunca deben enviarse por SMS». Esto no tiene nada que ver con la selección de contactos descrita anteriormente.
Método de notificación
El método de notificación del paso 3 especifica la técnica que se utilizará para enviar la notificación, p. ej., mediante correo electrónico HTML.
Cada método se implementa mediante un script. Checkmk incluye varios scripts predefinidos. También puedes escribir fácilmente tus propios scripts personalizados en cualquier lenguaje de programación que desees para implementar notificaciones definidas por el usuario, por ejemplo, para redirigir una notificación a tu propio sistema de tickets.
Algunos métodos de notificación pueden incluir parámetros.
Por ejemplo, los métodos para correos electrónicos ASCII y HTML te permiten especificar explícitamente la dirección del remitente (From:).
La página correspondiente para configurar los parámetros aparece tras seleccionar el método, tan pronto como hagas clic en «Create».
Sin embargo, antes de realizar ajustes en la regla de notificación individual aquí, debes saber que también puedes configurar parámetros para los métodos de notificación de forma general en otros dos lugares de Checkmk:
En los «Parámetros para métodos de notificación», que se describen más adelante en este artículo. En la regla de notificación, selecciona la definición de parámetro deseada en «Select parameters» antes de hacer clic en «Create» para cambiar la definición de parámetro seleccionada para esta regla de notificación.
En las reglas para hosts y servicios: En «Setup > Services > Service monitoring rules», encontrarás un conjunto de reglas para cada método de notificación en la sección «Notifications», que puedes usar para definir los mismos ajustes —y, como siempre, dependiendo del host o servicio.
Solo cambia las definiciones de los parámetros en la regla de notificación si quieres desviarte de esta configuración en casos concretos. Por ejemplo, puedes definir un asunto específico para tu correo electrónico a nivel global, pero definir un asunto alternativo en una regla de notificación individual.
En lugar de «Send notification», también puedes seleccionar «Suppress all previous». Las notificaciones de reglas anteriores que utilizaban este método se descartarán entonces. Puedes encontrar más información al respecto en la sección «Eliminar notificaciones por reglas».
|
Para muchos métodos de notificación para reenviar a otros sistemas, encontrarás información más detallada en artículos separados. La lista de artículos se encuentra en el capítulo sobre scripts de notificación. |
Selección de contactos
El procedimiento más habitual es enviar las notificaciones a todos los usuarios que se hayan registrado como contacto para el host o servicio correspondiente. Este es el procedimiento «normal» y lógico, ya que también es a través de los contactos como se define qué objetos recibe cada usuario en su GUI —en la práctica, aquellos objetos de los que el usuario es responsable—.
Puedes especificar varias opciones al seleccionar contactos con «Add recipient» y así ampliar la notificación a más contactos. Checkmk eliminará automáticamente los contactos duplicados. Para que la regla tenga sentido, debes seleccionar al menos una opción.
Las dos opciones de «Restrict previous options to» funcionan de forma algo diferente.
Aquí, los contactos seleccionados con las otras opciones volverán a estar restringidos.
Con ellas también puedes crear un operador «AND» entre grupos de contactos, por ejemplo, para permitir que se envíen notificaciones a todos los contactos que sean miembros tanto del grupo «Linux» como del grupo «Data center».
Al introducir Explicit email addresses puedes notificar a personas que, de hecho, no están designadas como usuarios en Checkmk. Por supuesto, esto solo tiene sentido cuando se utiliza en el método de notificación que realmente envía correos electrónicos.
Si, en el método elegido, has seleccionado Suppress all previous, las notificaciones solo se eliminarán para el contacto seleccionado aquí.
|
Si utilizas un sistema de tickets, un servicio de mensajería o un motor de eventos como método de notificación, también debes tener en cuenta las notas sobre estos casos especiales. |
Condiciones para enviar notificaciones
Por el momento, puedes saltarte el paso «Sending conditions» para reglas sencillas. Estas son de interés principalmente si quieres configurar escalaciones.
Propiedades generales
Al igual que con todas las reglas de Checkmk, aquí puedes incluir una descripción y un comentario para la regla, o incluso desactivarla temporalmente.
Con la opción «Allow users to deactivate this notification» puedes permitir a los usuarios «darse de baja» de las notificaciones generadas por esta regla. Te mostramos cómo hacerlo con las notificaciones personales.
4.3. Configurar parámetros para los métodos de notificación
Puedes definir parámetros independientes para cada método de notificación. Estos parámetros se definen y gestionan por separado de las reglas de notificación propiamente dichas en Checkmk. Esto te permite utilizar los parámetros para varias reglas al mismo tiempo. Solo tienes que realizar los cambios de forma centralizada en un único lugar y obtendrás un aspecto uniforme para todas las notificaciones del mismo tipo, independientemente de las reglas que las activen.
Abre la vista general de todos los parámetros personalizables a través de Setup > Events > Notifications y el botón «Parameters for notifications methods»:
Desde aquí, puedes crear, realizar la edición y —si no se utilizan en ninguna regla— eliminar los parámetros generales de cada método.
4.4. Probar las reglas de notificación
Para probar las reglas de notificación, Checkmk ofrece una herramienta inteligente en Test notifications. Puedes usarla para simular una notificación para un host o servicio y ver cuáles de tus reglas de notificación son efectivas. Además de la simulación, también puedes hacer que se envíe la notificación.
La forma más rápida de acceder a la prueba de notificación es a través de Setup > Events > Test notifications. Además, hay otras opciones para acceder desde algunas vistas en la monitorización (lista de servicios y detalles del servicio) y en la configuración (propiedades del host), en cada caso en el menú Host > Test notifications.
Primero, 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 qué host o servicio debe ser. Como evento, puedes seleccionar un cambio de estado o el inicio de un tiempo de mantenimiento programado. Puedes añadir una descripción del evento en Plugin output. Utiliza la checkbox «Send out notification for specific method» para especificar si la notificación solo se simula o se envía realmente.
Por último, en «Advanced condition simulation» hay dos opciones más con las que puedes definir la hora y el número de notificaciones. Esto te permite probar reglas de notificación que solo se aplican durante un periodo determinado (por ejemplo, fuera del horario laboral) o que inician una escalada tras un número específico de notificaciones repetidas.
Haz clic en «Test notifications» para iniciar la prueba —y también el envío, si has seleccionado esta opción. Los resultados se muestran debajo de la caja «Test notifications»:
Primero aparece el resumen.
En «Test results» puedes ver cuántas reglas de notificación se aplican y cuántas notificaciones se generan a partir de ellas.
Si has seleccionado «Send out notification», aquí se muestra el «notifications have been sent out» del mensaje correspondiente.
Esto debe dar lugar inmediatamente a un correo electrónico sobre este problema.
La línea de abajo resume las notificaciones generadas a partir de tus entradas.
Al hacer 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.
Las dos secciones siguientes muestran más detalles:
En «Predicted notifications» puedes ver a quién y cómo se enviarí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 muestra una lista de las reglas de notificación que has creado aquí.
En este punto, solo es importante la primera columna de la tabla, que utiliza iconos para indicar cuáles de las reglas se aplican 
y cuáles no 
.
|
Como de costumbre, puedes seguir activando notificaciones directamente a través de la GUI como alternativa a probar las notificaciones mediante simulación, por ejemplo, con los comandos Send custom notification y Fake check results. |
4.5. Notificaciones que se repiten con periodicidad y escalado
En algunos sistemas, puede tener sentido no limitarse a una sola notificación cuando un problema persiste durante un periodo de tiempo prolongado, por ejemplo, en el caso de hosts cuya etiqueta del host Criticality esté configurada como Business critical.
Configurar notificaciones que se repiten periódicamente
Checkmk se puede configurar para que se envíen notificaciones sucesivas a intervalos fijos, hasta que el problema haya sido reconocido o resuelto.
La configuración para esto se encuentra en el conjunto de reglas Periodic notifications during host problems o, respectivamente, en el conjunto de reglas Periodic notifications during service problems:
Una vez activada esta opción, ante un problema persistente, Checkmk activará notificaciones periódicas a los intervalos configurados. Estas notificaciones recibirán un número incremental que comienza por 1 (para la notificación inicial).
Las notificaciones periódicas no solo son útiles para recordar un problema (y molestar al operador), sino que también sirven de base para las escaladas, lo que significa que, tras un tiempo definido, una notificación puede escalarse a otros destinatarios.
Configura las escaladas y entiéndelas
Para configurar una escalada, crea una regla de notificación adicional que utilice la condición «Restrict to notification number».
Si introduce un rango de 3 a 99999 para el número secuencial, esta regla entrará en vigor a partir de la tercera notificación. La escalada se puede realizar seleccionando otro método (por ejemplo, SMS) o notificando a otras personas (selección de contactos).
Con la opción «Throttling of 'Periodic notifications'», tras un tiempo determinado se puede reducir la frecuencia de repetición de las notificaciones, de modo que, por ejemplo, al principio se pueda enviar un correo electrónico cada hora y, más adelante, reducirlo a un correo electrónico al día.
Con varias reglas de notificación, puedes crear un modelo de escalado. Pero, ¿cómo funcionará este escalado en la práctica? ¿A quién se notifica y cuándo? Aquí tienes un ejemplo, implementado con una regla para notificaciones que se repiten con periodicidad, así como tres reglas de notificación: Por ejemplo:
En caso de que se detecte un problema en un servicio, se activará una notificación en forma de correo electrónico cada 60 minutos hasta que el problema se resuelva o se realice el Reconocimiento.
Las notificaciones de la uno a la cinco se envían a las dos personas responsables del servicio.
Las notificaciones de la seis a la diez también se envían al jefe de equipo correspondiente.
A partir de la notificación número once, se envía un correo diario a la dirección de la empresa.
A las 9 de la mañana, se produce un problema en las instalaciones. Se notifica el problema a los dos empleados responsables, pero no dan respuesta (por el motivo que sea). Así que a las 10, 11, 12 y a la 1 de la tarde, cada uno recibe nuevos correos electrónicos. A partir de la sexta notificación, a las 2 de la tarde, el jefe de equipo también recibe un correo electrónico; sin embargo, el problema sigue sin resolverse. A las 3, 4, 5 y 6 de la tarde, se envían más correos electrónicos a los miembros del equipo y al jefe de equipo.
A las 7 de la tarde, entra en vigor el tercer nivel de escalado: A partir de ahora, no se envían más correos electrónicos a los miembros del equipo ni al jefe de equipo. En su lugar, la dirección de la empresa recibe un correo electrónico todos los días a las 7 de la tarde hasta que se resuelva el problema.
En cuanto se solucione el problema y el servicio en Checkmk vuelva a estar «OK», se envía automáticamente un «todo en orden» al último grupo de personas notificado: Así que, en el ejemplo anterior, si el problema se soluciona antes de las 2 de la tarde, a los dos miembros del equipo; si se soluciona entre las 2 y las 7 de la tarde, a los miembros del equipo y al jefe del equipo; y después de las 7 de la tarde, solo a la dirección de la empresa.
4.6. Eliminar notificaciones por reglas
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 «Suppress all previous». 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 está parcialmente completado, y que debido a una serie de reglas se han activado las tres notificaciones siguientes:
| Quién (contacto) | Cómo (método) |
|---|---|
Harry Hirsch |
Correo electrónico |
Bruno Weizenkeim |
Correo electrónico |
Bruno Weizenkeim |
SMS |
Ahora viene la siguiente regla con el método «SMS» y la selección «Suppress all previous». La selección de contactos elige el grupo de contacto «Windows», del que forma parte Bruno Weizenkeim. Como resultado de esta regla, se elimina de la tabla la entrada «Bruno Weizenkeim / SMS», que queda así:
| Quién (contacto) | Cómo (método) |
|---|---|
Harry Hirsch |
Correo electrónico |
Bruno Weizenkeim |
Correo electrónico |
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:
Las reglas pueden suprimir (eliminar) notificaciones específicas.
Las reglas de eliminación deben ir después de las reglas que crean las notificaciones.
Una regla de eliminación no «elimina» realmente una regla anterior, sino que suprime las notificaciones generadas por (posiblemente varias) reglas anteriores.
Las reglas posteriores pueden restablecer las notificaciones suprimidas anteriormente.
4.7. Entrega sincrónica para correos electrónicos HTML
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), los datos de acceso y el método de cifrado:
En el historial del servicio en cuestión, podrás entonces realizar un seguimiento exacto del envío. Aquí tienes un ejemplo en el que un servicio —con fines de prueba— se configuró manualmente en 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 orden cronológico de abajo hacia arriba, tal y como ya los hemos presentado en el capítulo sobre el historial de notificaciones del artículo sobre los conceptos básicos de las notificaciones.
La diferencia importante es que ahora puedes ver en la entrada superior de 
que el correo electrónico se entregó correctamente al smarthost y que su respuesta es success.
También puedes seguir los pasos individuales en el archivo ~/var/log/notify.log.
Las siguientes líneas pertenecen al último paso y contienen la respuesta del servidor SMTP:
2021-08-26 10:02:22,016 [20] [cmk.base.notify] Got spool file d3b417a5 (mysrv;CPU load) for local delivery via mail
2021-08-26 10:02:22,017 [20] [cmk.base.notify] executing /omd/sites/mysite/share/check_mk/notifications/mail
2021-08-26 10:02:29,538 [20] [cmk.base.notify] Output: success 250 - b'2.0.0 Ok: queued as 1BE667EE7D6'El ID del mensaje 1BE667EE7D6 aparecerá en el archivo de registro del smarthost.
Allí, si te preocupa, puedes investigar dónde ha llegado el correo electrónico.
En cualquier caso, puedes demostrar que el correo electrónico se envió correctamente desde Checkmk y cuándo.
Repitamos la prueba anterior, pero esta vez con una contraseña mal configurada para la transferencia SMTP al smarthost.
Aquí puedes ver en texto sin formato 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 ser una buena solución. En su lugar, Checkmk muestra una advertencia clara con fondo rojo en el snap-in «Vista general»:
Aquí puedes:
Hacer clic en el texto «… failed notifications» para ver una lista de los envíos fallidos.
Haz clic en el icono «
» para confirmar estos mensajes y eliminar el aviso haciendo clic en «
» (Eliminar notificaciones) en la Vista general que se abre.
Importante: Ten en cuenta que el envío directo por SMTP en situaciones de error puede provocar que un script de notificación se ejecute durante mucho tiempo y que se produzca un timeout. Por este motivo, te recomendamos encarecidamente que utilices el spooler de notificación y que selecciones un envío asíncrono de las notificaciones.
El comportamiento ante errores repetitivos (como un timeout de SMTP) se puede definir con Global settings > Notifications > Notification spooler configuration por método de notificación:
Además de un timeout opcional (el valor predeterminado es 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, por lo tanto, envíe múltiples notificaciones (Maximum concurrent executions). Si el script de notificación es muy lento, una ejecución en paralelo puede tener sentido; sin embargo, el script debe estar programado de tal manera que las ejecuciones múltiples se ejecuten correctamente (y, por ejemplo, que el script no reserve ciertos datos para sí mismo).
Un envío múltiple y paralelo a través de SMTP no supone ningún problema, ya que el servidor de destino puede gestionar múltiples conexiones en paralelo. Este no es el caso cuando se envía directamente desde SMS a través de un módem sin un spooler adicional, y en este caso conviene mantener el valor 1.
Importante: ¡La entrega rastreable a través de SMTP no está disponible para notificaciones masivas!
5. Notificaciones masivas
5.1. Vista general
Cualquiera que trabaje con monitorización ha vivido alguna vez cómo un problema aislado desencadena una auténtica avalancha de notificaciones (sucesivas). El principio de los hosts principales es una forma de reducir esto en circunstancias específicas, pero por desgracia no sirve en todos los casos.
Puedes tomar como ejemplo el propio proyecto Checkmk: Una vez al día creamos paquetes de instalación de Checkmk para todas las distribuciones de Linux compatibles. Nuestra propia monitorización de Checkmk está configurada de tal manera que contamos con un servicio que solo entra en estado «OK» si se ha creado correctamente el número adecuado de paquetes. En ocasiones puede ocurrir que un error general en el software dificulte la creación de los paquetes, lo que provoca que 43 servicios entren simultáneamente en estado «CRIT».
Hemos configurado las notificaciones de tal manera que, en ese caso, solo se envíe un único correo electrónico que制表 las 43 notificaciones en orden. Esto es, naturalmente, 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 que pertenezca a un problema completamente distinto.
El funcionamiento de esta notificación masiva es muy sencillo. Cuando se produce una notificación, primero se retiene durante un breve periodo de tiempo. Las notificaciones posteriores que se produzcan durante este tiempo se añadirán inmediatamente al mismo correo electrónico. Esta agrupación se puede definir para cada regla. Así, por ejemplo, durante el día puedes trabajar con correos electrónicos individuales, pero por la noche con una notificación masiva. Si se activa una notificación masiva, por lo general se te ofrecerán las siguientes opciones:
El tiempo de espera se puede configurar como desees. En muchos casos basta con un minuto, ya que para entonces, a más tardar, deberían haber aparecido todos los problemas relacionados. Por supuesto, puedes establecer un tiempo más largo, pero eso provocará un retraso considerable en las notificaciones.
Dado que, naturalmente, no tiene sentido meterlo todo en el mismo saco, puedes especificar qué grupos de problemas deben notificarse de forma conjunta. La opción «Host» se utiliza muy a menudo: esto garantiza que solo se agrupen las notificaciones del mismo host.
Aquí tienes algunos datos adicionales sobre las notificaciones masivas:
Si la agrupación está activada en una regla, la activación se puede desactivar mediante una regla posterior, y viceversa.
La notificación masiva siempre se realiza por contacto. Cada contacto tiene, en efecto, su propio «contenedor de colección privado».
Puedes limitar el tamaño del contenedor (Max. notifications per bulk). Una vez alcanzado el máximo, la notificación masiva se enviará inmediatamente.
5.2. Notificaciones masivas y periodos de tiempo
¿Qué pasa cuando una notificación está dentro del periodo de notificación, pero la notificación masiva que contiene esta notificación —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 sencillo: todas las configuraciones que restringen las notificaciones a períodos de tiempo son válidas solo para la notificación en cuestión. La notificación masiva posterior siempre se entregará independientemente de todos los períodos de tiempo.
6. ¿Qué pasa si no hay ninguna regla aplicable?
Quien configura también puede cometer errores. Un posible error en la configuración de las notificaciones podría ser que se detecte un problema crítico de monitorización, pero que no se active ninguna regla de notificación.
Para protegerte de este tipo de situaciones, Checkmk ofrece la configuració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 recibirá las notificaciones a las que no se aplique ninguna regla de notificación.
|
Como alternativa, también puedes designar a un usuario como destinatario en su configuración personal. La dirección de correo electrónico almacenada con el usuario se utiliza como dirección de reserva. |
Sin embargo, la dirección de reserva solo se utilizará si no se aplica ninguna regla, ¡no cuando no se haya activado ninguna notificación! Como mostramos en la sección sobre la eliminación de notificaciones, la supresión explícita de notificaciones es deseable; no se trata de un error de configuración.
La introducción de una dirección de reserva se «recomendará» en la página Notifications con una advertencia en pantalla:
Si, por cualquier motivo, solo quieres deshacerte 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 tiene efecto en la configuración de notificaciones, ya que aún no se ha creado ninguna notificación aquí. Pero con esto te aseguras de que siempre se aplique al menos una regla, lo que permite eliminar esta advertencia.
Te desaconsejamos expresamente este enfoque, ya que podrías pasar por alto lagunas en tu secuencia de reglas.
|
Si solo quieres desactivar las notificaciones para ti personalmente, puedes hacerlo a través de las reglas de notificación personales. |