Consola de eventos

Como siempre en Checkmk, primero debes activar cambios para que surtan efecto. Esto no es un inconveniente, porque así, en el caso de cambios que afecten a varias reglas relacionadas, puedes especificar exactamente cuándo deben "activarse" las reglas. Y antes puedes utilizar la página Event Simulator para comprobar si todo se ajusta a lo previsto.

Primero, haz clic en el número de cambios acumulados en la parte superior derecha de la página.

A continuación, haz clic en Activate on selected sites para activar el cambio. La Consola de eventos está diseñada de tal forma que esta acción se ejecuta sin interrupciones. La recepción de mensajes entrantes está garantizada en todo momento, de modo que no se puede perder ningún mensaje en el proceso.

Sólo los administradores pueden activar cambios en la CE. Esto se controla mediante el permiso Activate changes for event console.

Por supuesto, ahora puedes enviar mensajes a través de Syslog o SNMP para hacer pruebas, pero para una primera prueba es más práctico el Event Simulator integrado en la CE:

Aquí tienes dos opciones:Try out evalúa en función del mensaje simulado cuál de las reglas coincidiría. Si estás en el nivel superior de la GUI de configuración de la CE, se resaltarán los paquetes de reglas. Si estás dentro de un paquete de reglas, se resaltarán las reglas individuales. Cada paquete o regla está marcado con uno de los tres símbolos siguientes:

Hacer clic en Generate event hace prácticamente lo mismo que Try out, sólo que ahora el mensaje se genera realmente.Cualquier acción definida se ejecuta realmente. Y el evento también aparecerá en los eventos abiertos en la monitorización. Puedes ver el código fuente del mensaje generado en la confirmación:

El evento generado aparece en el menú Monitor en Event Console > Events:

Para una primera prueba real a través de la red, puedes enviar fácilmente a mano un mensaje syslog desde otro ordenador Linux. Como el protocolo es tan sencillo, ni siquiera necesitas un programa especial, simplemente puedes enviar los datos a través de netcat o nc utilizando UDP. El contenido del paquete UDP consiste en una sola línea de texto. Si se ajusta a una estructura específica, la Consola de eventos desglosa los componentes limpiamente:

Pero también puedes enviar simplemente cualquier cosa. En ese caso, la CE lo aceptará igualmente y sólo lo evaluará como un texto de mensaje. Por supuesto, faltará información adicional como la aplicación, la prioridad, etc. Por motivos de seguridad, se asumirá el estado CRIT:

Dentro del site Checkmk que ejecuta la CE hay una tubería con nombre, en la que puedes escribir mensajes de texto localmente a través de echo. Éste es un método muy sencillo para conectar una aplicación local y también una forma de probar el proceso de los mensajes:

Por cierto, aquí también es posible enviar en formato syslog, para que todos los campos de los datos del evento se rellenen limpiamente.

El comando Update & Acknowledge muestra la siguiente zona encima de la lista de eventos:

Con el botón Update puedes, en una sola acción, añadir un comentario al evento, añadir una persona de contacto y reconocer el evento. El campo Change contact es intencionadamente de texto libre. Aquí también puedes introducir cosas como números de teléfono. En particular, este campo no influye en la visibilidad del evento en la GUI - es puramente un campo de comentario.

El checkbox Set event to acknowledged hará que el evento pase de la fase open a acknowledged, y en adelante se mostrará como handled. Esto es análogo al Reconocimiento de problemas de host y de servicio.

La invocación posterior del comando con el checkbox desmarcado elimina el Reconocimiento.

El comando Change State permite cambiar manualmente el estado de un evento, por ejemplo, de CRIT a WARN.

Con el comando Custom Action, se pueden ejecutar acciones libremente definibles sobre los eventos. Inicialmente, sólo está disponible la acción Send monitoring notification. Ésta enviará una notificación Checkmk que se gestionará de la misma forma que la de un servicio activamente monitorizado. Ésta pasa por las reglas de notificación y puede generar correos electrónicos, un SMS o lo que hayas configurado en consecuencia. Consulta más abajo los detalles sobre la notificación por la CE.

