Monitoring log files

El paquete de instalación del agente de Windows de Checkmk Community no contiene un entorno Python. Sin embargo, ya hay un archivo cabinet correspondiente disponible en tu servidor Checkmk. Puedes encontrar este archivo, llamado python-3.cab, en el directorio ~/share/check_mk/agents/windows o en Checkmk a través de Setup > Agents > Windows > Windows Agent. Copia este archivo a tu host de Windows en el directorio C:\Program Files (x86)\checkmk\service\install. Ya hay un archivo con este nombre y un tamaño de 0 bytes. Debes sobrescribir este archivo con la versión del servidor Checkmk. A continuación, reinicia el servicio del agente Checkmk. En PowerShell con derechos de administrador, puedes hacerlo con el siguiente comando:

Una vez reiniciado el servicio de Windows, el entorno virtual de Python se habrá instalado automáticamente.

Como alternativa, también puedes descargar e instalar un paquete actual de Python desde python.org. Asegúrate de activar las siguientes opciones durante la instalación:

Si quieres empezar a probar inmediatamente después de instalar Python, es imprescindible reiniciar el servicio checkmkservice, ya sea a través del Administrador de tareas de Windows o con los comandos especificados anteriormente; de lo contrario, el servicio no reconocerá las nuevas variables del entorno.

En las ediciones comerciales, primero abre la regla del plugin de agente «Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows)». La configuración predeterminada «Deploy the Logwatch plugin and its configuration» normalmente debe dejarse tal cual. Sin embargo, si quieres o necesitas transferir el archivo de configuración «logwatch.cfg» al host de otra manera, la opción «Deploy the Logwatch plugin without configuration» sigue estando disponible aquí.

Continúa con la opción Retention period. La configuración predeterminada aquí es de un minuto, lo que también se corresponde con el intervalo de comprobación preestablecido en Checkmk. Este valor siempre debe ser, como mínimo, igual al intervalo de comprobación. Esta opción es la principal responsable de garantizar que no se pierdan mensajes de registro debido a una detección de servicio o a la ejecución manual de cmk -d myhost. Puedes encontrar más detalles en la ayuda en línea de la opción y en el Werk #14451 con el que se introdujo esta opción.

Ahora llega la sección de la regla donde realmente empieza la acción: Configure a logfile section. Empezaremos directamente con el mayor escollo de los últimos años. En el campo Patterns for logfiles to monitor, tendrás que especificar los archivos de registro que quieres someter a monitorización. Puedes hacerlo de forma individual y explícita o con los llamados patrones glob (glob, para abreviar). Aquí estamos usando el módulo de Python glob, del que hay una documentación detallada en docs.python.org. Sin embargo, nos gustaría ofrecerte algunos ejemplos útiles aquí mismo.

Por ejemplo, si introduces /var/log/my.log aquí, logwatch realizará la monitorización solo de este único archivo de registro. Si, en cambio, introduces /var/log/*log aquí, logwatch realizará la monitorización de todos los archivos que terminen con la cadena de caracteres log y que se encuentren directamente en el directorio /var/log. Si quieres realizar la monitorización de los archivos de registro de todos los subdirectorios directos de /var/, puedes hacerlo con el siguiente patrón, por ejemplo: /var/*/*log. No ofrecemos explícitamente el patrón ** para buscar de forma recursiva en una estructura de directorios, ya que acabaríamos con una lista de resultados demasiado grande en muy poco tiempo y nos alejaríamos del objetivo real de logwatch.

La siguiente tabla te ofrece algunos ejemplos útiles más de cómo puedes usar patrones glob para la monitorización realmente de los archivos que requieren monitorización sin tener que especificarlos todos individualmente:

Así que, en cuanto a qué archivos tienen una coincidencia en el primer paso, no usamos expresiones regulares y esto puede ser suficiente para que llegues a todos los archivos que quieras.

Sin embargo, si ahora necesitas filtrar aún más, puedes usar la opción Regular expression for logfile filtering para aplicar expresiones regulares a los resultados del paso 1 en un segundo paso.

