Monitoring log files

El paquete de instalación para el agente Windows de Checkmk Raw no contiene un entorno Python. Sin embargo, en tu servidor Checkmk ya existe un archivo de gabinete correspondiente. 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 en tu host Windows en el directorio C:\Program Files (x86)\checkmk\service\install. Ya existe 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 Windows PowerShell con derechos de administrador, puedes hacerlo con el siguiente comando:

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

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 hacer pruebas inmediatamente después de instalar Python, es esencial reiniciar el checkmkservice mediante el Administrador de Tareas de Windows o con los comandos especificados anteriormente, de lo contrario el servicio no conocerá las nuevas variables del entorno.

En las ediciones comerciales, llama primero la regla para el plugin de agente Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows). La opción por defecto Deploy the Logwatch plugin and its configuration debe dejarse normalmente como está. Sin embargo, si quieres o necesitas transferir el archivo de configuración logwatch.cfg al host de otra forma, la opción Deploy the Logwatch plugin without configuration sigue disponible aquí.

Continúa con la opción Retention period. El valor por defecto aquí es un minuto, que también se corresponde con el intervalo de comprobación preestablecido en Checkmk. Este valor debería ser siempre al menos igual al intervalo de comprobación. Esta opción se encarga principalmente de garantizar que no se pierdan mensajes de registro debido a la detección de un 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 viene la sección de la regla en la que las cosas realmente se ponen en marcha: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 monitorizar. Puedes hacerlo de forma individual y explícita o con los llamados patrones glob (glob para abreviar). Aquí estamos utilizando el módulo de Python glob, para el que existe una documentación detallada en docs.python.org. Sin embargo, nos gustaría proporcionarte aquí mismo algunos ejemplos útiles.

Por ejemplo, si introduces aquí /var/log/my.log, logwatch sólo monitorizará este único archivo de registro. Si, en cambio, introduces aquí /var/log/*log, logwatch monitorizará todos los archivos que terminen con la cadena de caracteres log y que se encuentren directamente en el directorio /var/log. Si quieres monitorizar los archivos de registro de todos los subdirectorios directos de /var/, puedes hacerlo con el siguiente glob, por ejemplo: /var/*/*log. Aquí no ofrecemos explícitamente el glob ** para buscar recursivamente en una estructura de directorios, porque acabaríamos con una lista de resultados demasiado grande demasiado rápidamente y dejaríamos atrás el verdadero propósito de logwatch.

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

Por tanto, en lo que respecta a los archivos "coincidentes" en el primer paso, no utilizamos expresiones regulares y esto puede ser suficiente para que llegues a todos los archivos que desees.

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

Si has recopilado todos los archivos /var/log/ y sus subdirectorios directos en el primer paso con /var/log/ y /var/log/*/*, podrías utilizar la expresión regular error.log$|err$ para reducir la lista de resultados a todos los archivos que terminen con err.log o err. Atenció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 buenas y potentes herramientas para seleccionar los archivos a monitorizar, de modo que Logwatch también puede comprobar los demás parámetros y contenidos muy rápidamente en el siguiente paso, utilizando una lista de archivos manejable. Puedes profundizar en el conocimiento de esta última en el artículo Expresiones regulares en Checkmk.

Con la opción Restrict the length of the lines puedes ordenar a logwatch que trunque las líneas excesivamente largas después del número de caracteres especificado.

La siguiente opción Watch the total size of the log file es útil para reconocer una rotación de registro defectuosa. Si estableces aquí 100 MiB, recibirás un aviso 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 puede restringirse con Restrict number of processed messages per cycle y con Restrict runtime of logfile parsing puedes asegurarte de que logwatch no pase demasiado tiempo en un único archivo que puede haberse inundado con miles y miles de entradas nuevas desde la última comprobación.

Si activas una de estas dos últimas opciones, también debes especificar qué debe ocurrir si se supera el límite especificado. Con nuestra configuración por defecto, el servicio asociado se vuelve crítico y recibes un mensaje de que se han saltado líneas o de que se ha superado el tiempo máximo de ejecución.

Handling of context messages es una opción con la que el volumen de datos transferidos puede llegar a ser muy grande muy rápidamente. Por tanto, piensa detenidamente si sólo es importante para ti el mensaje de registro que crees que debe generar un CRIT o un WARN, o si deben transferirse al servidor Checkmk todas las líneas que se hayan añadido desde la última ejecución de logwatch. Para archivos de registro pequeños que sólo crecen unas pocas líneas cada minuto, la opción Do transfer context no plantea problemas. Sin embargo, si se monitorizan 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 ser suficiente ver que se ha añadido un gran número de mensajes nuevos desde la última monitorización para iniciar un check directamente en el host en cuestión.

Si necesitas el contexto -es decir, las líneas anteriores y posteriores al mensaje de registro que es importante para ti- puedes limitarlo a un determinado número de líneas anteriores y posteriores 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á desactivado por defecto. Esto a veces causa asombro, 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 viejo que el periódico de ayer, y tampoco lo son 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 respectivo. Sólo durante la segunda ejecución se comprueba el contenido de los archivos, es decir, las líneas recién añadidas.

Logwatch se basa en que realmente sea capaz de leer los archivos de registro. Bajo el capó, logwatch hace todo lo posible para reconocer la codificación de cada archivo de registro. Sin embargo, las codificaciones de caracteres demasiado exóticas pueden dar problemas. Si puedes especificar la codificación de caracteres de los archivos de registro monitorizados, UTF-8 es una muy buena opción. Si esto no es posible y logwatch no consigue averiguar la codificación, puedes hacer una especificación explícita con Codec that should be used to decode the matching files.

Con Duplicated messages management, si activas esta opción, puedes ahorrar de nuevo 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 ha repetido una línea y lo escribe en consecuencia en la salida, en lugar de repetir las líneas.

Por último, las líneas de los archivos de registro que te interesen 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 conduzca 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 duplican aquí.

Un punto 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 para realizar después la clasificación final. Esto nos lleva a un punto importante que muestra lo flexible que puede ser Logwatch cuando se utiliza correctamente.

Todas las opciones explicadas en esta sección se convierten en entradas del archivo de configuración ya mencionado, que se almacena en el host respectivo. Si ahora quieres hacer cambios en la clasificación de determinados mensajes, puede que primero tengas que editar la regla, y luego bakear el agente e instalarlo.

Alternativamente, puedes transferir primero todos los mensajes interesantes al servidor Checkmk (por ejemplo, con el estado OK ), y luego en el servidor Checkmk (re)clasificarlos con la regla Logfile patterns. De este modo te ahorrarás el trabajo de hornear y desplegar el nuevo agente, y después de personalizar la regla mencionada en consecuencia, tendrás que -sólo una vez- activar rápidamente los cambios. Más adelante, en el capítulo Reclasificar con patrones de archivo de registro, encontrarás cómo hacerlo exactamente.

En el Checkmk Raw 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 ser la siguiente

En primer lugar, introduce siempre aquí un patrón glob, seguido de todas las opciones que deban aplicarse. A continuación, sigue -con una sangría de un espacio- una letra que represente el estado o función deseados y, por último, una expresión regular que se compare 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 comprobarían en busca de los dos patrones, a critical message y something that should only trigger a warning.

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

Como todas las opciones que puedes especificar en un archivo de configuración de este tipo ya se han explicado en la sección Configuración a través del Agent bakery, a continuación sólo se ofrece una lista y una breve descripción. Consulta la sección anterior para obtener una explicación detallada.