El botón Archive Event elimina permanentemente un evento de la lista de eventos abiertos. Dado que todas las acciones sobre los eventos -incluida esta eliminación- se registran también en el archivo, podrás seguir accediendo posteriormente a toda la información sobre el evento. Por eso no hablamos de eliminar, sino de archivar.

También puedes archivar cómodamente eventos individuales de la lista de eventos utilizando .

Para proporcionar visibilidad de los host y servicios en la monitorización para usuarios normales, Checkmk utiliza grupos de contacto. Estos grupos se asignan a los host y servicios mediante la configuración de la GUI, reglas o carpetas.

Con la Consola de eventos, la situación es que esa asignación de eventos a grupos de contacto no existe, porque sencillamente no se sabe de antemano qué mensajes se van a recibir realmente. Ni siquiera se conoce la lista de hosts, porque los sockets para Syslog y SNMP son accesibles desde todas partes. Por eso, la Consola de eventos incluye algunas funciones especiales para definir la visibilidad.

En primer lugar, al configurar los roles de usuario aparece el permiso Event Console > See all events. ¡Está activo por defecto, de modo que los usuarios normales pueden ver todos los eventos!Esto se establece deliberadamente para garantizar que los mensajes de error importantes no se queden por el camino debido a una configuración incorrecta. El primer paso para una visibilidad más precisa es eliminar este permiso del rol user.

Para que la visibilidad de los eventos sea lo más coherente posible con el resto de la monitorización, la Consola de eventos intenta, en la medida de lo posible, hacer coincidir los hosts de los que recibe eventos con los hosts configurados a través de la GUI de Configuración. Lo que parece sencillo es complicado en los detalles. A veces falta el nombre del host en el evento y sólo se conoce la dirección IP. En otros casos, el nombre del host está escrito de forma distinta a la que aparece en la GUI de Configuración.

La asignación se realiza del siguiente modo:

Puedes influir en la asignación en un punto: a saber, si los grupos de contacto están definidos en la regla y se puede asignar el host, el mapeo suele tener prioridad. Puedes cambiar esto en una regla con la opción Precedence of contact groups:

Además, puedes hacer ajustes directamente en la regla para la notificación. Esto permite dar prioridad al tipo de evento sobre las responsabilidades habituales de un host.

Tanto para los paquetes de reglas ...

... como para las reglas individuales ...

... en la columna Hits encontrarás la información sobre la frecuencia con la que el paquete o la regla ya ha coincidido con un mensaje. Esto te ayuda a eliminar o reparar las reglas ineficaces. Pero también puede ser interesante para las reglas que coinciden muy a menudo. Para un rendimiento óptimo de la CE, éstas deben estar al principio de la secuencia de reglas. De esta forma puedes reducir el número de reglas que la CE tiene que probar en cada mensaje.

Puedes restablecer los contadores en cualquier momento con el elemento de menú Event Console > Reset counters.

En Probar una regla ya has visto cómo puedes utilizar Event Simulator para comprobar las evaluaciones de tus reglas. Puedes obtener información similar en tiempo de ejecución para todos los mensajes, si en los ajustes de la Consola de eventos estableces el valor de Debug rule execution a on.

El archivo de registro de la Consola de eventos se encuentra en var/log/mkeventd.log, en el que encontrarás la razón exacta por la que alguna regla verificada no surtió efecto:

Huelga decir que debes utilizar este registro intensivo sólo cuando sea necesario y con precaución. ¡En un entorno sólo ligeramente más complejo se generarán enormes volúmenes de datos!

Para todas las condiciones que implican campos de texto, el texto de comparación siempre se trata como una expresión regular. La comparación siempre tiene lugar ignorando mayúsculas/minúsculas. Esto último es una excepción a las convenciones de Checkmk en otros módulos. Sin embargo, esto hace que la formulación de las reglas sea más robusta, especialmente porque los nombres del host en los eventos no son necesariamente consistentes en su ortografía si se han configurado en cada host localmente en lugar de centralmente. Por tanto, esta excepción es muy útil aquí.

