 |
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
Una función muy útil del sistema de notificaciones de Checkmk es aquella que permite a los usuarios —incluso a los que no tienen derechos de administrador— personalizar las notificaciones. Los usuarios pueden:
Añadir notificaciones que de otro modo no recibirían («suscribirse»)
Eliminar las notificaciones que recibirían de otro modo (si no hay restricciones)
Personalizar los parámetros de las notificaciones
Desactivar por completo todas sus notificaciones
2. Gestionar las notificaciones con reglas personalizadas
Desde el punto de vista del usuario, el punto de acceso es el menú Usuario, y allí la opción «Notification rules». En la página «Your personal notification rules», puedes crear una nueva regla con «Add rule».
El contenido de las reglas de notificación personales es similar al de las reglas de notificación globales, con una diferencia: no incluyen una selección de contacto. El propio usuario queda seleccionado automáticamente como contacto. Esto significa que un usuario solo puede añadir o eliminar sus propias notificaciones personales.
Sin embargo, el usuario solo puede eliminar notificaciones si la opción «Allow users to deactivate this notification» está activada en la regla (global) que las crea:
En el orden de las reglas de notificación, las reglas personales siempre vienen después de las reglas globales y, por lo tanto, pueden ajustar la tabla de notificaciones que se ha generado hasta ese momento. Así que, salvo por el bloqueo de eliminación que acabamos de describir, las reglas globales siempre se aplican como configuración predeterminada que el usuario puede personalizar.
 |
Los cambios en las reglas de notificación no requieren activación, sino que surten efecto de inmediato. |
2.1. Estructura de las reglas de notificación
A continuación, te presentamos la estructura general de las reglas de notificación personales con las definiciones de las propiedades generales, el método de notificación y las condiciones.
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.
Método de notificación
El método de notificación especifica la técnica que se utilizará para enviar la notificación, por ejemplo, mediante correo electrónico HTML.
Cada método se implementa mediante un script. Checkmk incluye varios scripts. También puedes escribir fácilmente tus propios scripts 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.
Un método puede incluir parámetros, como permitir que el método que envía correos electrónicos ASCII y HTML establezca explícitamente la dirección de correo electrónico del remitente (From:), por ejemplo.
Antes de realizar ajustes directamente en la regla de notificación, debes saber que los parámetros de los métodos de notificación también se pueden especificar a través de reglas para hosts y servicios: En Setup > Services > Service monitoring rules, en la sección «Notifications», encontrarás un conjunto de reglas para cada método de notificación, que puedes usar para definir los mismos ajustes —y, como es habitual, pueden depender del host o del servicio.
Las definiciones de parámetros en las reglas de notificación permiten variar esta configuración en casos concretos. Así, por ejemplo, puedes definir un asunto global para tu correo electrónico, pero también definir un asunto alternativo con una regla de notificación individual.
En lugar de parámetros, también puedes seleccionar «Cancel previous notifications», con lo que se eliminarán todas las notificaciones de este método procedentes de reglas anteriores. Para más información al respecto, consulta el tema «Eliminar notificaciones».
|
Para muchos métodos de notificación destinados al reenvío 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. Cuando utilices 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
Las condiciones determinan cuándo se utilizará una regla. Para entenderlo, 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
/tmpo si un host está en un grupo del host específico—al estado actual o al 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.
Supongamos que quieres que se active una notificación cuando se produzca un evento de monitorización para un servicio cuyo nombre comience por NTP en una carpeta de la carpeta Main:
Supongamos además que esta condición se amplía ahora para notificar también todos los cambios de estado de un host al estado DOWN:
El resultado de esta regla de notificación con las tres condiciones individuales es que nunca se producirá una notificación, ya que ningún evento de monitorización contendrá el cambio de estado de un host y el nombre del servicio con NTP.
La siguiente nota se repite de vez en cuando en el Manual de usuario. Sin embargo, en relación con la configuración de tus notificaciones, conviene volver a insistir en ello: Consulta la ayuda en línea con Help > Show inline help para obtener detalles sobre el efecto de las distintas condiciones. El siguiente extracto de la ayuda en línea para la opción Match services ilustra muy bien el comportamiento: «Nota: Las notificaciones de host nunca coincidirán con esta regla si se utiliza esta opción».
La excepción a la operación AND
Solo si un evento de monitorización cumple todas las condiciones configuradas, se aplicará la regla de notificación. Como se ha mencionado anteriormente, hay una excepción importante a esta regla general: para las condiciones Match host event type y Match service event type:
Si seleccionas solo «Match host event type», la regla no tendrá coincidencia con ningún evento de servicio. Lo mismo ocurre con la selección de eventos de «Match service event type» y de host. Sin embargo, si activas ambas condiciones, la regla tendrá coincidencia si el tipo de evento está activado en cualquiera de las dos listas de checkboxes. En este caso excepcional, estas condiciones no se vincularán con un «AND» lógico, sino con un «OR». De esta forma, puedes gestionar fácilmente las notificaciones de host y de servicio con una sola regla.
Otro consejo sobre las condiciones «Match contacts» y «Match contact groups»:
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 utilizar 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.
2.2. 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 «Cancel previous notifications». Para poder entender el funcionamiento de una regla de este tipo, lo mejor es visualizar la tabla de notificaciones.
Supongamos que ya se han procesado algunas reglas para un evento de monitorización específico. Esto ha generado dos notificaciones para nuestro usuario, una por correo electrónico y otra por SMS.
Ahora llega la siguiente regla con el método «SMS» y la selección «Cancel previous notifications». Como resultado de esta regla, se eliminará la notificación por SMS a nuestro usuario y solo se generará un 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.
2.3. Entrega sincrónica para correos electrónicos HTML
Puedes seleccionar y configurar el envío 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:
Para obtener más información sobre cómo rastrear el envío correcto o fallido en la interfaz de usuario de Checkmk y en los archivos de registro, consulta el artículo sobre reglas de notificación globales.
Importante: ¡Las notificaciones rastreables no están disponibles para las notificaciones masivas!
3. Notificaciones masivas
3.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 colecció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 privada».
Puedes limitar el tamaño del «bote» (Maximum bulk size). Una vez alcanzado el máximo, la notificación masiva se enviará inmediatamente.
3.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 periodos 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 periodos de tiempo.
4. Configuración del administrador
4.1. Desactivar temporalmente las notificaciones
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á configurado como no para el rol de usuario user de forma predeterminada.
Un usuario solo verá las checkboxes correspondientes en su configuración personal si le 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 no se dispone del permiso descrito anteriormente. Encontrarás esta configuración en Setup > Users > Users y, a continuación, en las propiedades del perfil de usuario.
Con esto, por ejemplo, puedes silenciar muy rápidamente las notificaciones de un compañero que está de vacaciones, sin necesidad de modificar la configuración real.
4.2. Impedir las personalizaciones definidas por el usuario
Si quieres impedir las personalizaciones por completo, puedes revocar el permiso «General Permissions > Edit personal notification settings» del rol «user».
Como administrador, puedes mostrar todas las reglas de usuario seleccionando «Setup > Events > Notifications» y, a continuación, la entrada del menú «Display > Show user rules»:
Después de las reglas globales, se muestra una lista de reglas personales, que también puedes editar con 
.