 |
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
1.1. Los eventos no son estados
La tarea principal de Checkmk es la monitorización activa de estados. En cualquier momento, cada servicio monitorizado se encuentra en uno de los siguientes estados: OK, WARN, CRIT o UNKNOWN. Mediante sondeos regulares, la monitorización actualiza constantemente su visión de la situación actual.
Un tipo de monitorización completamente diferente es el que maneja los eventos. Un ejemplo de evento es una excepción que se produce en una aplicación. La aplicación puede permanecer en el estado «OK» y seguir funcionando correctamente, pero algo ha pasado.
1.2. La Consola de eventos
Con la Consola de eventos (EC, por sus siglas en inglés), Checkmk ofrece un sistema totalmente integrado para la monitorización de eventos procedentes de fuentes como syslog, Traps SNMP, registros de eventos de Windows, archivos de registro y aplicaciones propias. Los eventos no se definen simplemente como estados, sino que forman una categoría propia y, de hecho, Checkmk los muestra como información independiente en la barra lateral «Overview».
Internamente, los eventos no son procesados por el core de monitorización, sino por un servicio independiente: el daemon de eventos (mkeventd).
La Consola de eventos también cuenta con un archivo donde puedes buscar eventos pasados. Sin embargo, hay que decir desde el principio que esto no sustituye a un archivo de registros propiamente dicho. La función de la Consola de eventos es filtrar de forma inteligente un pequeño número de mensajes relevantes de un gran flujo. Está optimizada para la simplicidad, la robustez y el rendimiento, no para almacenar grandes volúmenes de datos.
Un breve resumen de las funciones de la EC:
Puede recibir mensajes directamente a través de syslog o Traps SNMP. Por lo tanto, no es necesaria una configuración de los servicios del sistema Linux correspondientes.
También puede evaluar archivos de registro de texto y registros de eventos de Windows utilizando los agentes Checkmk.
Clasifica los mensajes basándose en secuencias de reglas definidas por el usuario.
Puede correlacionar, resumir, contar, anotar y reescribir mensajes, así como tener en cuenta sus relaciones temporales.
Puede realizar acciones automatizadas y enviar notificaciones a través de Checkmk.
Está totalmente integrado en la interfaz de usuario de Checkmk.
Está incluido y listo para usar en cualquier versión actual del sistema Checkmk.
1.3. Terminología
La Consola de eventos recibe mensajes (principalmente en forma de mensajes de registro). Un mensaje es una línea de texto con varios atributos adicionales posibles, por ejemplo, una marca de tiempo, el nombre del host, etc. Si el mensaje es relevante, se puede convertir directamente en un evento con los mismos atributos, pero:
Un mensaje solo se convertirá en un evento si se aplica una regla.
Las reglas pueden realizar la edición del texto y otros atributos de los mensajes.
Se pueden combinar varios mensajes en un solo evento.
Los mensajes también pueden cancelar eventos actuales.
Se pueden generar eventos artificiales si no aparecen ciertos mensajes.
Un evento puede pasar por varias fases:
Abierto |
El estado «normal»: ha ocurrido algo: el operador debe ocuparse de ello. |
Reconocido |
Se ha reconocido el problema; esto es similar a los problemas de host y de servicio en la monitorización basada en el estado. |
En recuento |
Aún no han llegado el número requerido de mensajes especificados: la situación aún no es problemática. Por lo tanto, el evento aún no se muestra al operador. |
Retrasado |
Se ha recibido un mensaje de error, pero la Consola de eventos sigue esperando a ver si se recibe el mensaje «OK» correspondiente dentro del tiempo configurado. Solo entonces se mostrará el evento al operador. |
Cerrado |
El operador o el sistema han cerrado el evento y solo se encuentra en el archivo. |
Un evento también tiene un estado. Sin embargo, en sentido estricto, aquí no se refiere al estado del evento en sí, sino al estado del servicio o dispositivo que envió el evento. Para usar una analogía con la monitorización basada en el estado, un evento también puede marcarse como «OK», «WARN», «CRIT» o «UNKNOWN».
2. Configuración de la Consola de eventos
Configurar la Consola de eventos es muy sencillo, ya que forma parte integral de Checkmk y se activa automáticamente.
Sin embargo, si quieres recibir mensajes syslog o Traps SNMP a través de la red, debes habilitarlo por separado. El motivo es que ambos servicios necesitan abrir un puerto UDP con un número de puerto específico. Y como solo un site de Checkmk por sistema puede hacerlo, la recepción a través de la red está desactivada por defecto.
Los números de puerto son:
| Protocolo | Puerto | Servicio |
|---|---|---|
UDP |
162 |
Traps SNMP |
UDP |
514 |
Syslog |
TCP |
514 |
Syslog a través de TCP |
El ssyslog a través de TCP se usa muy poco, pero tiene la ventaja de que la transmisión de mensajes está protegida. Con UDP nunca se puede garantizar que los paquetes lleguen realmente. Y ni el ssyslog ni las Traps SNMP ofrecen Reconocimientos o protección similar contra la pérdida de mensajes. Para poder usar el ssyslog a través de TCP, el sistema emisor debe, por supuesto, poder enviar mensajes a través de este puerto.
En la Appliance Checkmk, puedes habilitar la recepción de syslog/Traps SNMP en la configuración del site.
Si no, simplemente usa omd config.
Encontrarás la configuración necesaria en Addons:
En omd start puedes ver, en la línea que contiene mkeventd, qué interfaces externas tiene abiertas tu EC:
3. Primeros pasos con la Consola de eventos
3.1. Reglas, reglas, reglas
Al principio se mencionó que la EC se usa para filtrar y mostrar mensajes relevantes. Sin embargo, la triste realidad es que la mayoría de los mensajes —ya sean de archivos de texto, del registro de eventos de Windows o del syslog— no tienen mucha importancia. Tampoco ayuda que los mensajes ya hayan sido preclasificados por quien los generó.
Por ejemplo, en syslog y en el registro de eventos de Windows, los mensajes se clasifican en categorías similares a OK, WARN y CRIT. Pero lo que realmente significan WARN y CRIT puede definirlo subjetivamente el programador. Y ni siquiera se puede afirmar con certeza que la aplicación que ha generado el mensaje sea importante en este ordenador. En resumen: no puedes evitar tener que configurar qué mensajes te parecen un problema real y cuáles se pueden descartar sin más.
Como en todo Checkmk, la configuración se realiza mediante reglas, que el EC realiza para cada mensaje entrante según el principio de «primera coincidencia». La primera regla que se aplica a un mensaje entrante decide su destino. Si no se aplica ninguna regla, el mensaje simplemente se descartará en silencio.
Dado que con el tiempo se suelen acumular muchas reglas para el EC, estas se organizan en paquetes. El proceso de las reglas se realiza paquete por paquete y, dentro de cada paquete, de arriba abajo, por lo que el orden de procesamiento de estos paquetes es importante.
3.2. Crear una regla sencilla
Como era de esperar, la interfaz de configuración del EC se encuentra en el menú «Setup», en «Events > Event Console». Out of the box, solo encontrarás el paquete «Default rule pack», que en realidad no contiene ninguna regla. Por lo tanto, como ya se ha mencionado, los mensajes entrantes se descartan y tampoco se registran. El módulo en sí tiene este aspecto:
Empieza creando un nuevo paquete de reglas con «
» y «Add rule pack»:
Como siempre, el ID es una referencia interna y no se puede cambiar más adelante. Después de guardar, encontrarás la nueva entrada en la lista de tus paquetes de reglas:
Allí puedes ahora switch al paquete de reglas, que aún está vacío, con 
y crear una nueva regla con Add rule.
Rellena solo la primera caja con el encabezado Rule Properties:
Lo único necesario es un Rule ID único. Este ID aparecerá más adelante en los archivos de registro y se almacenará junto con los eventos generados. Por eso es recomendable asignar los ID con nombres significativos de forma sistemática. El resto de campos son opcionales. Esto es especialmente cierto en el caso de las condiciones.
Importante: Esta nueva regla es solo un ejemplo para pruebas y se aplicará a todos los eventos. Por lo tanto, también es importante que más adelante la elimines o, al menos, la desactives; de lo contrario, tu Consola de eventos se inundará con todo tipo de mensajes inútiles y quedará prácticamente inservible.
Activación de los cambios
Como siempre en Checkmk, primero debes activar los cambios para que surtan efecto. Esto no es una desventaja, ya que de esta manera, para los cambios que afectan a varias reglas relacionadas, puedes especificar exactamente cuándo deben entrar en vigor las reglas. Y antes puedes usar la herramienta de simulación de cambios (Event Simulator) para comprobar si todo funciona como se espera.
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 manera que esta acción se ejecuta sin interrupciones. La recepción de mensajes entrantes está garantizada en todo momento, de modo que no se pierda ningún mensaje durante el proceso.
Solo los administradores pueden activar cambios en la EC. Esto se controla mediante el permiso «Activate changes for event console».
Probar la nueva regla
Para probarlo, por supuesto, ahora podrías enviar mensajes a través de syslog o SNMP. También deberías hacerlo más adelante. Pero para una primera prueba, el «Event Simulator» integrado en la EC es más práctico:
Aquí tienes dos opciones: el « Try out» evalúa, basándose en el mensaje simulado, cuál de las reglas tendría una coincidencia. Si te encuentras en el nivel superior de la GUI de configuración del EC, 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:
|
Esta regla es la primera en aplicarse al mensaje y, por lo tanto, determina su destino. |
|
Esta regla se aplicaría, pero el mensaje ya ha sido manejado por una regla anterior. |
|
Esta regla no se aplica. Muy útil: si pasas el ratón por encima de la bola gris, obtienes una explicación de por qué no se aplica la regla. |
Hacer clic en «Generate event» hace casi lo mismo que «Try out», solo que ahora el mensaje se genera realmente. Cualquier acción definida se ejecuta realmente. Y el evento aparecerá entonces también en los eventos abiertos de la monitorización. Puedes ver el código fuente del mensaje generado en la confirmación:
El evento generado aparece en el menú «Monitor» (Generar mensajes) bajo «Event Console > Events» (Generar mensajes):
Generar mensajes manualmente para probar
Para una primera prueba real a través de la red, puedes enviar fácilmente un mensaje syslog desde otro ordenador Linux de forma manual.
Dado que 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 esta se ajusta a una estructura específica, la Consola de eventos desglosa los componentes de forma clara:
Pero también puedes enviar cualquier cosa. La EC lo aceptará de todos modos y lo evaluará simplemente 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 de Checkmk donde se ejecuta el EC hay una tubería con nombre, en la que puedes escribir mensajes de texto localmente a través de echo.
Este es un método muy sencillo para establecer una conexión con una aplicación local y también una forma de probar el procesamiento de mensajes:
Por cierto, aquí también es posible enviar en formato syslog, de modo que todos los campos de los datos del evento se rellenen correctamente.
3.3. Configuración de la Consola de eventos
La Consola de eventos tiene su propia configuración global, que no se encuentra junto a la de los demás módulos, sino en «Setup > Events > Event Console» (Configuración > Configuración de la consola de eventos) con el botón «Settings» (Configurar).
Como siempre, puedes encontrar explicaciones sobre cada configuración en la ayuda en línea y en los apartados correspondientes de este artículo.
Se puede acceder a la configuración mediante el permiso «Configuration of Event Console», que por defecto solo está disponible en el rol «admin».
3.4. Permisos
La Consola de eventos también tiene su propia sección para roles y permisos:
Analizaremos algunos de estos permisos con más detalle en los apartados correspondientes de este artículo.
3.5. Asignación de hosts en la Consola de eventos
Una característica especial de la Consola de eventos es que, a diferencia de la monitorización basada en el estado, los hosts no son el centro de atención. Los eventos pueden ocurrir sin ninguna asignación explícita de host, lo cual, de hecho, suele ser deseable. Sin embargo, debería ser posible realizar una asignación para los hosts que ya están en monitorización activa, con el fin de acceder rápidamente a la vista general de estado cuando se produce un evento. O, como muy tarde, si los eventos se van a convertir en estados, una asignación correcta es esencial.
La regla fundamental para los mensajes recibidos a través de syslog es que el nombre del host en el mensaje debe coincidir con el nombre del host en la monitorización.
Esto se consigue utilizando el nombre de dominio completo (FQDN) / nombre de host completo (FQHN), tanto en tu configuración de syslog como en la denominación de hosts en Checkmk.
En Rsyslog puedes lograrlo utilizando la directiva global $PreserveFQDN on.
Checkmk intenta hacer coincidir los nombres de host de los eventos con los de la monitorización activa lo mejor que puede de forma automática. Además del nombre del host, también se prueba el alias del host. Si el nombre corto se transmite a través de syslog, la asignación será correcta.
Una resolución inversa de la dirección IP no tendría mucho sentido aquí, ya que a menudo se utilizan servidores de registro intermedios. Si la conversión de los nombres del host a FQDN/FQHN o la reintroducción de muchos alias lleva demasiado tiempo, puedes utilizar la configuración de la Consola de eventos «Hostname translation for incoming messages» para traducir los nombres del host directamente al recibir mensajes. De este modo, tienes numerosas posibilidades:
El método más flexible es trabajar con expresiones regulares, que permiten realizar búsquedas y sustituciones inteligentes dentro de los nombres del host.
En particular, si los nombres del host son explícitos, pero solo falta la parte del dominio utilizada en Checkmk, una regla sencilla ayuda: (.*) se convierte en \1.mydomain.test.
En los casos en los que todo esto no sea suficiente, aún puedes utilizar Explicit hostname mapping para especificar una tabla de nombres individuales y sus respectivas traducciones.
Importante: La conversión de nombres se realiza antes de checkear las condiciones de la regla y, por lo tanto, mucho antes de una posible reescritura del nombre del host por parte de la acción de regla Rewrite hostname en la reescritura automática de texto.
La asignación es algo más sencilla con SNMP. Aquí se compara la dirección IP del remitente con las direcciones IP almacenadas en la caché de los hosts en la monitorización; es decir, tan pronto como haya comprobaciones activas regulares disponibles, como la comprobación de accesibilidad del puerto Telnet o SSH en un switch, los mensajes de estado de este dispositivo enviados a través de SNMP se asignarán al host correcto.
4. La Consola de eventos en la monitorización
4.1. Vistas de eventos
Los eventos generados por la Consola de eventos se muestran de forma análoga a los hosts y servicios en el entorno de monitorización. Puedes encontrar el punto de acceso a esta función en el menú «Monitor» (Consola de eventos), en «Event Console > Events:» (Vistas de eventos)
Puedes personalizar la vista «Events» tal y como lo harías con cualquier otra. Puedes filtrar los eventos mostrados, ejecutar comandos, etc. Para más detalles, consulta el artículo sobre vistas de tabla. Al crear nuevas vistas de eventos, los eventos y el historial de eventos están disponibles como fuentes de datos.
Al hacer clic en el ID del evento (aquí, por ejemplo, «27»), se mostrarán sus detalles:
Como puedes ver, un evento tiene bastantes campos de datos, cuyo significado explicaremos poco a poco en este artículo. No obstante, conviene mencionar aquí brevemente los campos más importantes:
| Campo | Significado |
|---|---|
State (severity) of event |
Como se menciona en la introducción, cada evento se clasifica como «OK», «WARN», «CRIT» o «UNKNOWN». Los eventos con el estado «OK» son bastante inusuales. Esto se debe a que el EC está diseñado precisamente para filtrar solo los problemas. Sin embargo, hay situaciones en las que un evento «OK» puede tener sentido. |
Text/Message of the event |
El contenido real del evento: un mensaje de texto. |
Hostname |
El nombre del host que envió el mensaje. No tiene por qué ser necesariamente un host que Checkmk esté supervisando activamente. Sin embargo, si existe un host con ese nombre en la monitorización, el EC creará automáticamente un enlace. En este caso, los campos Host alias, Host contacts y Host icons también se rellenarán y el host aparecerá con la misma notación que en la monitorización activa. |
Rule-ID |
El ID de la regla que creó este evento. Al hacer clic en este ID, irás directamente a los detalles de la regla. Por cierto, el ID se conserva incluso si la regla ya no existe. |
Como mencioné al principio, los eventos se muestran directamente en la sección «Overview» de la barra lateral:
Aquí verás tres números:
Events — todos los eventos abiertos y de Reconocimiento (corresponde a la vista de tabla «Event Console > Events»)
Problems — de los cuales solo aquellos con estado «WARN» / «CRIT» / «UNKNOWN»
Unhandled — de estos, a su vez, solo los que aún no han recibido el Reconocimiento (más sobre esto en un momento)
4.2. Comandos y Flujo de trabajo de los eventos
Al igual que con los hosts y los servicios, también se ha realizado el mapeo de un Flujo de trabajo sencillo para los eventos.
Como es habitual, esto se hace mediante comandos, que se encuentran en el menú Commands.
Al mostrar y seleccionar con checkboxes, puedes ejecutar un comando en varios eventos a la vez.
Como característica especial, existe la opción de archivar un evento concreto directamente a través del icono 
.
Para cada uno de los comandos hay un permiso, que puedes usar para controlar para qué rol se permite la ejecución del comando.
Por defecto, todos los comandos están permitidos para los titulares de los roles «admin» y «user».
Están disponibles los siguientes comandos:
Actualizar y realizar un reconocimiento
El comando «Update & Acknowledge» muestra el siguiente área 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 realizar el Reconocimiento del evento. El campo «Change contact» es intencionadamente de texto libre. Aquí también puedes introducir datos como números de teléfono. En particular, este campo no influye en la visibilidad del evento en la GUI; es simplemente un campo de comentarios.
La checkbox «Set event to acknowledged» hará que el evento switch de la fase «open» a «acknowledged», y a partir de ese momento se mostrará como «handled». Esto es análogo al Reconocimiento de problemas de host y de servicio.
Si vuelves a ejecutar el comando con la checkbox desmarcada, se eliminará el Reconocimiento.
Cambiar estado
El comando «Change State» permite cambiar manualmente el estado de un evento, por ejemplo, de «CRIT» a «WARN».
Acción personalizada
Con el comando «Custom Action», se pueden ejecutar acciones libremente definibles sobre los eventos. Inicialmente, solo está disponible la acción «Send monitoring notification». Esto enviará una notificación de Checkmk que se manejará de la misma manera que una procedente de un servicio supervisado activamente. Esto 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 mediante el EC.
Archivar evento
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— también se registran en el archivo, podrás seguir accediendo más adelante a toda la información del evento. Por eso no hablamos de eliminar, sino de archivar.
También puedes archivar cómodamente eventos individuales desde la lista de eventos utilizando «».
4.3. Visibilidad de los eventos
El «problema» de la visibilidad
Para proporcionar visibilidad de los hosts y servicios en la monitorización a los usuarios normales, Checkmk utiliza grupos de contacto. Estos grupos se asignan a los hosts y servicios a través de la GUI de configuración, reglas o configuración de carpetas.
Con la Consola de eventos, la situación es que no existe tal asignación de eventos a grupos de contacto. Esto se debe a que simplemente no se sabe de antemano qué mensajes se recibirán realmente. Ni siquiera se conoce la lista de hosts, ya que se puede acceder a los sockets de syslog y SNMP desde cualquier lugar. Por lo tanto, la Consola de eventos incluye algunas funciones especiales para definir la visibilidad.
Al principio, todo el mundo puede verlo todo
En primer lugar, al configurar los roles de usuario, existe el permiso «Event Console > See all events».
Este está activo por defecto, ¡por lo que los usuarios normales pueden ver todos los eventos!
Esto se ha configurado así a propósito para garantizar que los mensajes de error importantes no se pasen por alto debido a una configuración incorrecta.
El primer paso para una visibilidad más precisa es eliminar este permiso del rol «user».
Asignación a hosts
Para garantizar 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 lograr una coincidencia entre los hosts desde los que recibe eventos y los hosts configurados a través de la GUI de configuración. Lo que parece sencillo resulta complicado en los detalles. A veces falta el nombre del host en el evento y solo se conoce la dirección IP. En otros casos, el nombre del host se escribe de forma diferente a como aparece en la GUI de configuración.
La asignación se realiza de la siguiente manera:
Si no se encuentra ningún nombre del host en el evento, se utiliza su dirección IP como nombre del host.
A continuación, el nombre del host del evento se compara, sin distinguir entre mayúsculas y minúsculas, con todos los nombres de host, direcciones de host y direcciones IP de los hosts en la monitorización.
Si se encuentra un host de esta manera, se utilizan sus grupos de contacto para el evento, y esto se utiliza a su vez para controlar la visibilidad.
Si no se encuentra el host, los grupos de contacto —si están configurados allí— se toman de la regla que creó el evento.
Si tampoco hay grupos almacenados allí, el usuario solo podrá ver el evento si tiene el permiso «Event Console > See events not related to a known host».
Puedes influir en la asignación en un punto: Concretamente, si se definen grupos de contacto 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 realizar ajustes directamente en la regla de la notificación. Esto permite dar prioridad al tipo de evento sobre las responsabilidades habituales de un host.
4.4. Resolución de problemas
¿Qué regla se aplica y con qué frecuencia?
Tanto para los paquetes de reglas …
… como para las reglas individuales …
… en la columna «Hits» encontrarás información sobre la frecuencia con la que el paquete o la regla ya ha tenido una coincidencia con un mensaje. Esto te ayuda a eliminar o reparar reglas ineficaces. Pero también puede ser interesante para reglas que tienen muchas coincidencias. Para un rendimiento óptimo del EC, estas deberían estar al principio de la secuencia de reglas. De esta forma puedes reducir el número de reglas que el EC tiene que comprobar en cada mensaje.
Puedes restablecer los contadores en cualquier momento con el elemento de menú «Event Console > Reset counters».
Depuración de la evaluación de reglas
En «Probar una regla» ya has visto cómo puedes usar la Consola de eventos (Event Simulator) para checkear las evaluaciones de tus reglas. Puedes obtener información similar en tiempo de ejecución para todos los mensajes si, en la configuración de la Consola de eventos, cambias el valor de «Debug rule execution» a «on».
El archivo de registro de la Consola de eventos se encuentra en var/log/mkeventd.log, donde verás el motivo exacto por el que cualquier regla que se haya comprobado no se ha aplicado:
[1481020022.001612] Processing message from ('10.40.21.11', 57123): '<22>Dec 6 11:27:02 myserver123 exim[1468]: Delivery complete, 4 message(s) remain.'
[1481020022.001664] Parsed message:
application: exim
facility: 2
host: myserver123
ipaddress: 10.40.21.11
pid: 1468
priority: 6
text: Delivery complete, 4 message(s) remain.
time: 1481020022.0
[1481020022.001679] Trying rule test/myrule01...
[1481020022.001688] Text: Delivery complete, 4 message(s) remain.
[1481020022.001698] Syslog: 2.6
[1481020022.001705] Host: myserver123
[1481020022.001725] did not match because of wrong application 'exim' (need 'security')
[1481020022.001733] Trying rule test/myrule02n...
[1481020022.001739] Text: Delivery complete, 4 message(s) remain.
[1481020022.001746] Syslog: 2.6
[1481020022.001751] Host: myserver123
[1481020022.001764] did not match because of wrong textNo hace falta decir que debes utilizar este registro intensivo solo cuando sea necesario y con precaución. ¡En un entorno solo ligeramente más complejo se generarán enormes volúmenes de datos!
5. Todo el peso de las reglas
5.1. Las condiciones
La parte más importante de una regla EC es, por supuesto, la condición (Matching Criteria). Solo si un mensaje cumple todas las condiciones almacenadas en la regla, se ejecutan las acciones definidas en la regla y, por lo tanto, se completa la evaluación del mensaje.
Información general sobre comparaciones de texto
Para todas las condiciones que involucran campos de texto, el texto de comparación siempre se trata como una expresión regular. La comparación siempre se realiza sin distinguir entre mayúsculas y 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 de forma local en lugar de de forma centralizada. Por lo tanto, esta excepción es muy útil aquí.
Además, siempre se aplica una concordancia infix, es decir, una check del contenido del texto de búsqueda.
Así que puedes ahorrarte 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 checkará si hay una concordancia 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 infija; por ejemplo, myhost.com también tendrá una coincidencia con notmyhostide.
Grupos de concordancia
Aquí es muy importante y útil el concepto de grupos de concordancia en el campo Text to match. Esto se refiere a las secciones de texto que coinciden con expresiones entre paréntesis en la expresión regular.
Supongamos que quieres realizar la monitorización del siguiente tipo de mensaje en el archivo de registro de una base de datos:
Database instance WP41 has failedEl WP41 es, por supuesto, variable y seguramente no querrás formular una regla separada para cada instancia diferente.
Por lo tanto, utilizas .* en la expresión regular, que representa cualquier cadena:
Database instance .* has failed
Si ahora pones la parte variable entre paréntesis, la Consola de eventos memorizará (capturará) el valor real para cualquier acción futura:
Database instance (.*) has failed
Tras una coincidencia satisfactoria de la regla, el primer grupo de concordancia se establece ahora en el valor «WP41» (o la instancia que haya producido el error).
Puedes ver estos grupos de concordancia en la 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:
Reescribir eventos
Cancelar eventos automáticamente
Contar mensajes
En 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`, solo el grupo de concordancia `123`.
dirección IP
En el campo «Match original source IP address» puedes realizar una coincidencia con la dirección IPv4 del remitente del mensaje.
Especifica una dirección exacta o una red en el formato X.X.X.X/Y, por ejemplo, 192.168.8.0/24 para realizar coincidencias con todas las direcciones de la red 192.168.8. X.
Ten en cuenta que la coincidencia de la dirección IP solo funciona si los sistemas supervisados envían directamente a la Consola de eventos. Si otro servidor syslog intermedio conectado reenvía los mensajes, su dirección aparecerá en su lugar como remitente en el mensaje.
Prioridad y servicio de syslog
Los campos «Match syslog priority» y «Match syslog facility» son información estandarizada, definida originalmente por la información de 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 estaban pensadas 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 años 90 del siglo pasado ya estaba casi en desuso.
Pero es un hecho que todos los mensajes que llegan a través de syslog llevan una de estas facilidades. En algunos casos, también puedes asignarlas libremente al enviar el mensaje, para poder filtrarlos más tarde. Esto es bastante útil.
El uso de la función y la prioridad también tiene un aspecto relacionado con el rendimiento. Si defines una regla que, en cualquier caso, solo se aplica a mensajes que tengan todos la misma función o prioridad, debes definirlas adicionalmente en los filtros de la regla. La Consola de eventos puede entonces saltarse estas reglas de forma muy eficiente cuando se recibe un mensaje con valores diferentes. Cuantas más reglas tengan estos filtros configurados, menos comparaciones de reglas serán necesarias.
Invertir una coincidencia
La checkbox «Negate match: Execute this rule if the upper conditions are not fulfilled.» hace que la regla solo se aplique cuando no se cumple ninguna de las condiciones. En realidad, esto solo es útil en el contexto de dos tipos de reglas (opción «Rule type» en la caja «Outcome & Action» de la regla):
Do not perform any action, drop this message, stop processing.
Skip this rule pack, continue rule execution with next pack
Puedes obtener más información sobre los paquetes de reglas a continuación.
5.2. Efecto de la regla
Tipo de regla: Cancelar o crear un evento
Cuando hay una coincidencia de regla, especifica qué debe suceder con el mensaje. Esto se hace en la caja «Outcome & Action»:
La opción «Rule type» (Acción de la regla) se puede usar para abortar la evaluación en ese punto por completo o solo para el paquete de reglas actual. Especialmente la primera opción debería usarse para eliminar la mayor parte del «ruido» inútil usando unas pocas reglas específicas al principio. Solo con las reglas «normales» se evalúan realmente las otras opciones de esta caja.
Establecimiento del estado
Con «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 ciertos eventos de forma puramente informativa. En tal caso, resulta interesante combinarlo con una caducidad automática de estos eventos.
Además de establecer un estado explícito, hay dos opciones más dinámicas. La configuración «(set by syslog)» se encarga de la clasificación basándose en la prioridad de syslog. Esto solo funciona si el mensaje ya ha sido clasificado como 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:
| Prioridad | ID | Estado | Definición según syslog |
|---|---|---|---|
|
0 |
CRIT |
El sistema no funciona |
|
1 |
CRIT |
se requiere una acción inmediata |
|
2 |
CRIT |
condición crítica |
|
3 |
CRIT |
error |
|
4 |
WARN |
advertencia |
|
5 |
OK |
información normal, pero importante |
|
6 |
OK |
puramente informativo |
|
7 |
OK |
mensaje de depuración |
Además de los mensajes de syslog, los mensajes del Registro de eventos de Windows y los mensajes de archivos de texto que ya se han clasificado con el Plugin logwatch de Checkmk en el sistema de destino proporcionan estados predefinidos. Para las Traps SNMP, lamentablemente esto no está disponible.
Un método completamente diferente consiste en clasificar el mensaje basándose en el propio texto. Esto se puede hacer con la configuración «(set by message text)»:
La coincidencia con los textos configurados aquí solo se produce después de comprobar «Text to match» y de que se hayan comprobado las demás condiciones de la regla, por lo que no tienes que repetir esas comprobaciones.
Si no se encuentra ninguno de los patrones configurados, el evento devuelve el estado UNKNOWN.
Niveles de servicio
La idea detrás del campo «Service Level» es que cada host y cada servicio de una organización tiene un cierto nivel de importancia. Esto se puede asociar a un acuerdo de servicio específico para el host o el servicio. En Checkmk, puedes usar reglas para asignar dichos niveles de servicio a tus hosts y servicios y luego, por ejemplo, hacer que las notificaciones o los dashboards personalizados dependan de ello.
Dado que los eventos no se correlacionan necesariamente con los hosts o los 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 sea necesario en la configuración de la consola de eventos (Global settings > Notifications > Service Levels). Lo decisivo son los números que designan los niveles, ya que estos se ordenan por dichos números y también se comparan según su importancia relativa.
Grupos de contacto
Los grupos de contacto utilizados para la visibilidad también se utilizarán para la notificación de eventos. Aquí puedes usar reglas para asignar grupos de contacto explícitamente a los eventos. Encontrarás más detalles en el capítulo sobre monitorización.
Acciones
Las acciones son muy similares a los alert handlers para hosts y servicios. Aquí puedes hacer que se ejecute un script definido por ti mismo cuando se abra un evento. Encontrarás todos los detalles que describen las acciones más abajo, en una sección aparte.
Eliminación automática (archivo)
La eliminación automática (= archivado), que puedes configurar en Delete event immediately after the actions, garantiza que un evento no sea visible en absoluto en la monitorización. Esto es útil si solo quieres activar algunas acciones automáticamente o si solo quieres archivar ciertos eventos para poder buscarlos más tarde.
5.3. Reescritura automática de textos
Con la función «Rewriting», una regla EC puede reescribir automáticamente los campos de texto de un mensaje y añadir anotaciones. Esto se configura en una caja aparte:
Al reescribir, los grupos de concordancia son especialmente importantes. Estos te permiten incluir partes del mensaje original en el nuevo texto. Puedes acceder a los grupos al reescribir de la siguiente manera:
|
Se sustituirá por el primer grupo de concordancia del mensaje original. |
|
Se sustituirá por el segundo grupo de concordancia del mensaje original (etc.). |
|
Se sustituirá por el mensaje original completo. |
En la captura de pantalla anterior, el texto del nuevo mensaje se codificará como Instance \1 has been shut down.
Por supuesto, esto solo funciona si el «Text to match» de la misma regla de la expresión de búsqueda regular también tiene al menos una expresión entre paréntesis.
Un ejemplo de esto sería, por ejemplo:
Algunas notas adicionales sobre la reescritura:
La reescritura se realiza después de la coincidencia y antes de ejecutar las acciones.
La coincidencia, la reescritura y las acciones siempre se realizan en la misma regla. No es posible reescribir un mensaje y luego procesarlo con una regla posterior.
Las expresiones
\1,\2, etc. se pueden usar en todos los campos de texto, no solo en Rewrite message text.
5.4. Cancelación automática de eventos
Algunas aplicaciones o dispositivos tienen la amabilidad de enviar más tarde un mensaje de OK adecuado tan pronto como se ha resuelto el problema. Puedes configurar el EC de tal manera que, en ese caso, el evento abierto por el error se cierre automáticamente. A esto se le llama cancelar.
La siguiente figura muestra una regla con la que se buscan mensajes que contengan el texto «database instance (.*) has failed».
La expresión «(.*)» representa una cadena arbitraria que se captura en un grupo de concordancia.
La expresión «database instance (.*) recovery in progress», que se encuentra en el campo «Text to cancel event(s)» de la misma regla, cerrará automáticamente los eventos creados con esta regla cuando se reciba un mensaje que tenga una coincidencia:
La cancelación automática funciona siempre que
se reciba un mensaje cuyo texto tenga una coincidencia con Text to cancel event(s),
el valor capturado aquí en el grupo «
(.*)» sea idéntico al del grupo de concordancia del mensaje original,ambos mensajes procedan del mismo host, y
se trate de la misma aplicación (el campo Syslog application to cancel event).
El principio del grupo de concordancia es muy importante aquí.
Al fin y al cabo, no tendría mucho sentido que el mensaje database instance TEST recovery in progress cancelara un evento generado por el mensaje database instance PROD has failed, ¿verdad?
No cometas el error de usar el marcador de posición \1 en Text to cancel events(s).
¡Esto NO funciona!
Estos marcadores de posición solo sirven para reescribir.
En algunos casos ocurre que un texto se utiliza tanto para crear como para cancelar un evento. En tal caso, cancelar tiene prioridad.
Realizar acciones al cancelar
También puedes hacer que se ejecuten acciones automáticamente cuando se cancela un evento. Es importante saber que, cuando se cancela un evento, varios campos de datos del evento se sobrescriben con los valores del mensaje OK antes de que se ejecute ninguna acción. De esta forma, todos los datos del mensaje de «OK» estarán disponibles en el script de acción. Además, durante esta fase, el estado del evento se marca como «OK». De esta forma, un script de acción puede detectar una anulación y puedes usar el mismo script para mensajes de error y de «OK» (por ejemplo, al realizar una conexión a un sistema de tickets).
Los siguientes campos se sobrescriben con los datos del mensaje OK:
El texto del mensaje
La marca de tiempo
La hora de la última ocurrencia
La prioridad del syslog
El resto de campos no cambian, incluido el ID del evento.
Cancelar en combinación con reescritura
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 EC siempre comprueba si el mensaje de cancelación coincide con el nombre del host y la aplicación del evento abierto. Pero si estos se hubieran reescrito, 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 la aplicación para comparar los textos relevantes. Probablemente esto es lo que esperarías.
También puedes aprovechar este comportamiento si el campo de la aplicación en el mensaje de error y el posterior mensaje de «OK» no tienen coincidencia. En este caso, simplemente reescribe el campo de la aplicación con un valor fijo conocido. De hecho, esto hace que este campo se ignore.
Cancelación basada en la prioridad de syslog
Hay (por desgracia) situaciones en las que el texto de los mensajes de error y de «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 de syslog.
Para ello existe la opción «Syslog priority to cancel event».
Aquí introduce el rango debug … notice, por ejemplo.
Normalmente se considera que todas las prioridades de este rango tienen un estado «OK».
Al usar esta opción, debes introducir igualmente un texto adecuado en el campo «Text to cancel event(s)», de lo contrario habrá coincidencia con todos los mensajes «OK» que afecten a la misma aplicación.
5.5. Recuento de mensajes
En la caja «Counting & Timing» encontrarás opciones para contar mensajes similares. La idea es que algunos mensajes solo son relevantes si se producen con demasiada frecuencia o con muy poca frecuencia dentro de los periodos de tiempo especificados.
Mensajes demasiado frecuentes
Puedes activar el check de mensajes que se producen con demasiada frecuencia con la opción «Count messages in interval»:
Aquí primero especificas un periodo de tiempo en «Time period for counting» y el número de mensajes que deben dar lugar a la apertura de un evento en «Count until triggered». En el ejemplo anterior, esto está configurado 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 todos los mensajes que tienen coincidencias a nivel global, sino solo aquellos que se refieren a la misma «causa». Para controlar esto, hay tres checkboxes para las opciones precedidas por Force separate events for different …. Están preconfiguradas de tal manera que los mensajes solo se cuentan juntos si tienen coincidencias en:
host
aplicación
Esto te permite formular reglas como «Si se reciben más de 10 mensajes por hora desde el mismo host, la misma aplicación y el mismo site, entonces…». Debido a la regla, esto puede dar lugar a que se generen varios eventos diferentes.
Si, por ejemplo, desmarcas las tres checkboxes, el recuento se hará solo de forma global y la regla solo podrá generar un evento en total.
Por cierto, puede tener sentido introducir 1 como recuento. De esta forma, puedes controlar eficazmente las «tormentas de eventos». Si, por ejemplo, en un breve intervalo de tiempo se reciben 100 mensajes del mismo tipo, solo se creará un evento. Entonces verás en los detalles del evento
la hora en que se produjo el primer mensaje,
la hora en que se produjo el mensaje más reciente y
el número total de mensajes combinados en este evento.
Cuando se cierre el caso, mediante dos checkboxes puedes definir cuándo debe abrirse un nuevo evento. Normalmente, el Reconocimiento del evento hace que, si se reciben más mensajes, se inicie un nuevo recuento y se active un nuevo evento. Esta función está desactivada con «Continue counting when event is acknowledged».
La opción «Discontinue counting after time has elapsed» garantiza que siempre se abra un evento independiente 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án un máximo de 10 mensajes de una hora a un evento ya abierto. Tan pronto como 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, solo verás un máximo de un evento de este tipo de mensaje al día.
La configuración «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? ¿Siempre horas completas del día? Podría darse el caso de que en el último minuto de una hora se recibieran nueve mensajes, y otros nueve en el primer minuto de la siguiente hora. Eso sumaría 18 mensajes en solo dos minutos de tiempo transcurrido, pero seguiría siendo menos de 10 por hora, por lo que la regla no se aplicaría. Eso no suena muy razonable…
Como no hay una única solución a este problema, Checkmk ofrece tres definiciones diferentes de lo que debería significar exactamente «10 mensajes por hora»:
| Algoritmo | Funcionalidad |
|---|---|
Interval |
El intervalo de recuento comienza con el primer mensaje entrante que presenta una coincidencia. Se genera un evento en la fase «counting». Si transcurre el tiempo especificado antes de alcanzar el recuento, el evento se elimina silenciosamente. Sin embargo, si se alcanza el recuento antes de que expire el tiempo, el evento se abre inmediatamente (y se activan las acciones configuradas). |
Token Bucket |
Este algoritmo no funciona con intervalos de tiempo fijos, sino que implementa un método que se utiliza a menudo en redes para la gestión del tráfico. Supongamos que has configurado 10 mensajes por hora. Eso supone una media de uno cada 6 minutos. La primera vez que se recibe un mensaje que cumple los criterios de coincidencia, se genera un evento en la fase «counting» y el contador se establece en 1. Por cada mensaje posterior, este se incrementa en 1. Y cada 6 minutos, el contador se reduce en 1 de nuevo, independientemente de si ha llegado un mensaje o no. Si el contador vuelve a bajar a 0, el evento se elimina. Así que el disparador se activa cuando la tasa media de mensajes se mantiene permanentemente por encima de 10 por hora. |
Dynamic Token Bucket |
Esta es una variante del algoritmo «Token Bucket», en el que cuanto menor es el contador en un momento dado, más lentamente disminuye. En el ejemplo anterior, si el contador fuera 5, solo disminuiría cada 12 minutos en lugar de cada 6 minutos. El efecto general de esto es que las tasas de notificación que estén justo por encima de la tasa permitida abrirán un evento (y, por lo tanto, se notificarán) mucho más rápido. |
Entonces, ¿qué algoritmo deberías elegir?
Interval es el más sencillo de entender y más fácil de seguir si más adelante quieres realizar un recuento exacto en tu archivo de syslog.
Token Bucket Por otro lado, es más inteligente y «suave». Hay menos anomalías en los extremos de los intervalos.
Dynamic Token Bucket hace que el sistema sea más reactivo y genere notificaciones más rápido.
Los eventos que aún no han alcanzado el número establecido están latentes, pero no son visibles automáticamente para el operador. Se encuentran en la fase «counting». Puedes hacer visibles estos eventos con el filtro «phase» en la vista de tabla de eventos:
Mensajes demasiado infrecuentes o ausentes
Al igual que la llegada de un mensaje concreto puede indicar un problema, la ausencia de un mensaje también puede indicar un problema. Es posible que esperes al menos un mensaje al día de un trabajo concreto. Si este mensaje no llega, es probable que el trabajo no se esté ejecutando y deba solucionarse urgentemente.
Puedes configurar algo como esto en «Counting & Timing > Expect regular messages»:
Al igual que con el recuento, debes especificar un periodo de tiempo en el que esperas que aparezcan los mensajes. Aquí, sin embargo, se utiliza un algoritmo completamente diferente, que tiene mucho más sentido en este caso. El periodo de tiempo siempre se alinea exactamente con posiciones definidas. Por ejemplo, el periodo hour siempre comienza en el minuto y el segundo cero. Tienes las siguientes opciones:
| Intervalo | Alineación |
|---|---|
10 seconds |
En un número de segundos divisible por 10 |
minute |
En el minuto completo |
5 minutes |
A las 0:00, 0:05, 0:10, etc. |
15 minutes |
A las 0:00, 0:15, 0:30, 0:45, etc. |
hour |
Al comienzo de cada hora completa |
day |
Exactamente a las 00:00, pero en una zona horaria configurable. Esto también te permite indicar que esperas un mensaje entre las 12:00 y las 12:00 del día siguiente. Por ejemplo, si te encuentras en la zona horaria UTC +1, especifica UTC -11 hours. |
two days |
Al comienzo de una hora completa. Aquí puedes especificar un desfase horario de 0 a 47, tomando como referencia el 1 de enero de 1970 a las 00:00:00 UTC. |
week |
A las 00:00 de la madrugada del jueves en la zona horaria UTC más la diferencia horaria, que puedes indicar en horas. Jueves porque el 1/1/1970 —el inicio de la «época»— fue un jueves. |
¿Por qué es tan complicado? Esto es para evitar falsas alarmas. ¿Esperas, por ejemplo, un mensaje de una copia de seguridad al día? Seguramente habrá ligeras diferencias en la duración de la copia de seguridad, por lo que los mensajes no se recibirán exactamente con 24 horas de diferencia. Por ejemplo, si esperas que el mensaje llegue alrededor de medianoche, con un margen de una o dos horas, 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, solo recibirás una notificación a las 12:00 del mediodía.
Múltiples ocurrencias del mismo problema
La opción «Merge with open event» está preconfigurada de tal manera que, en caso de que el mismo mensaje aparezca repetidamente, se actualizará el evento existente. Puedes modificar esto para que se abra un nuevo evento cada vez.
5.6. Temporización
En «Counting & Timing» hay dos opciones que afectan a la apertura y/o al cierre automático de eventos.
La opción «Delay event creation» es útil si estás trabajando con la cancelación automática de eventos. Establece, por ejemplo, un retraso de 5 minutos; así, en caso de un mensaje de error, el evento creado permanecerá en estado «delayed» durante 5 minutos, con la esperanza de que el mensaje de «OK» llegue dentro de ese tiempo. Si es así, el evento se cierra automáticamente y sin complicaciones, y no aparece en la monitorización. Sin embargo, si el tiempo expira, el evento se abrirá y se ejecutarán las acciones que hayas definido:
Limit event lifetime hace más o menos lo contrario. Con esto puedes hacer que los eventos se cierren automáticamente tras un tiempo determinado. Esto es útil, por ejemplo, para eventos informativos con estado «OK» que te gustaría mostrar, pero para los que no quieres que la monitorización genere ninguna actividad. Al «switcharlos» automáticamente, te ahorras tener que borrar manualmente esos mensajes:
Al realizar el reconocimiento del mensaje, se detendrá la desconexión por el momento. Este comportamiento se puede controlar con las dos checkboxes.
5.7. Paquetes de reglas
Los paquetes de reglas no solo tienen la ventaja de facilitar la gestión, sino que también pueden simplificar la configuración de múltiples reglas similares y, al mismo tiempo, acelerar la evaluación.
Supongamos que tienes un conjunto de 20 reglas que giran en torno al registro de eventos de Windows Security. Todas estas reglas tienen en común que comprueban en la condición la presencia de un texto determinado en el campo de la aplicación (el nombre de este archivo de registro se utiliza en los mensajes del EC como Application). En tal caso, procede de la siguiente manera:
Crea tu propio paquete de reglas.
Crea las 20 reglas para Security en este paquete o muévelas allí (lista de selección Move to pack… en la parte derecha de la tabla de reglas).
Elimina la condición sobre la aplicación de todas estas reglas.
Crea como primera regla del paquete una regla por la que los mensajes salgan del paquete inmediatamente si la aplicación no es Security.
Esta regla de exclusión tiene la siguiente estructura:
Matching Criteria > Match syslog application (tag) en
Security.Matching Criteria > Invert matching en Negate match: Execute this rule if the upper conditions are not fulfilled.
Outcome & Action > Rule type en Skip this rule pack, continue rule execution with next rule pack
Cualquier mensaje que no provenga del registro de seguridad será «rechazado» por la primera regla de este paquete. Esto no solo simplifica el resto de las reglas del paquete, sino que también acelera el proceso, ya que en la mayoría de los casos no es necesario checkear las demás reglas.
6. Acciones
6.1. Tipos de acciones
La Consola de eventos incluye tres tipos de acciones, que puedes ejecutar manualmente o al abrir o cancelar eventos:
Ejecutar scripts shell escritos por ti mismo.
Envío de correos electrónicos personalizados
Generar notificaciones de Checkmk
6.2. Scripts shell y correos electrónicos
Primero debes definir los correos electrónicos y los scripts en la configuración de la Consola de eventos. Los encontrarás en la entrada «Actions (Emails & Scripts)»:
Ejecución de scripts shell
Con el botón «Add new action» puedes crear una nueva acción.
El siguiente ejemplo muestra cómo crear un script shell sencillo como acción del tipo «Execute Shell Script».
Los detalles de los eventos están disponibles para el script a través de variables del entorno,
por ejemplo, el «$CMK_ID» del evento, el «$CMK_HOST», el texto completo «$CMK_TEXT» o el primer grupo de concordancia como «$CMK_MATCH_GROUP_1».
Para ver una lista completa de las variables del entorno disponibles, consulta la ayuda en línea de «
».
Las versiones anteriores de Checkmk permitían variables del entorno, así como macros como $TEXT$, que se sustituían antes de que se ejecutara el script.
Debido al peligro de que un atacante pudiera inyectar comandos a través de un paquete UDP especialmente diseñado que se ejecutara con los privilegios del proceso de Checkmk, no debes utilizar macros.
Actualmente, las macros siguen siendo compatibles por motivos de compatibilidad, pero nos reservamos el derecho a eliminarlas en una futura versión 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:
cat << EOF > ${OMD_ROOT}/tmp/test.out
Something happened:
Event-ID: $CMK_ID
Host: $CMK_HOST
Application: $CMK_APPLICATION
Message: $CMK_TEXT
EOFLos scripts se ejecutan en el siguiente entorno:
/bin/bashse utiliza como intérprete.El script se ejecuta como usuario del site con el directorio de inicio del site (p. ej.,
/omd/sites/mysite).Mientras se ejecuta el script, ¡se detiene el proceso de otros eventos!
Si tu script contiene 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 local/bin/myaction independiente e inícialo con el comando at, por ejemplo:
echo "$OMD_ROOT/local/bin/myaction '$HOST$' '$TEXT$' | at nowEnvío de correos electrónicos electrónicos
El tipo de acción «Send Email» envía un correo electrónico de texto simple.
En realidad, también podrías hacerlo con un script, por ejemplo, utilizando el comando de línea de comandos «mail».
Pero de esta manera 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».
6.3. Notificaciones a través de Checkmk
Además de ejecutar scripts y enviar correos electrónicos (simples), el EC tiene un tercer tipo de acción: enviar notificaciones a través del sistema de notificaciones de Checkmk. El EC puede generar notificaciones de la misma manera que las notificaciones de host y de servicio de la monitorización activa. Las ventajas en comparación con los simples correos electrónicos descritos anteriormente son obvias:
La notificación se configura para la monitorización activa y basada en eventos de forma conjunta en una ubicación central.
Hay disponibles funciones como notificaciones masivas, correos electrónicos en HTML y otras funciones útiles.
Las reglas de notificación definidas por el usuario, la desactivación de notificaciones y similares funcionan como de costumbre.
El tipo de acción «Send monitoring notification» siempre se procesa automáticamente y no es necesario configurarlo.
Dado que los eventos difieren un poco de los hosts o servicios «normales», hay algunas peculiaridades en sus notificaciones, sobre las que puedes informarte con más detalle en la siguiente sección.
Asignación a hosts existentes
Los eventos pueden provenir 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 de host ampliados, como alias, tags del host, contactos, etc., no están disponibles inicialmente. Esto, en particular, es la razón por la que las condiciones en las reglas de notificación no funcionan necesariamente como cabría esperar.
Por ejemplo, al enviar una notificación, el EC intenta encontrar un host dentro de la monitorización activa que tenga una coincidencia con el evento. Esto se hace utilizando el mismo procedimiento que se usa para la visibilidad de los eventos. Si se encuentra dicho host, se toman los siguientes datos de este host:
La ortografía correcta del nombre del host.
El alias del host
La dirección IP principal configurada en Checkmk.
Las etiquetas del host
La carpeta en la GUI de configuración
La lista de contactos y grupos de contacto
Como resultado, es posible que el nombre del host en la notificación procesada no coincida exactamente con el nombre del host del 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 aplicables 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 sitio que el EC que recibió el mensaje. Por supuesto, esto solo funciona si los mensajes syslog, las Traps SNMP, etc., se envían siempre al site de Checkmk en el que se está realizando la monitorización activa del host.
Si la consulta no funciona o no se encuentra el host, se aceptarán datos sustitutivos:
Nombre del host |
El nombre del host del evento. |
Alias del host |
El nombre del host se utilizará como alias. |
dirección IP |
El campo de la dirección IP contiene la dirección del remitente original del mensaje. |
Tags del host |
El host no recibirá ninguna etiqueta del host. Si tienes grupos de tags de host con etiquetas vacías, el host adoptará esas etiquetas; de lo contrario, no tendrá ninguna etiqueta del grupo. Ten esto en cuenta cuando definas condiciones que hagan referencia a etiquetas de host en las reglas de notificación. |
Configuración de la carpeta de la GUI |
No hay carpeta. Por lo tanto, todas las condiciones que van a una carpeta específica son imposibles de cumplir, incluso en el caso de la Carpeta principal. |
Contacto |
La lista de contactos está vacía. Si hay contactos de reserva, se introducirán. |
Si no se puede asignar el host en la monitorización activa, esto puede, por supuesto, provocar problemas con las notificaciones. Por un lado, debido a las condiciones, que entonces pueden dejar de ser aplicables, 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 manejen específicamente mediante sus propias reglas. Para ello, hay una condición independiente con la que puedes hacer coincidir positivamente solo las notificaciones de la Consola de eventos, o viceversa, excluirlas:
Campos de notificación restantes
Para que las notificaciones de la EC pasen por el sistema de notificaciones de la monitorización activa, la EC 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:
Tipo de notificación |
Las notificaciones de la CE siempre se consideran mensajes de servicio. |
Descripción del servicio |
Este es el contenido del campo «Application» del evento. Si este campo está vacío, se introducirá « |
Número de notificación |
Esto está fijado en |
Fecha/Hora |
Para los eventos que se cuentan, esta es la hora de la última aparición de un mensaje asociado al evento. |
Salida del Plugin |
El contenido de texto del evento. |
Estado del servicio |
Estado del evento, es decir, «OK», «WARN», «CRIT» o «UNKNOWN». |
Estado anterior |
Como los eventos no tienen estado anterior, aquí siempre se introduce «OK» para los eventos normales, y «CRIT» cuando se cancela un evento. Esta regla es la que más se acerca a lo que se necesita para las reglas de notificación que tienen una condición sobre el cambio exacto de estado. |
Definición manual de grupos de contacto
Como se ha descrito anteriormente, puede que no sea posible determinar automáticamente los contactos para un evento. En tales casos, puedes especificar grupos de contactos directamente en la regla EC que se va a utilizar para la notificación. Es importante que no te olvides de marcar la caja «Use in notifications»:
Switch global para notificaciones
Hay un switch central para las notificaciones en el snap-in «Master control». Esto también se aplica a las notificaciones reenviadas por la EC:
Al igual que con la asignación de hosts, consultar el switch mediante el EC requiere acceso Livestatus al core de monitorización local. Una consulta realizada con éxito se puede ver en el archivo de registro de la Consola de eventos:
[1482142567.147669] Notifications are currently disabled. Skipped notification for event 44Tiempos de mantenimiento programados de los hosts
La Consola de eventos es capaz de detectar los hosts que se encuentran actualmente en un periodo de tiempo de mantenimiento programado y no envía notificaciones en tales situaciones. En el archivo de registro se verá así:
[1482144021.310723] Host myserver123 is currently in scheduled downtime. Skipping notification of event 433.Por supuesto, esto también requiere que el host se haya encontrado 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.
Macros adicionales
Cuando escribas tus propios scripts de notificación, especialmente para las notificaciones procedentes de la Consola de eventos, tendrás a tu disposición una serie de variables adicionales que describen el evento original (a las que se accede como de costumbre con el prefijo NOTIFY_):
|
ID del evento. |
|
ID de la regla que creó el evento. |
|
Prioridad de ssyslog como un número entre |
|
Facilidad de syslog —también como un número. El rango de valores va de |
|
Fase del evento. Como solo los eventos abiertos activan acciones, esto debería ser |
|
El campo de comentarios del evento. |
|
El campo «Owner». |
|
El campo de comentario con la información de contacto específica del evento. |
|
El ID del proceso que envió el mensaje (para eventos de syslog). |
|
Los grupos de concordancia de la regla. |
|
Los grupos de contacto opcionales definidos manualmente en la regla. |
6.4. Ejecución de acciones
Arriba, en Comandos, ya has aprendido sobre la ejecución manual de acciones por parte del operador. Más interesante es la ejecución automática de acciones, que puedes configurar con reglas EC en la sección «Outcome & Action»:
Aquí puedes seleccionar una o más acciones que se ejecutarán cada vez que se abra o se cancele un evento según la regla. Para esto último, puedes usar la lista «Do cancelling actions» para especificar si la acción solo debe ejecutarse si el evento cancelado ya ha llegado a la fase «open». Al usar el recuento o el retraso, puede ocurrir que se cancelen eventos que aún están en estado de espera y que aún no son visibles para el usuario.
La ejecución de las acciones se registra en el archivo de registro var/log/mkeventd.log:
[1481120419.712534] Executing command: ACTION;1;cmkadmin;test
[1481120419.718173] Exitcode: 0También se escriben en el archivo.
7. Traps SNMP
7.1. Configuración de la recepción de Traps SNMP
Dado que la Consola de eventos tiene su propio motor SNMP integrado, configurar la recepción de Traps SNMP es muy sencillo.
¡No necesitas snmptrapd desde el sistema operativo!
Si ya lo tienes en ejecución, deténlo.
Tal y como se describe en la sección sobre la configuración de la Consola de eventos, utiliza omd config para habilitar el receptor de traps en este site:
Dado que en cada servidor el puerto UDP para las trampas solo puede ser utilizado por un proceso, esto solo se puede hacer en un site de Checkmk por ordenador.
Al iniciar el site, en la línea que contiene mkeventd puedes comprobar si se ha habilitado la recepción de trampas:
Para que las Traps SNMP funcionen, el emisor y el receptor deben acordar ciertas credenciales. En el caso de SNMPv1 y v2c, se trata de una simple contraseña, conocida como «Community». Con la versión 3 necesitas algunas credenciales más. Configuras estas credenciales en los ajustes de la Consola de eventos, en «Credentials for processing SNMP traps». Puedes usar el botón «Add new element» para configurar varias credenciales diferentes que los dispositivos SNMP pueden utilizar como alternativas:
Ahora, por supuesto, la parte mucho más compleja es especificar la dirección de destino de todos los dispositivos que se van a someter a monitorización y configurar aquí también las credenciales.
7.2. Pruebas
Por desgracia, muy pocos dispositivos ofrecen funciones de prueba útiles.
Al menos puedes comprobar fácilmente la recepción de traps de forma manual usando la propia Consola de eventos enviando un trap de prueba —preferiblemente desde otro sistema Linux.
Esto se puede hacer con el comando snmptrap.
El siguiente ejemplo envía un trap a 192.168.178.11.
El nombre del host del remitente se especifica después de .1.3.6.1 y debe poder resolverse o indicarse como una dirección IP (aquí 192.168.178.30):
Si has configurado el servidor de eventos (Log level) como Verbose logging en los ajustes, podrás ver la recepción y evaluación de las trampas en el archivo de registro del EC:
[1482387549.481439] Trap received from 192.168.178.30:56772. Checking for acceptance now.
[1482387549.485096] Trap accepted from 192.168.178.30 (ContextEngineId "0x80004fb8054b6c617070666973636816893b00", ContextName "")
[1482387549.485136] 1.3.6.1.2.1.1.3.0 = 329887
[1482387549.485146] 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.0.17
[1482387549.485186] 1.3.6.1.6.3.18.1.3.0 = 192.168.178.30
[1482387549.485219] 1.3.6.1.6.3.18.1.4.0 =
[1482387549.485238] 1.3.6.1.6.3.1.1.4.3.0 = 1.3.6.1
[1482387549.485258] 1.3.6.1 = Just kiddingSi las credenciales son incorrectas, solo verás una línea:
[1482387556.477364] Trap received from 192.168.178.30:56772. Checking for acceptance now.Y así es como se ve un evento generado por una trampa de este tipo:
7.3. Convertir números en texto: traducir traps
SNMP es un protocolo binario y es muy parco en las descripciones textuales de los mensajes.
El tipo de trampa se comunica internamente mediante una secuencia de números en los llamados OID.
Estos se muestran como secuencias de números separados por puntos (p. ej., 1.3.6.1.6.3.18.1.3.0).
Con la ayuda de los llamados archivos MIB, la Consola de eventos puede traducir estas secuencias numéricas a texto.
Así, por ejemplo, 1.3.6.1.6.3.18.1.3.0 se convierte en el texto «SNMPv2-MIB::sysUpTime.0».
La traducción de las trampas se puede activar en la configuración de la Consola de eventos:
La trampa de prueba de arriba ahora genera un evento ligeramente diferente:
Si has activado la opción «Add OID descriptions», todo se vuelve mucho más detallado... y más confuso. Sin embargo, ayuda a comprender mejor qué hace realmente una trampa:
7.4. Subir tus propios MIB
Lamentablemente, las ventajas del Open Source aún no han llegado a los autores de archivos MIB, por lo que desde el proyecto Checkmk no podemos ofrecer archivos MIB específicos de cada fabricante.
Solo viene preinstalada una pequeña colección de MIB básicas gratuitas, que, por ejemplo, proporcionan una traducción de «sysUpTime».
Sin embargo, puedes añadir estos archivos a la Consola de eventos en el módulo SNMP MIBs for trap translation a través de la entrada de menú Add one or multiple MIBs para subir tus propios archivos MIB, tal y como se ha hecho a continuación con algunos MIB de los switches inteligentes de Netgear:
Notas sobre los MIB:
En lugar de archivos individuales, también puedes subir archivos ZIP con colecciones de MIB de una sola vez.
Los MIB tienen dependencias entre sí. Checkmk te mostrará los MIB que falten.
Los MIB subidos también se utilizan en la línea de comandos mediante
cmk --snmptranslate.
8. Monitorización de archivos de registro
El agente Checkmk puede analizar archivos de registro mediante el complemento logwatch. Este complemento ofrece, en primer lugar, su propia monitorización de archivos de registro, independiente de la Consola de eventos, incluyendo la posibilidad de realizar Reconocimientos directamente en la monitorización. También existe la posibilidad de transferir los mensajes detectados por el complemento tal cual a la Consola de eventos.
En el agente de Windows, la monitorización de archivos de registro está integrada de forma permanente, en forma de un Plugin para la evaluación de archivos de texto y otro para la evaluación de los registros de eventos de Windows.
El Plugin «mk_logwatch», escrito en Python, está disponible para Linux y Unix.
Se puede acceder a los tres a través de Agent bakery para su instalación o configuración.
Utiliza los siguientes conjuntos de reglas para hacerlo:
Text logfiles (Linux, Solaris, Windows)
Finetune Windows Eventlog monitoring
La configuración precisa del Plugin logwatch no es el tema de este artículo. Sin embargo, lo importante es que sigas realizando el mejor filtrado previo posible de los mensajes en el propio Plugin logwatch y no te limites a enviar el contenido completo de los archivos de texto a la Consola de eventos.
No confundas esto con la reclasificación posterior mediante el conjunto de reglas «Logfile patterns». Esto solo puede cambiar el estado de los mensajes que ya han sido enviados por el agente. Sin embargo, si ya has configurado estas plantillas y simplemente quieres switchar de logwatch a la Consola de eventos, puedes mantener los patrones. Para ello, las reglas de reenvío (Logwatch Event Console Forwarding) incluyen la opción «Reclassify messages before forwarding them to the EC».
En este caso, todos los mensajes pasan por un total de tres secuencias de reglas: en el agente, a través de la reclasificación y en la Consola de eventos.
Ahora modifica Logwatch de manera que los mensajes detectados por los Plugins ya no se supervisen con la comprobación normal de Logwatch, sino que simplemente se reenvíen 1:1 a la Consola de eventos y se procesen allí. Esto se hace con el conjunto de reglas «Logwatch Event Console Forwarding»:
Algunas notas al respecto:
Si tienes un entorno distribuido en el que cada sitio no tiene su propia Consola de eventos, los sitios remotos deben reenviar sus mensajes al site central a través de syslog.
El valor predeterminado para esto es UDP; sin embargo, este no es un protocolo seguro.
Una solución mejor es utilizar syslog a través de TCP, pero tendrás que habilitarlo en el site central (omd config).
Al reenviar, especifica cualquier Syslog facility.
De esta forma, podrás reconocer fácilmente los mensajes reenviados en la EC.
Para ello son muy adecuados local0 a local7.
Con List of expected logfiles puedes realizar la monitorización de la lista de archivos de registro esperados y recibir una alerta si no se encuentran ciertos archivos como se esperaba.
Importante: Guardar la regla por sí sola no sirve de nada. Esta regla solo se activa durante un descubrimiento de servicios. Solo cuando la ejecutes de nuevo, se eliminarán los servicios logwatch anteriores y, en su lugar, se creará un nuevo servicio llamado Log Forwarding para cada host.
Esta comprobación también te mostrará más adelante si surge algún problema al reenviar a la Consola de eventos.
8.1. Nivel de servicio y prioridades de syslog
Dado que los archivos de registro reenviados a menudo carecen de clasificación syslog dependiendo del formato utilizado, puedes definir la reclasificación en el conjunto de reglas de Logwatch Event Console Forwarding bajo Log Forwarding. Además, en los conjuntos de reglas que defines como parte de Rule packs siempre es posible establecer el estado y los niveles de servicio de forma individual.
9. Estado de los eventos en la monitorización activa
Si además quieres ver qué hosts de la monitorización activa tienen actualmente eventos problemáticos abiertos, puedes añadir una check activa para cada host que resuma el estado actual de los eventos del host. Para un host sin eventos abiertos, se verá así:
Si solo hay eventos en estado «OK», la check muestra su número, pero sigue en verde:
Aquí tienes un ejemplo de un caso con eventos abiertos en estado «CRIT»:
Creas esta comprobación activa utilizando una regla del conjunto de reglas «Check event state in Event Console». También puedes especificar si los eventos que ya han recibido Reconocimiento deben seguir contribuyendo al estado:
Con la opción «Application (regular expression)» puedes restringir la comprobación a los eventos que tengan un texto específico en el campo de aplicación. En este caso, puede tener sentido tener más de una comprobación de eventos en un host y separar las comprobaciones por aplicación. Para que se distingan por el nombre, también necesitas la opción «Item (used in service description)», que añade un texto que especifiques al nombre del servicio.
Si tu Consola de eventos no se ejecuta en el mismo site de Checkmk que el que también realiza la monitorización del host, debes configurar Access to Event Console para un acceso remoto a través de TCP:
Para que esto funcione, la Consola de eventos debe permitir el acceso a través de TCP. Puedes configurar esto en los ajustes de la Consola de eventos a la que se va a acceder:
10. El archivo
10.1. Cómo funciona el archivo
La Consola de eventos guarda un registro de todos los cambios que sufre un evento. Puedes encontrar este registro de dos maneras:
En la vista de tabla global «Recent event history», que puedes encontrar en Monitor > Event Console.
En los detalles de un evento a través del elemento de menú «Event Console Event > History of Event».
En la vista de tabla hay un filtro que solo muestra los eventos de las últimas 24 horas. Sin embargo, como siempre, puedes personalizar los filtros.
La siguiente figura muestra el historial del evento 33, que ha sufrido un total de cuatro cambios.
Primero se creó el evento (NEW),
luego se cambió manualmente el estado de «OK» a «WARN» (CHANGESTATE),
después se realizó un reconocimiento con un comentario añadido (UPDATE), y
por último, el evento se archivó/eliminó (DELETE):
El archivo contiene los siguientes tipos de acción, que se muestran en la columna «Action»:
| Tipo de acción | Descripción |
|---|---|
|
El evento se creó recientemente (debido a un mensaje recibido o a una regla que esperaba un mensaje que no llegó). |
|
El operador realizó la edición del evento (cambio en el comentario, la información de contacto o el Reconocimiento). |
|
El evento se archivó. |
|
El evento se canceló automáticamente mediante un mensaje OK. |
|
El operador ha cambiado el estado del evento. |
|
El evento se archivó automáticamente porque no se aplicó ninguna regla y la opción «Force message archiving» estaba activada en la configuración global. |
|
El evento se archivó automáticamente porque, mientras estaba en la fase «counting», se eliminó la regla asociada. |
|
El evento pasó de «counting» a «open» porque se alcanzó el número de mensajes configurado. |
|
El evento se archivó automáticamente porque no se alcanzó el número requerido de mensajes en «counting». |
|
El evento se archivó automáticamente porque, mientras estaba en la fase «counting», su regla asociada se cambió a «no contar». |
|
El evento se abrió porque expiró el retraso configurado en la regla. |
|
El evento se archivó automáticamente porque su tiempo de vida configurado había expirado. |
|
Se envió un correo electrónico. |
|
Se ejecutó una acción automática (script). |
|
El evento se archivó automáticamente justo después de abrirse, porque así estaba configurado en su regla correspondiente. |
10.2. Ubicación del archivo
Como se ha mencionado anteriormente, el archivo de la Consola de eventos no se ha diseñado como un archivo syslog completo.
Para que la implementación y, sobre todo, la administración sean lo más sencillas posible, se ha omitido un backend de base de datos.
En su lugar, el archivo se escribe en archivos de texto simples.
Cada entrada consta de una línea de texto, que contiene columnas separadas por tabulaciones.
Puedes encontrar los archivos en ~/var/mkeventd/history:
Por defecto, cada día se inicia automáticamente un nuevo archivo. En la configuración de la Consola de eventos puedes personalizar la rotación del archivo. La configuración Event history logfile rotation te permite switchar a una rotación semanal.
Los nombres de los archivos se ajustan a la hora Unix desde el momento de la creación del archivo (segundos desde el 1/1/1970 UTC).
Los archivos se conservan durante 365 días, a menos que cambies esto en la configuración «Event history lifetime». Además, los archivos también son registrados por la gestión central de espacio en disco de Checkmk, que se puede configurar en los ajustes globales en «Site management». En este caso, se aplica el límite de tiempo más corto establecido en cada caso. La gestión global tiene la ventaja de que, si el espacio libre en disco se vuelve escaso, elimina automáticamente los datos históricos de Checkmk de forma sistemática, empezando por los más antiguos.
Si tienes problemas de espacio, también puedes simplemente eliminar los archivos del directorio manualmente o cambiarlos de ubicación. No coloques archivos comprimidos ni de ningún otro tipo en este directorio.
10.3. Archivado automático
A pesar de las limitaciones de los archivos de texto, en teoría es posible archivar un gran número de mensajes en la Consola de eventos. Escribir en los archivos de texto del archivo ofrece un gran rendimiento, pero a costa de una búsqueda posterior menos eficiente. Dado que los archivos solo tienen el periodo de solicitud como índice, para cualquier solicitud hay que leer y buscar en todos los archivos relevantes por completo.
Normalmente, la EC solo escribirá en el archivo aquellos mensajes para los que se haya abierto realmente un evento. Puedes hacerlo de dos maneras diferentes para ampliar esto a todos los eventos:
Crea una regla que tenga una coincidencia con todos los eventos (posteriores) y, en la Consola de eventos (Outcome & actions), activa la opción «Delete event immediately after the actions».
Activa el switch «Force message archiving» en la configuración de la Consola de eventos.
Esta última opción garantiza que los mensajes que no estén sujetos a ninguna regla se escriban, no obstante, en el archivo (tipo de acción «ARCHIVED»).
11. Rendimiento y optimización
11.1. Procesamiento de mensajes
Incluso en una época en la que los servidores tienen 64 núcleos y 2 TB de memoria principal, el rendimiento del software sigue siendo importante. Especialmente en el procesamiento de eventos, los mensajes entrantes pueden perderse en situaciones extremas.
La razón es que ninguno de los protocolos utilizados (syslog, Traps SNMP, etc.) ofrece control de flujo. Si miles de hosts envían mensajes simultáneamente cada segundo, el receptor no tiene forma de ralentizarlos.
Por lo tanto, en entornos algo más grandes, es importante que estés atento a los tiempos de procesamiento de los mensajes. Esto depende de cuántas reglas hayas definido y de cómo estén estructuradas.
Medición del rendimiento
Para medir tu rendimiento, hay un snap-in independiente para la barra lateral llamado «Event Console Performance».
Puedes añadirlo como de costumbre con «
»:
Los valores que se muestran aquí son promedios de aproximadamente el último minuto. Una tormenta de eventos que dura solo unos segundos no se puede leer aquí directamente, pero las cifras se han suavizado un poco y, por lo tanto, son más fáciles de leer.
Para probar el rendimiento máximo, puedes generar artificialmente una tormenta de mensajes sin clasificar (¡por favor, solo 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:
| Valor | Significado |
|---|---|
Received messages |
Número de mensajes recibidos actualmente por segundo. |
Rule tries |
Número de reglas que se prueban. Esto proporciona información valiosa sobre la eficiencia de la secuencia de reglas, especialmente junto con el siguiente parámetro. |
Rule hits |
Número de reglas por segundo que se están aplicando actualmente. Estas también pueden ser reglas que descartan mensajes o que simplemente cuentan. Por lo tanto, no todas las reglas aplicadas dan lugar a un evento. |
Rule hit ratio |
La relación entre Rule tries y Rule hits. En otras palabras: cuántas reglas tiene que probar la EC antes de que una (por fin) surta efecto. En el ejemplo de la captura de pantalla, la tasa es alarmantemente baja. |
Created events |
Número de nuevos eventos creados por segundo. Dado que la Consola de eventos solo debería mostrar problemas relevantes (comparables a los problemas de host y servicio de la monitorización), ¡el número de |
Processing time per message |
Aquí puedes ver cuánto tiempo tardó en procesarse un mensaje. Precaución: en general, esto no es lo contrario de Received messages. Porque siguen faltando los tiempos en los que la Consola de eventos no tenía nada que hacer, simplemente porque no llegaban mensajes. Aquí lo que realmente mides es el tiempo real transcurrido entre la llegada de un mensaje y la finalización del procesamiento. Puedes ver aproximadamente cuántos mensajes puede manejar la Consola de eventos en un tiempo determinado. Ten en cuenta también que esto no es tiempo de CPU, sino tiempo real. En un sistema con suficientes CPU libres, estos tiempos son más o menos iguales. Pero en cuanto el sistema está tan saturado que no todos los procesos consiguen siempre una CPU, el tiempo real puede aumentar considerablemente. |
Consejos de ajuste
Puedes ver cuántos mensajes puede procesar la Consola de eventos por segundo en la pestaña «Processing time per message». Este tiempo suele estar relacionado con el número de reglas que hay que probar antes de que se procese un mensaje. Aquí tienes varias opciones de optimización:
Además, hay una optimización en el EC basada en la prioridad y la facilidad de syslog. Para cada combinación de prioridad y facilidad, se crea internamente una secuencia de reglas separada en la que solo se incluyen aquellas reglas relevantes para los mensajes de esa combinación.
Cada regla que contenga una condición sobre la prioridad, la facilidad o, preferiblemente, ambas, no se incluirá en todas estas secuencias de reglas, sino, de forma óptima, solo en una. Esto significa que no es necesario checkear la regla para mensajes con una clasificación de syslog diferente.
Tras un reinicio, en ~/var/log/mkeventd.log verás una vista general de las secuencias de reglas optimizadas:
[8488808306.233330] kern : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233343] user : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233355] mail : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233367] daemon : emerg(120) alert(89) crit(89) err(89) warning(89) notice(89) info(89) debug(89)
[8488808306.233378] auth : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233389] syslog : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233408] lpr : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233482] news : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233424] uucp : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233435] cron : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233446] authpriv : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233457] ftp : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233469] (unused 12) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233480] (unused 13) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233498] (unused 13) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233502] (unused 14) : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233589] local0 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233538] local1 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233542] local2 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233552] local3 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233563] local4 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233574] local5 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233585] local6 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233595] local7 : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)
[8488808306.233654] snmptrap : emerg(112) alert(67) crit(67) err(67) warning(67) notice(67) info(67) debug(67)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; solo para la combinación daemon / emerg hay que comprobar 120 reglas.
Cada regla que incluye una condición sobre la prioridad o la instalación reduce aún más el número de 67.
¡Por supuesto, solo puedes establecer estas condiciones si estás seguro de que los mensajes relevantes las cumplen!
11.2. El recuento de eventos actuales
El número de eventos presentes actualmente también puede afectar al rendimiento de la EC, es decir, cuando se descontrola gravemente. Como se ha mencionado anteriormente, la EC no debe considerarse un sustituto de un archivo syslog, sino solo para mostrar «problemas actuales». La Consola de eventos puede sin duda manejar varios miles de problemas, pero ese no es su verdadero propósito.
En cuanto el número de eventos actuales supera los 5 000, el rendimiento empieza a deteriorarse notablemente. Por un lado, esto se nota en la GUI, que reacciona más lentamente a las solicitudes. Por otro lado, el procesamiento también se ralentiza, ya que en algunas situaciones hay que comparar los mensajes con todos los eventos actuales. Los requisitos de memoria también pueden suponer un problema.
Por motivos de rendimiento, la Consola de eventos mantiene siempre todos los eventos actuales en la RAM.
Estos se escriben en el archivo ~/var/mkeventd/status una vez por minuto (ajustable) y al finalizar correctamente el procesamiento.
Si este archivo se vuelve muy grande (por ejemplo, más de 50 megabytes), este proceso también se vuelve cada vez más lento.
Puedes checkar rápidamente el tamaño actual con ll. (alias de ls -alF):
Si tienes demasiados eventos actuales debido a una regla poco acertada (por ejemplo, una que tenga una coincidencia con todo), no es razonablemente posible eliminarlos manualmente a través de la GUI. En este caso, basta con eliminar el archivo de estado:
Atención: Por supuesto, se perderán todos los eventos actuales, así como el contador almacenado y otros estados. En particular, los nuevos eventos volverán a empezar con el ID 1.
Protección automática contra desbordamiento
La Consola de eventos cuenta con una protección automática contra el «desbordamiento». Esto limita el número de eventos actuales por host, por regla y a nivel global. No solo 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, miles de eventos críticos inundan el sistema 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 almacenar demasiados eventos en su memoria principal. Por otro lado, la Vista general para el operador queda (en cierta medida) protegida y los eventos que no forman parte de la avalancha siguen siendo visibles.
Una vez alcanzado el límite, se producirá una de las siguientes acciones:
Se detiene la creación de nuevos eventos (para este host, regla o a nivel global).
Lo mismo, pero además se crea un «evento de desbordamiento».
Lo mismo, pero además se notifica a los contactos correspondientes.
Como alternativa a las tres variantes anteriores, también puedes hacer que se elimine el evento más antiguo para dejar espacio al nuevo.
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 predeterminada:
Si has habilitado un valor con «…create overflow event», cuando se alcance el límite, se creará un único evento artificial que informará al operador de la situación de error:
Si además has habilitado un valor con «…notify contacts», se notificará a los contactos correspondientes a través de una notificación de Checkmk. Esa notificación seguirá las reglas de notificación de Checkmk. Estas reglas no tienen por qué seguir la selección de contactos de la Consola de eventos, sino que pueden modificarla. La siguiente tabla muestra qué contactos se seleccionan si has configurado «Notify all contacts of the notified host or service» (que es el valor predeterminado):
| Límite | Selección de contactos |
|---|---|
por host |
Los contactos del host, que se determinan de la misma manera que para la notificación de eventos a través de Checkmk. |
por regla |
Deja el campo del nombre del host en blanco. Si se han definido grupos de contactos en la regla, se seleccionarán; de lo contrario, se aplicarán los contactos de reserva. |
Global |
Los contactos de reserva. |
11.3. Archivo demasiado grande
Como se muestra arriba, la Consola de eventos tiene un archivo con todos los eventos y sus pasos de procesamiento. Esto se almacena en archivos de texto para facilitar la implementación y la administración.
Los archivos de texto son difíciles de superar en términos de rendimiento a la hora de escribir datos; por ejemplo, el uso de bases de datos solo es posible con un enorme esfuerzo de optimización. Esto se debe, entre otros factores, a la optimización de este tipo de acceso por parte de Linux y a la jerarquía de memoria completa de discos y SAN. Sin embargo, esto va en detrimento de los accesos de lectura. Dado que los archivos de texto no tienen un índice, es necesaria una lectura completa al buscar en los archivos.
En su forma más simple, la Consola de eventos utiliza los nombres de los archivos de registro como índice para la hora de los eventos. Cuanto más limites el periodo de tiempo, más rápida será la búsqueda.
No obstante, es muy importante que tu archivo no se haga demasiado grande. Si utilizas la Consola de eventos solo para procesar mensajes de error reales, esto no debería ocurrir. Si intentas utilizar la Consola de eventos como sustituto de un archivo syslog real, esto puede dar lugar a archivos muy grandes.
Si te encuentras con una situación en la que tu archivo se ha vuelto demasiado grande, puedes simplemente eliminar los archivos más antiguos en ~/var/mkeventd/history/.
Además, en Event history lifetime puedes, por lo general, limitar la vida útil de los datos para que la eliminación sea la opción predeterminada en el futuro.
Por defecto, se almacenan 365 días.
Quizás puedas arreglártelas con mucho menos.
11.4. Medición del rendimiento a lo largo del tiempo
Checkmk inicia automáticamente un servicio para cada sitio de Consola de eventos, que registra sus datos de rendimiento en curvas y también te avisa si se producen desbordamientos.
Siempre que hayas instalado un agente de Linux en el servidor de monitorización, la comprobación se detectará automáticamente y se configurará como de costumbre:
La comprobación incluye muchos tipos de mediciones interesantes, por ejemplo, el número de mensajes entrantes por cada periodo de tiempo y cuántos de ellos se descartaron:
La eficiencia de tu secuencia de reglas se representa mediante una comparación entre las reglas probadas y las que funcionaron:
Este gráfico muestra el tiempo medio que se tarda en procesar un mensaje:
También hay bastantes gráficos gráficos adicionales.
12. Monitorización distribuida
Para saber cómo usar la Consola de eventos en una instalación con varios sitios de Checkmk, consulta el artículo sobre monitorización distribuida.
13. La interfaz de estado
La Consola de eventos, a través del socket Unix ~/tmp/run/mkeventd/status, ofrece tanto acceso al estado interno como la posibilidad de ejecutar comandos.
El protocolo que se usa aquí es un subconjunto muy restringido de Livestatus.
El core de monitorización accede a esta interfaz y pasa los datos a la GUI para ofrecer también una monitorización distribuida para la Consola de eventos.
Las siguientes restricciones se aplican al Livestatus simplificado de la Consola de eventos:
Los únicos encabezados permitidos son
Filter:yOutputFormat:.Por lo tanto, no es posible el KeepAlive, solo se puede realizar una solicitud por conexión.
Están disponibles las siguientes tablas:
|
Muestra una lista de todos los eventos actuales. |
|
Acceso al archivo. Una consulta en esta tabla accederá a los archivos de texto del archivo. Asegúrate de usar un filtro sobre la hora de la entrada para evitar el acceso completo a todos los archivos. |
|
Valores de estado y rendimiento del EC. Esta tabla siempre tiene exactamente una fila. |
Los comandos se pueden escribir en el socket usando unixcat con una sintaxis muy sencilla:
Están disponibles los siguientes comandos:
|
Archiva un evento. Argumentos: ID del evento y abreviatura del usuario. |
|
Recarga la configuración. |
|
Cierra la Consola de eventos. |
|
Vuelve a abrir el archivo de registro. Este comando es necesario para la rotación del archivo de registro. |
|
Elimina todos los eventos actuales y archivados. |
|
Inicia una actualización inmediata del archivo « |
|
Restablece los contadores de aciertos de reglas (corresponde al elemento de menú «Event Console > Reset counters» en la GUI de configuración). |
|
Ejecuta una actualización a partir de un evento. Los argumentos son, en orden: ID del evento, abreviatura del usuario, Reconocimiento (0/1), comentario e información de contacto. |
|
Cambia los estados «OK», «WARN», «CRIT» y «UNKNOWN» de un evento. Los argumentos son el ID del evento, la abreviatura del usuario y el dígito de estado ( |
|
Ejecuta una acción definida por el usuario en un evento. Los argumentos son el ID del evento, la abreviatura del usuario y el ID de la acción. El ID especial |
14. Archivos y directorios
| Ruta del archivo | Descripción |
|---|---|
|
Directorio de trabajo del daemon de eventos. |
|
Estado completo actual de la Consola de eventos. Esto incluye principalmente todos los eventos abiertos actualmente (y aquellos en fases de transición como «counting», etc.). En caso de una configuración incorrecta que provoque una gran cantidad de eventos abiertos, este archivo puede volverse enorme y reducir drásticamente el rendimiento de la Consola de eventos. En tal situación, puedes detener el servicio « |
|
Ubicación del archivo. |
|
Archivo de registro de la Consola de eventos. |
|
La configuración global de la Consola de eventos en sintaxis Python. |
|
Todos tus paquetes de reglas y reglas configurados en sintaxis Python. |
|
Una tubería con nombre donde puedes escribir mensajes directamente con |
|
Un socket de Unix que hace lo mismo que la tubería, pero permite que varias aplicaciones escriban en él simultáneamente. Para escribir en él, necesitas el comando ` |
|
El ID de proceso actual del daemon de eventos mientras está en ejecución. |
|
Un socket de Unix que permite consultar el estado actual y enviar comandos. Las solicitudes de la GUI van primero al core de monitorización, que luego accede a este socket. |
|
Archivos MIB subidos por ti para la traducción de Traps SNMP. |