Además, siempre se aplica una concordancia infix, es decir, un check del contenido del texto de búsqueda, por lo que puedes guardar un .* al principio o al final del texto de búsqueda.

Sin embargo, hay una excepción: si no se utiliza una expresión regular en la coincidencia con el nombre del host, sino un nombre del host explícito, se comprobará si hay coincidencia exacta y no si está contenido.

Atención: ¡Si el texto de búsqueda contiene un punto (.), se considerará una expresión regular y se aplicará la búsqueda infix, por ejemplo, mihost.com coincidirá también, por ejemplo, con notmyhostide!

Muy importante y útil aquí es el concepto de grupos de concordancia en el campo Text to match. Se refiere a las secciones de texto que coinciden con las expresiones entre paréntesis de la expresión regular.

Supongamos que quieres monitorizar el siguiente tipo de mensaje en el archivo de registro de una base de datos:

El WP41 es, por supuesto, variable y seguramente no querrás formular una regla distinta para cada instancia diferente, por lo que utilizarás .* en la expresión regular, que significa cualquier cadena:

Database instance .* has failed

Si ahora encierras la parte variable entre corchetes, la Consola de eventos memorizará(capturará) el valor real para cualquier acción futura:

Database instance (.*) has failed

Tras una coincidencia correcta de la regla, el primer grupo de concordancia se fija ahora en el valor WP41 (o en la instancia que haya producido el error).

Puedes ver estos grupos de concordancia en Event Simulator si pasas el cursor por encima de la bola verde:

También puedes ver los grupos en los detalles del evento generado:

Entre otras cosas, los grupos de concordancia se utilizan para:

Llegados a este punto, un consejo: Hay situaciones en las que necesitas agrupar algo en la expresión regular pero no quieres crear un grupo de concordancia. Puedes hacerlo colocando un ?: justo después del paréntesis de apertura. Ejemplo: La expresión one (.*) two (?:.*) three crea para una coincidencia en one 123 two 456 three sólo el único grupo de concordancia 123.

En el campo Match original source IP address puedes coincidir con la dirección IPv4 del remitente del mensaje. Especifica una dirección exacta o una red en la notación X.X.X.X/Y, por ejemplo 192.168.8.0/24 para coincidir con todas las direcciones de la red 192.168.8.X.

Ten en cuenta que la coincidencia en la dirección IP sólo funciona si los sistemas monitorizados envían directamente a la Consola de eventos. Si otro servidor de syslog intermedio conectado está reenviando los mensajes, su dirección aparecerá en su lugar como remitente en el mensaje.

Los campos Match syslog priority y Match syslog facility son información estandarizada, definida originalmente por la información Syslog. Internamente, un campo de 8 bits se divide en 5 bits para la facilidad (32 posibilidades) y 3 bits para la prioridad (8 posibilidades).

Las 32 facilidades predefinidas se pensaron en su día para algo como una aplicación, pero la selección no se hizo con mucha visión de futuro en aquel momento. Una de las facilidades es uucp, un protocolo que a principios de los 90 del milenio pasado ya estaba casi obsoleto.

Pero es un hecho que cada mensaje que llega a través de syslog lleva una de estas facilidades. En algunos casos también puedes asignarlas libremente al enviar el mensaje, para poder filtrarlas después, lo que resulta bastante útil.

El uso de la facilidad y la prioridad también tiene un aspecto de rendimiento. Si defines una regla que, en cualquier caso, sólo se aplica a los mensajes que tienen todos la misma facilidad o prioridad, debes definirlas adicionalmente en los filtros de la regla. La Consola de eventos podrá entonces omitir estas reglas de forma muy eficiente cuando se reciba un mensaje con valores diferentes. Cuantas más reglas tengan establecidos estos filtros, menos comparaciones de reglas serán necesarias.

