 |
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
La monitorización de tareas que se procesan de forma regular o bajo demanda, así como de procesos que se ejecutan de forma permanente, se puede realizar, por ejemplo, analizando archivos de registro o de estado. Sin embargo, esto suele suponer un esfuerzo adicional, ya que a menudo es necesario leer grandes volúmenes de datos para extraer poca información.
Para reducir este esfuerzo, Checkmk ofrece la opción de que un programa escriba la salida directamente en un archivo en formato de agente Checkmk. Almacenados en el llamado directorio de spool, el agente recopila todos estos archivos e integra su contenido en la salida del agente. El método que utiliza el directorio de spool es útil, por ejemplo, para
el análisis periódico de archivos de registro,
monitorización de copias de seguridad automáticas,
crear y checkear estadísticas de carga a partir de una base de datos,
cuando el Plugin «
mk-job» no es suficiente para controlar los cronjobs,el desarrollo de checks propios para probar la salida de muestra.
En Checkmk, el directorio spool es compatible con los agentes en los siguientes sistemas operativos: Windows, Linux, AIX, FreeBSD, OpenWrt y Solaris.
Para asegurarte de que puedes usar esta función sin problemas, hay algunos puntos que debes tener en cuenta.
2. Rutas de los directorios de archivos
La ruta de archivo predeterminada al directorio de spool es /var/lib/check_mk_agent/spool/ en Linux y otros sistemas Unix, y C:\ProgramData\checkmk\agent\spool\ en Windows.
En Linux y Unix puedes personalizar la ruta del directorio principal con la regla Agent rules > Installation paths for agent files (Linux, UNIX) y la opción Base directory for variable data (caches, state files) disponible allí.
Si estás trabajando en un host en monitorización, puedes filtrar el directorio de spool configurado allí de la salida del agente:
Checkmk utiliza un único directorio de spool, que por defecto es propiedad de root.
No se proporcionan múltiples directorios con diferentes propietarios.
Sin embargo, por supuesto puedes crear archivos (inicialmente vacíos) en el directorio de spool y nombrar propietario a otro usuario, quien podrá entonces sobrescribir el contenido de su archivo.
|
¡Ten en cuenta que el agente no checkea el contenido de los archivos spool! Los archivos spool manipulados pueden sobrescribir secciones normales del agente y, por lo tanto, crear la falsa impresión de un funcionamiento sin problemas. Incluso sin intención maliciosa, existe el riesgo potencial de que un archivo spool contenga una salida del agente dañada, lo que provocaría que las partes posteriores de la salida del agente se ignoraran por completo. |
3. Nombres y contenido de los archivos
Los archivos spool pueden contener salida de texto en cualquiera de los formatos procesados por Checkmk. Los archivos se añaden unos tras otros en el orden en que aparecen en el directorio de spool. La extensión del archivo no importa.
Si quieres usar un esquema numérico para ordenarlos, antepone un guión bajo al nombre del archivo (_), ya que los nombres de archivo que empiezan por números sirven para comprobar la antigüedad.
Los archivos que empiezan por un punto se ignoran.
Para evitar confusiones en el contenido del archivo concatenado, cada archivo spool debe
empezar con un título de la sección, es decir, una línea entre
<<<y>>>— incluso si solo se usa el formato de local checks en el archivo —terminar con un salto de línea.
Así, una local check que proporcione un servicio de forma inmediata podría tener este aspecto:
<<<local>>>
0 "Spool Test Dummy" - This static service is always OKDel mismo modo, puedes omitir las salidas que requieran un check plugin en el lado de Checkmk:
<<<waterlevels>>>
rainbarrel 376
pond 15212
pool 1237323.1. Finalización de secciones piggyback
Si utilizas secciones piggyback en un archivo, termina este archivo con la línea <<<<>>>>.
Esta es la única forma de garantizar que, si cambia el orden de lectura, la salida que sigue a la salida piggyback se reasigne al propio host.
4. Check de la antigüedad de los archivos
Si un programa puede escribir correctamente en su archivo de salida, todo va bien, independientemente de si el proceso ha concluido con éxito o no. Pero, ¿qué pasa si un programa se interrumpe antes de escribir en el disco, o si un error del sistema de archivos impide que se escriban nuevos archivos?
Para esta situación, tienes la opción de anteponer un número entero al nombre del archivo, por ejemplo, 600MyCronjob.
En este caso, el número se interpretará como la antigüedad máxima del archivo en segundos.
Si el archivo es más antiguo, el agente lo ignorará y el servicio asociado en Checkmk pasará al estado UNKNOWN debido a la falta de salida.
En el ejemplo de un archivo llamado 3900_hourly_cleaner.txt, el número se ha elegido así para un cronjob que se ejecuta cada hora, para el que se espera un tiempo de ejecución inferior a cinco minutos.
5. Un ejemplo práctico
Supongamos que gestionas un servicio en el que los usuarios inician y cierran sesión. En los archivos de registro del servicio, encontrarás líneas de los tres tipos siguientes:
21/Oct/2022:12:42:09 User harrihirsch logged in from 12.34.56.78
21/Oct/2022:12:42:23 User zoezhang logged out after 10 min idle
21/Oct/2022:13:00:00 Current user count: 739El proceso no escribe la línea con Current user count después de cada inicio de sesión o cierre de sesión, sino a intervalos fijos.
Si el número de líneas del archivo de registro es lo suficientemente bajo como para leerlo rápidamente, puedes programar un local check.
Esta check lee todo el archivo de registro línea por línea cada vez y siempre establece el recuento de usuarios en el valor mostrado cuando aparece la línea Current user count.
Cuando aparecen las líneas logged in y logged out, aumenta o disminuye el recuento de usuarios.
Al final, tu check imprime una línea similar a la siguiente:
1 "Frobolator User Count" count=1023 Watch out! Limit nearly used up.A medida que tu servicio se vuelve más popular, la local check tarda cada vez más en ejecutarse, hasta que llega un punto en el que esta solución, e incluso ejecutarla como un plugin de agente asíncrono, ya no resulta práctica. Aquí es donde el uso adecuado del directorio de spool puede aumentar drásticamente la eficiencia de la ejecución de la comprobación. En los siguientes párrafos, te mostraremos cómo modificar el programa que ha estado proporcionando tu local check para que haga un uso eficaz del directorio de spool.
En primer lugar, el programa no debe cerrarse al llegar al final del archivo, sino escribir un archivo spool que contenga el estado actual del servicio una vez evaluado completamente el archivo de registro:
<<<local>>>
2 "Frobolator User Count" count=1200 Maximum number of users reached!A continuación, deja que tu programa espere un cierto periodo de tiempo —ya sean unos segundos o varios minutos, dependiendo de la frecuencia con la que se añadan nuevas entradas al registro—. Después, debe evaluar solo las líneas recién añadidas y volver a calcular el estado. Si los números han cambiado, reescribirá el archivo spool.
Programa este procedimiento como un bucle infinito.
Para detectar un posible crash de este programa, debes nombrar el archivo spool en consecuencia, por ejemplo, 1800_frobolator.txt — si 30 minutos sin actualizar el archivo spool indican problemas con el servicio o con el programa de evaluación.
En lugar del directorio de complementos del agente, inicia ahora el programa como un daemon utilizando las opciones de tu sistema operativo. Presta atención aquí al reinicio automático, si el programa crashea o se cierra. Muchas aplicaciones de servidor también ofrecen la opción de redirigir la salida del registro a otro programa, en lugar de o además de escribir archivos de registro normales. Utilizar este mecanismo para un script de evaluación que escribe archivos spool también es una buena idea.
6. Algunos detalles que debes tener en cuenta
La lectura de archivos puede presentar otros inconvenientes en comparación con el inicio habitual de procesos por parte del agente. Ten en cuenta los siguientes puntos para garantizar un funcionamiento sin problemas.
6.1. Juego de caracteres
Checkmk espera que la salida del agente esté codificada exclusivamente en UTF-8 (sin marca de orden de bytes / BOM) con un simple salto de línea (0x0A o \n) como separador de líneas.
Las desviaciones pueden, en el peor de los casos, provocar que la salida del agente no se pueda leer más allá del primer carácter de un archivo spool con formato incorrecto.
En concreto, esto significa:
Especialmente en sistemas Windows y Linux más antiguos, asegúrate de que los archivos spool no se escriban con la codificación Windows 1250 a 1258 o ISO 8859. Si esto es inevitable, asegúrate de que solo se utilice la intersección con UTF-8 —ASCII de 7 bits de facto—.
Especialmente en los sistemas Windows más recientes, asegúrate de que los archivos spool no se escriban con la codificación UTF-16 que se usa allí como estándar.
No usa BOM. En particular, los lenguajes de scripting en Windows suelen escribir automáticamente esta secuencia de caracteres, que indica la codificación utilizada, en los archivos de salida. En la salida del agente, esto impide que aparezca
<<<al principio de una línea.Usa el salto de línea de Unix (
0x0Ao\n). Una vez más, Windows suele usar la cadenaCRLF(0x0D 0x0Ao\r\n).
Si un archivo spool provoca un comportamiento indeseado, examina sus primeras líneas con un editor hexadecimal:
0xFF 0xFEindica un archivo codificado en UTF-16: En este caso, cambia tus scripts para que generen salida en UTF-8.0xEF 0xBB 0xBFmuestra UTF-8 con BOM. En este caso, suele bastar con escribir el archivo sin BOM en el futuro.
6.2. Soft links y tuberías con nombre
En principio, los archivos del directorio de spool también pueden ser soft links o tuberías con nombre. Cabe señalar que la comprobación de antigüedad a través de los nombres de archivo no funciona aquí, ya que se evalúa la antigüedad del propio soft link o de la tubería con nombre, y no la de los datos escritos. En el caso de las tuberías con nombre, también debes asegurarte de que el proceso que escribe en la tubería siempre proporcione datos. Si no se proporcionan datos, el agente Checkmk esperará indefinidamente y, finalmente, realizará un timeout.
Si necesitas permitir que usuarios sin privilegios escriban en archivos spool, crea archivos vacíos para estos usuarios y configura su propiedad en consecuencia. Estos usuarios podrán entonces crear un soft link por su cuenta o escribir directamente en el archivo spool.
6.3. Bloqueo y almacenamiento en búfer
Al escribir programas más largos que escriben varias líneas de estado en un archivo spool, es tentador abrir el archivo de salida para escribir en él cuando se inicia el programa. Sin embargo, en este caso el archivo permanecerá completamente vacío hasta que el búfer de escritura se vacíe primero y se escriba en el destino, y estará incompleto hasta que el programa de escritura haya cerrado el archivo. Lo mismo ocurre si un archivo se bloquea de forma exclusiva durante una operación de escritura larga.
Por esta razón, debes escribir en el archivo de salida solo cuando todo el contenido que se va a escribir esté disponible, o escribir en un archivo temporal que luego copies al directorio de spool —o, respectivamente, usar cat para transferir el contenido de un archivo temporal a uno ya existente en el directorio de spool.
6.4. Mantener una vista general
Puede surgir otro problema cuando diferentes programas intentan escribir en archivos con el mismo nombre. Con muchos archivos spool, es fácil perder la pista de qué programa escribe realmente en qué archivo spool. En particular, si un archivo spool con un formato incorrecto hace que parte de la salida del agente quede inutilizable, esto resulta muy molesto y puede dar lugar a una búsqueda que lleva mucho tiempo.
Puedes mantener todo en orden creando un archivo con el mismo nombre —precedido de un punto— para cada archivo spool, que contenga información sobre el trabajo y una persona de contacto, si procede. El contenido de este archivo oculto no se transfiere con él.