Si ha realizado la colección de todos los archivos de /var/log/ y sus subdirectorios directos en el primer paso con /var/log/ y /var/log/*/*, podría usar la expresión regular error.log$|err$ para reducir la lista de resultados a todos los archivos que terminen en err.log o err. Precaución: El «punto» (.) vuelve a ser ahora un carácter arbitrario. Esto podría, por ejemplo, dejar los archivos /var/log/apache2/error.log, /var/log/mail.err y /var/log/cups/error_log.

Como puedes ver, ya te hemos proporcionado dos herramientas buenas y potentes para seleccionar los archivos que se van a realizar tareas de monitorización, de modo que logwatch también pueda comprobar los demás parámetros y contenidos muy rápidamente en el siguiente paso utilizando una lista de archivos manejable. Puedes profundizar tus conocimientos sobre esto último en el artículo «Expresiones regulares en Checkmk».

Con la opción Restrict the length of the lines puedes indicar a logwatch que trunque las líneas excesivamente largas tras el número de caracteres especificado.

La siguiente opción, «Watch the total size of the log file», es útil para detectar una rotación de registros defectuosa. Si aquí estableces 100 MiB, recibirás una advertencia cada vez que un archivo de registro concreto vuelva a superar el tamaño especificado.

El número máximo de líneas que logwatch comprueba por ejecución y archivo se puede restringir con «Restrict number of processed messages per cycle», y con «Restrict runtime of logfile parsing» puedes asegurarte de que logwatch no dedique demasiado tiempo a un solo archivo que pueda haberse visto inundado con miles y miles de nuevas entradas desde la última check.

Si activas una de las dos últimas opciones, también debes especificar qué debe suceder si se supera el límite especificado. Con nuestra configuración predeterminada, el servicio asociado pasa a estado crítico y recibes un mensaje indicando que se han omitido líneas o que se ha superado el tiempo de ejecución máximo.

Handling of context messages es una opción con la que el volumen de datos transferidos puede aumentar mucho muy rápidamente. Así que piensa bien si solo te importa el mensaje de log que crees que debería generar un CRIT o un WARN, o si todas las líneas que se han añadido desde la última ejecución de logwatch deben transferirse al servidor Checkmk. Para archivos de registro pequeños que solo crecen unas pocas líneas por minuto, la configuración Do transfer context no supone ningún problema. Sin embargo, si se realiza la monitorización de 50 archivos de registro en un host, que de repente contienen 100 000 líneas nuevas con una longitud de 500 caracteres, ya estamos en el rango de los gigabytes. En tal caso, puede bastar con ver que se ha añadido un gran número de mensajes nuevos desde la última comprobación para iniciar una comprobación directamente en el host en cuestión.

Si necesitas el contexto —es decir, las líneas anteriores y posteriores al mensaje de registro que te interesa—, puedes limitarlo a un número determinado de líneas antes y después con la opción Limit the amount of context data sent to the monitoring server.

Con Limit the amount of data sent to the monitoring server puedes limitar el tamaño de los datos transferidos en general.

Process new logfiles from the beginning está desactivada por defecto. Esto a veces causa sorpresa, porque logwatch no «reconoce» los problemas que hay en los archivos de registro y los transmite al servidor Checkmk. En nuestra opinión, nada es más antiguo que el periódico de ayer, y lo mismo ocurre con los mensajes de registro que ya estaban en un archivo de registro antes de la primera ejecución de logwatch. Durante esta primera ejecución, logwatch no hace más que anotar cuántas líneas contiene ya el registro correspondiente. Solo durante la segunda ejecución se checkea el contenido de los archivos, es decir, las líneas recién añadidas.

Logwatch depende de poder leer realmente los archivos de registro. En segundo plano, logwatch hace todo lo posible por reconocer la codificación de cada archivo de registro. Sin embargo, las codificaciones de caracteres demasiado exóticas pueden causar problemas. Si puedes especificar la codificación de caracteres de los archivos de registro objeto de monitorización, UTF-8 es una muy buena opción. Si esto no es posible y logwatch no consigue averiguar la codificación, puedes especificarla explícitamente con Codec that should be used to decode the matching files.

Con Duplicated messages management, si activas esta opción, puedes ahorrar un poco de ancho de banda, y la salida posterior en Checkmk también será más legible. Si activas Filter out consecutive duplicated messages in the agent output, logwatch cuenta cuántas veces se repitió una línea y lo escribe en la salida en lugar de repetir las líneas.

Por último, las líneas de los archivos de registro que te interesan se describen ahora mediante una expresión regular y se les asigna un estado. Si quieres que cada línea que contenga la palabra «panic» dé lugar a un «CRIT» en Checkmk, basta con introducir «panic» en el campo «Pattern(Regex)» después de hacer clic en «Add message pattern» debajo de «Regular expressions for message classification». Las funciones de las demás opciones ofrecidas ya se describen con gran detalle en la ayuda en línea en este punto y no se repiten aquí.

Una cosa a tener en cuenta: el estado «OK» puede parecer confuso a primera vista. Se utiliza para transferir primero las líneas de un archivo de registro al servidor Checkmk con el fin de llevar a cabo después la clasificación final. Esto nos lleva a un punto importante que muestra lo flexible que puede ser logwatch cuando se usa correctamente.

Todas las opciones explicadas en esta sección se convierten en entradas en el archivo de configuración ya mencionado, que se almacena en el host correspondiente. Si ahora quieres realizar cambios en la clasificación de ciertos mensajes, es posible que primero tengas que editar la regla, luego compilar el agente e instalarlo.

Como alternativa, puedes transferir primero todos los mensajes de interés al servidor Checkmk (por ejemplo, con el estado «OK») y, a continuación, (re)clasificarlos en el servidor Checkmk con la regla «Logfile patterns». De esta forma, te ahorras la molestia de compilar y desplegar el nuevo agente y, tras personalizar la regla mencionada anteriormente como corresponda, solo tendrás que activar rápidamente los cambios —una sola vez—. Puedes ver exactamente cómo hacerlo más abajo, en el capítulo «Reclasificación con patrones de archivos de registro».

En la comunidad Checkmk , configuras el plugin de agente como de costumbre a través de un archivo de texto. Por regla general, logwatch busca un archivo llamado logwatch.cfg en los directorios /etc/check_mk (Linux) o c:\ProgramData\checkmk\agent\config\ (Windows). Una configuración (casi) mínima podría tener este aspecto:

En primer lugar, introduce siempre aquí un patrón glob, seguido de todas las opciones que se van a aplicar. A continuación, con una sangría de un espacio, va una letra que representa el estado o la función deseados y, por último, una expresión regular que se compara con cada línea del archivo de registro. Con la configuración anterior, todas las líneas nuevas que se hayan añadido al archivo /var/log/my.log desde la última ejecución de logwatch se checkarían en busca de los dos patrones: a critical message y something that should only trigger a warning.

En el archivo ~/share/check_mk/agents/cfg_examples/logwatch.cfg encontrarás un ejemplo de configuración muy completo aplicable a un usuario del site.

Dado que todas las opciones que puedes especificar en dicho archivo de configuración ya se han explicado en la sección «Configuración a través de Agent bakery», aquí solo se incluye una lista y una breve descripción. Consulta la sección anterior para obtener una explicación detallada.