El checkbox Negate match: Execute this rule if the upper conditions are not fulfilled. hace que la regla sólo tenga efecto cuando no se cumpla ninguna de las condiciones. En realidad, esto sólo es útil en el contexto de dos tipos de reglas (Rule type en la caja Outcome & Action de la regla):

A continuación puedes obtener más información sobre los paquetes de reglas.

Cuando una regla coincide, especifica lo que debe ocurrir con el mensaje. Esto se hace en la caja Outcome & Action:

El Rule type se puede utilizar para abortar la evaluación en el punto por completo o para el paquete de reglas actual. Especialmente la primera opción se debe utilizar para deshacerse de la mayor parte del "ruido" inútil utilizando unas pocas reglas específicas al principio. Sólo con las reglas "normales" se evalúan realmente las otras opciones de esta caja.

En State, la regla establece el estado del evento en la monitorización. En la regla, este estado será WARN o CRIT. Las reglas que generan eventos OK pueden ser interesantes en excepciones para representar determinados eventos de forma puramente informativa. En tal caso, resulta interesante una combinación con una caducidad automática de estos eventos.

Además de establecer un estado explícito, hay dos opciones más dinámicas. La opción (set by syslog) asume la clasificación basada en la prioridad syslog. Esto sólo funciona si el mensaje ya ha sido clasificado utilizable por el remitente. Los mensajes recibidos directamente por syslog contendrán una de las ocho prioridades RFC, que se mapean de la siguiente manera:

Además de los mensajes syslog, los mensajes del Registro de eventos de Windows y los mensajes de los archivos de texto que ya se han clasificado con el Plugin Checkmk logwatch en el sistema de destino, proporcionan estados listos para usar. Para los Trap SNMP, lamentablemente, esto no está disponible.

Un método completamente distinto es clasificar el mensaje basándose en el propio texto, lo que puede hacerse con la configuración (set by message text):

La coincidencia con los textos configurados aquí sólo se produce después de comprobar Text to match y de que se hayan comprobado las demás condiciones de la regla, de modo que no tengas que repetir esas comprobaciones.

Si no se encuentra ninguno de los patrones configurados, el evento devuelve el estado UNKNOWN.

La idea que subyace en el campo Service Level es que cada host y cada servicio de una organización tiene un determinado nivel de importancia, que puede asociarse a un acuerdo de servicio específico para el host o el servicio. En Checkmk, puedes utilizar reglas para asignar dichos niveles de servicio a tus hosts y servicios y luego, por ejemplo, hacer que la notificación o los dashboards autodefinidos dependan de ello.

Dado que los eventos no se correlacionan necesariamente con los host o servicios, la Consola de eventos te permite asignar un nivel de servicio a un evento mediante una regla. Posteriormente, puedes filtrar las vistas de eventos utilizando este nivel.

Por defecto, Checkmk define cuatro niveles: 0 (sin nivel), 10 (plata), 20 (oro) y 30 (platino). Puedes cambiar esta selección según necesites en Global settings > Notifications > Service Levels. Son decisivos los números que designan los niveles, ya que los niveles se ordenan por estos números y también se comparan según la importancia relativa.

Los grupos de contacto utilizados para la visibilidad también se utilizarán para la notificación de eventos. Aquí puedes utilizar reglas para asignar grupos de contacto explícitamente a los eventos. Encontrarás más detalles en el capítulo sobre monitorización.

Las acciones son muy similares a los Alert handlers para host y servicios. Aquí puedes hacer que se ejecute un script autodefinido cuando se abra un evento. Más adelante, en una sección aparte, encontrarás información detallada sobre las acciones.

El borrado automático (= archivado), que puedes configurar con Delete event immediately after the actions, garantiza que un evento no sea visible en la monitorización en absoluto. Esto es útil si sólo quieres activar algunas acciones automáticamente o si sólo quieres archivar ciertos eventos para poder buscarlos más tarde.

También puedes hacer que se ejecuten acciones automáticamente cuando se cancela un evento. Es importante saber que cuando se cancela un evento, una serie de campos de datos del evento se sobrescriben con valores del mensaje OK antes de que se ejecute ninguna acción. De este modo, los datos completos del mensaje OK están disponibles en el script de acción. Además, durante esta fase, el estado del evento se marca como OK. De este modo, un script de acción puede detectar una anulación y puedes utilizar el mismo script para mensajes de error y OK (por ejemplo, cuando te conectas a un sistema de tickets).

Los siguientes campos se sobrescriben a partir de los datos del mensaje OK:

Todos los demás campos permanecen inalterados, incluido el ID del evento.

Si utilizas la reescritura y la cancelación en la misma regla, debes tener cuidado al reescribir el nombre del host o la aplicación. Al cancelar, la CE siempre comprueba si el mensaje de cancelación coincide con el nombre del host y la aplicación del evento abierto. Pero si éstos se reescribiesen, la cancelación nunca funcionaría.

Por lo tanto, antes de cancelar el evento, la Consola de eventos simula una reescritura del nombre del host y de la aplicación para comparar los textos relevantes. Esto es probablemente lo que esperarías.

También puedes aprovechar este comportamiento si el campo de aplicación del mensaje de error y el posterior mensaje OK no coinciden. En este caso, simplemente reescribe el campo de aplicación a un valor fijo conocido, lo que de hecho conduce al resultado de que este campo será ignorado.

Hay situaciones (por desgracia) en las que el texto de los mensajes de error y OK es absolutamente idéntico. En la mayoría de los casos, el estado real no está codificado en el texto, sino en la prioridad del syslog.

Para ello existe la opción Syslog priority to cancel event. Introduce aquí el intervalo debug... notice, por ejemplo. Normalmente se considera que todas las prioridades de este intervalo tienen un estado OK. Cuando utilices esta opción, debes introducir igualmente un texto adecuado en el campo Text to cancel event(s), ya que de lo contrario la regla coincidirá con todos los mensajes OK que afecten a la misma aplicación.

Puedes activar el check de mensajes que ocurren con demasiada frecuencia con la opción Count messages in interval:

Aquí especificas primero un periodo de tiempo en Time period for counting y el número de mensajes que deben provocar la apertura de un evento en Count until triggered. En el ejemplo anterior, esto se establece en 10 mensajes por hora. Por supuesto, no se trata de 10 mensajes arbitrarios, sino de mensajes que coinciden con la regla.

Normalmente, tiene sentido no contar globalmente todos los mensajes coincidentes, sino sólo los que se refieren a la misma "causa". Para controlar esto, existen los tres checkbox de las opciones prefijadas por Force separate events for different …​. Están preconfigurados de tal forma que los mensajes sólo se cuentan juntos si coinciden en:

Esto te permite formular reglas como "Si se reciben más de 10 mensajes por hora del mismo host, la misma aplicación y allí el mismo site, entonces..." Debido a la regla, esto puede dar lugar a que se generen varios eventos diferentes.

Si, por ejemplo, desmarcas los tres checkbox, el recuento se hará sólo globalmente y la regla sólo podrá generar un evento en total.

Por cierto, puede tener sentido introducir 1 como recuento. De este modo podrás controlar eficazmente las "tormentas de eventos". Si, por ejemplo, en un breve espacio de tiempo se reciben 100 mensajes del mismo tipo, sólo se creará un evento. Verás en los detalles del evento

A continuación, mediante dos checkbox puedes definir cuándo debe abrirse un nuevo evento. Normalmente, el Reconocimiento del evento crea una situación en la que, si se reciben más mensajes, se inicia un nuevo recuento y se activa un nuevo evento. Puedes desactivar esta función con Continue counting when event is acknowledged.

La opción Discontinue counting after time has elapsed garantiza que siempre se abra un evento distinto para cada periodo de comparación. En el ejemplo anterior, se especificó un umbral de 10 mensajes por hora. Si esta opción está activada, se añadirá un máximo de 10 mensajes de una hora a un evento ya abierto. En cuanto haya transcurrido la hora, si se ha recibido un número suficiente de mensajes, se abrirá un nuevo evento.

Por ejemplo, si estableces el número en 1 y el intervalo de tiempo en un día, sólo verás un máximo de un evento de este tipo de mensaje al día.

La configuración de Algorithm puede resultar un poco sorprendente a primera vista, pero seamos realistas: ¿qué quieres decir realmente con "10 mensajes por hora"? ¿A qué hora te refieres con eso? ¿Siempre a horas completas del día? Podría ser que en el último minuto de una hora se recibieran nueve mensajes, y otros nueve en el primer minuto de la hora siguiente. Eso hace entonces 18 mensajes en sólo dos minutos de tiempo transcurrido, pero siguen siendo menos de 10 por hora, por lo que la regla no se aplicaría. Eso no suena muy razonable...

Como no hay una solución única a este problema, Checkmk proporciona tres definiciones diferentes de lo que debe significar exactamente "10 mensajes por hora":

Entonces, ¿qué algoritmo debes elegir?

Los eventos que aún no han alcanzado el número establecido, están latentes pero no son visibles automáticamente para el operador. Están en la fase counting. Puedes hacer visibles estos eventos con el filtro phase en la vista de tabla:

Al igual que la llegada de un mensaje concreto puede significar un problema, la ausencia de un mensaje también puede significar un problema. Puedes esperar al menos un mensaje al día de un trabajo concreto. Si este mensaje no llega, es probable que el trabajo no esté funcionando y deba arreglarse urgentemente.

Puedes configurar algo así en Counting & Timing > Expect regular messages:

Al igual que con el recuento, tienes que especificar un periodo de tiempo en el que esperas que aparezca el mensaje o mensajes. Aquí, sin embargo, se utiliza un algoritmo completamente diferente, que tiene mucho más sentido en este punto. La periodicidad siempre se alinea exactamente con las posiciones definidas. Por ejemplo, el intervalo hour siempre comienza en el minuto y segundo cero. Tienes las siguientes opciones:

¿Por qué es tan complicado? Para evitar falsas alarmas. ¿Esperas un mensaje de copia de seguridad al día, por ejemplo? Seguramente habrá ligeras diferencias en el tiempo de ejecución de la copia de seguridad, de modo que los mensajes no se reciban exactamente con 24 horas de diferencia. Por ejemplo, si esperas que el mensaje llegue hacia medianoche, más o menos una hora o dos, un intervalo de 12:00 a 12:00 será mucho más realista que uno de 00:00 a 00:00. Sin embargo, si el mensaje no aparece, sólo recibirás una notificación a las 12:00 del mediodía.

La opción Merge with open event está preconfigurada de forma que, en caso de que aparezca repetidamente el mismo mensaje, se actualizará el evento existente. Puedes modificarlo para que se abra un nuevo evento cada vez.

Con el botón Add new action puedes crear una nueva acción. El siguiente ejemplo muestra cómo crear un simple script shell como una acción del tipo Execute Shell Script. Los detalles de los eventos están disponibles para el script a través de variables de entorno, por ejemplo la $CMK_ID del evento, la $CMK_HOST, el texto completo $CMK_TEXT o el primer grupo de coincidencia como $CMK_MATCH_GROUP_1. Para obtener una lista completa de las variables de entorno disponibles, consulta la ayuda en línea.

Las versiones anteriores de Checkmk permitían variables del entorno, así como macros como $TEXT$, que se sustituían antes de ejecutar el script. Debido al peligro de que un atacante pueda inyectar comandos a través de un paquete UDP especialmente diseñado que se ejecute con los privilegios del proceso de Checkmk, no debes hacer uso de macros. Actualmente, las macros siguen admitiéndose por motivos de compatibilidad, pero nos reservamos el derecho a eliminarlas en una versión futura de Checkmk.

El script de ejemplo que se muestra en la captura de pantalla crea el archivo tmp/test.out en el directorio del site, en el que escribe un texto que contiene los valores concretos de las variables para el último evento correspondiente:

Los scripts se ejecutan en el siguiente entorno:

Si es posible que tu script contenga tiempos de espera, puedes hacer que se ejecute de forma asíncrona utilizando el spooler de Linux at. Para ello, crea el script en un archivo separado local/bin/myaction e inícialo con el comando at, por ejemplo:

El tipo de acción Send Email envía un simple correo electrónico de texto. En realidad, también podrías hacerlo con un script, por ejemplo utilizando el comando de línea de comandos mail. Pero de esta forma es más cómodo. Ten en cuenta que también se permiten marcadores de posición en los campos Recipient email address y Subject.

Los eventos pueden proceder de cualquier host, independientemente de si están configurados en la monitorización activa o no. Al fin y al cabo, los puertos syslog y SNMP están abiertos a todos los hosts de la red. Como resultado, los atributos extendidos del host, como alias, tags del host, contactos, etc., no están disponibles inicialmente. Por eso, en particular, las condiciones de las reglas de notificación no funcionan necesariamente como cabría esperar.

Por ejemplo, al notificar, la CE intenta encontrar un host dentro de la monitorización activa que coincida con el evento. Para ello se utiliza el mismo procedimiento que para la visibilidad de los eventos. Si se encuentra un host de este tipo, se toman los siguientes datos de este host

Como resultado, el nombre del host en la notificación procesada puede no coincidir exactamente con el nombre del host en el mensaje original. Sin embargo, la codificación de los textos de notificación que se ajustan a los de la monitorización activa simplifica la formulación de reglas de notificación uniformes que incluyen condiciones que se aplican al nombre del host.

El mapeo se realiza en tiempo real enviando una consulta Livestatus al core de monitorización que se ejecuta en el mismo site que el CE que recibió el mensaje. Por supuesto, ¡esto sólo funciona si los mensajes syslog, Trap SNMP, etc. se envían siempre al site Checkmk en el que se está monitorizando activamente el host!

Si la consulta no funciona o no se puede encontrar el host, se aceptarán datos sustitutivos:

Si no se puede asignar el host en la monitorización activa, esto puede dar lugar, por supuesto, a problemas con las notificaciones. Por un lado, debido a las condiciones, que entonces pueden dejar de aplicarse, y también debido a la selección de contactos. Para estos casos, puedes modificar tus reglas de notificación, de modo que las notificaciones de la Consola de eventos se gestionen específicamente utilizando sus propias reglas. Para ello hay una condición independiente con la que puedes hacer coincidir positivamente sólo a las notificaciones de la CE, o viceversa, excluirlas:

Para que las notificaciones de la CE pasen a través del sistema de notificación de la monitorización activa, la CE debe adaptarse para ajustarse a su esquema. En el proceso, los campos de datos típicos de una notificación se rellenan de la forma más eficaz posible. Acabamos de describir cómo se determinan los datos del host. Otros campos son:

Como se ha descrito anteriormente, puede que no sea posible determinar automáticamente los contactos para un evento. En tales casos, puedes especificar los grupos de contacto directamente en la regla de notificación que se va a utilizar. Es importante que no olvides marcar la caja Use in notifications:

Existe un conmutador central para notificaciones en el snap-in Master control. Esto también se aplica a las notificaciones reenviadas por la CE:

Al igual que con la asignación de host, la consulta del conmutador por parte de la CE requiere el acceso de Livestatus al núcleo local de monitorización. Una consulta realizada con éxito puede verse en el archivo de registro de la Consola de Eventos:

La Consola de eventos es capaz de detectar host que se encuentran en un tiempo de mantenimiento programado y no envía notificaciones en tales situaciones. En el archivo de registro tendrá el siguiente aspecto:

Por supuesto, esto también requiere que el host se encuentre correctamente en la monitorización activa. Si esto no se consigue, se asume que el host no está en tiempo de mantenimiento y, en cualquier caso, se generará una notificación.

Cuando escribas tus propios scripts de notificación, especialmente para las notificaciones procedentes de la Consola de eventos, dispondrás de una serie de variables adicionales que describen el evento original (a las que se accede como siempre con el prefijo NOTIFY_):

Para medir tu rendimiento existe un snap-in independiente para la barra lateral con el nombre Event Console Performance. Puedes incluirlo de la forma habitual con :

Los valores que se muestran aquí son promedios de aproximadamente el último minuto. Una tormenta de eventos que dure sólo unos segundos no puede leerse aquí directamente, pero las cifras se han suavizado un poco y, por tanto, son más fáciles de leer.

Para probar el máximo rendimiento, puedes generar artificialmente una tormenta de mensajes sin clasificar (¡por favor, sólo en el sistema de pruebas!), por ejemplo, en un bucle de shell escribiendo continuamente el contenido de un archivo de texto en la tubería de eventos.

Las lecturas más importantes del snap-in tienen el siguiente significado:

Puedes ver cuántos mensajes puede procesar por segundo la Consola de eventos en Processing time per message. Este tiempo suele estar relacionado con el número de reglas que hay que probar antes de procesar un mensaje. Aquí tienes varias opciones de optimización:

Además, hay una optimización en la CE basada en la prioridad y la facilidad del syslog. Para cada combinación de prioridad y facilidad, se crea internamente una secuencia de reglas independiente en la que sólo se incluyen las reglas que son relevantes para los mensajes de esta combinación.

Cada regla que contenga una condición sobre la prioridad, la facilidad o, preferiblemente, ambas, no se incluirá en todas estas cadenas de reglas, sino, de forma óptima, sólo en una. Esto significa que no es necesario comprobar la regla para mensajes con una clasificación syslog diferente.

Tras un reinicio, en ~/var/log/mkeventd.log verás un resumen de las cadenas de reglas optimizadas:

En el ejemplo anterior puedes ver que, en cualquier caso, hay 67 reglas que deben comprobarse. Para los mensajes de la instalación daemon son relevantes 89 reglas, sólo para la combinación daemon/emerg deben comprobarse 120 reglas. Cada regla que recibe una condición sobre la prioridad o la instalación reduce aún más el número de 67.

Por supuesto, ¡sólo puedes establecer estas condiciones si estás seguro de que las cumplen los mensajes correspondientes!

La Consola de eventos tiene una protección automática contra el "desbordamiento", que limita el número de eventos actuales por host, por regla y globalmente. No sólo se cuentan los eventos abiertos, sino también los eventos en otras fases, como delayed o counting. Los eventos archivados no se cuentan.

Esto te protegerá en situaciones en las que, debido a un problema sistemático en tu red, se estén inundando miles de eventos críticos y la Consola de eventos se "apagaría". Por un lado, esto evita una degradación del rendimiento de la Consola de eventos, que tendría que retener demasiados eventos en su memoria principal. Por otro lado, la Vista general para el operador está (en cierto modo) protegida y los eventos que no forman parte de la tormenta permanecen visibles.

Una vez alcanzado el límite, se producirá una de las siguientes acciones:

Los límites, así como el efecto asociado al alcanzarlos, se definen en la configuración de la Consola de eventos con Limit amount of current events. La siguiente figura muestra la configuración por defecto:

Si has habilitado un valor con …​create overflow event, cuando se alcance el límite, se creará un único evento artificial, informando al operador de la situación de error:

Si además has habilitado un valor con …​notify contacts, se notificará a los contactos adecuados mediante la notificación de Checkmk. Esa notificación pasará por las reglas de notificación de Checkmk. Estas reglas no tienen por qué seguir la selección de contactos de la Consola de eventos, pero pueden modificarla. La siguiente tabla muestra qué contactos se seleccionan si has configurado Notify all contacts of the notified host or service (que es la configuración por defecto):