El mecanismo piggyback

Primero las buenas noticias: el mecanismo piggyback suele funcionar de forma totalmente automática:

Sin embargo, como es habitual en Checkmk, todo es configurable. En concreto, en las propiedades de un host (como el host B), en la caja Monitoring agents, puedes establecer cómo debe reaccionar ante los datos piggyback existentes o ausentes:

El valor por defecto es Use piggyback data from other hosts if present. Si están disponibles, se utilizan los datos piggyback, y si no hay ninguno, el host sólo utiliza sus "propios" datos de monitorización.

Con el ajuste Always use and expect piggyback data fuerzas el proceso de los datos piggyback. Si faltan datos o no están actualizados, el servicio Check_MK emitirá una advertencia.

Y con Never use piggyback data cualquier dato piggyback encontrado simplemente se ignora - una configuración que sólo necesitarás en casos excepcionales.

Por supuesto, para que un host procese datos piggyback, el propio host debe estar presente en la monitorización. En el ejemplo de ESX, esto significa que también debes tener tus máquinas virtuales como hosts en Checkmk, para que se monitoricen realmente.

En las ediciones comerciales, puedes automatizar esto utilizando la configuración dinámica y crear automáticamente hosts para los que haya datos piggyback disponibles.

En los esquemas anteriores era de algún modo lógico que los datos del objeto B se asignaran al host B en la monitorización, pero ¿cómo funciona exactamente?

Con el mecanismo piggyback la asignación siempre utiliza un nombre. El agente (especial) escribe un nombre de objeto para cada conjunto de datos piggyback. En el caso de ESX, por ejemplo, el nombre de la máquina virtual. Algunos plugins -como Docker-también tienen varias opciones para lo que debe utilizarse como nombre.

Nota: Los datos piggyback de hosts cuyos nombres empiezan por un punto no se procesan en Checkmk. Esto se aplica, por ejemplo, a nombres como ., .hostname o .hostname.domain.com. Para incluir estos hosts en la monitorización, los nombres del host deben cambiarse como se describe.

Para que el mapeo funcione correctamente, el nombre del host que coincida en Checkmk debe ser, por supuesto, idéntico, incluyendo mayúsculas y minúsculas.

Pero, ¿qué ocurre si los nombres de los objetos de los datos piggyback son inadecuados o indeseables para la monitorización? Son inadecuados, por ejemplo, los nombres de host piggyback que constan sólo de un punto o empiezan por un punto, como .myhostname, ya que no se procesan en Checkmk. Existe un conjunto de reglas especial Hostname translation for piggybacked hosts, que encontrarás en el Menú de configuración, en Setup > Agents > Agent access rules.

Para configurar un cambio de nombre tendrás que hacer dos cosas:

Aquí tienes un ejemplo del valor en una regla. Se configuran dos cosas: en primer lugar, todos los nombres del host de los datos piggyback se convierten a minúsculas. A continuación, los dos host vm0815 o vm0816 también se convierten a mylnxserver07 o mylnxserver08 del host Checkmk:

Más flexible es el método que utiliza expresiones regulares, que se encuentra en Multiple regular expressions. Es útil si es necesario renombrar muchos host y se hace según un esquema específico. Procede como sigue:

Un ejemplo de expresión regular sería, por ejemplo vm(.*)-local. El valor sustitutivo myvm\1 traduciría entonces el nombre vmharri-local en myvmharri.

Si tu red cambia, los datos piggyback también pueden cambiar. Esto plantea nuevas preguntas. ¿Cómo reacciona la monitorización si no se puede acceder a un host? ¿Qué ocurre si los datos piggyback quedan obsoletos, por ejemplo porque el objeto deja de estar disponible temporalmente -o incluso permanentemente-? ¿Todos los datos piggyback se tratan de la misma manera o hay diferencias? Como ocurre con muchos otros temas en Checkmk, el comportamiento aquí también es cuestión de configuración y, por tanto, de reglas. Con la regla Processing of piggybacked host data, que encontrarás en Setup > Agents > Agent access rules, puedes establecer varias opciones.

En la sección Processing of piggybacked host data introduces los detalles realmente interesantes para procesar los datos piggyback.

Checkmk te facilita el trabajo a la hora de gestionar los datos piggyback. Entre otras cosas, elimina automáticamente todos los host/objetos para los que no hay (o ya no hay) datos piggyback suministrados por un host de origen. Con la opción Keep hosts while piggyback source sends piggyback data only for other hosts especificas el periodo de tiempo tras el cual se eliminan los archivos afectados con datos piggyback. Asegúrate de que este periodo es al menos tan largo como el intervalo de check de los host piggyback.

Utiliza las dos opciones de Set period how long outdated piggyback data is treated as valid para definir durante cuánto tiempo deben seguir considerándose válidos los datos piggyback existentes si el host ya no suministra datos nuevos. Una vez transcurrido el periodo definido, los servicios basados en los datos piggyback se muestran como obsoletos. Define también el estado del servicio Check_MK durante este periodo. Puedes utilizarlo para evitar avisos innecesarios, sobre todo si se producen repetidas interrupciones de la conexión a corto plazo.

Una vez que hayas definido el tratamiento de los datos piggyback en general, puedes definir un tratamiento separado (según el mismo esquema) para host individuales en Exceptions for piggybacked hosts utilizando las opciones descritas.

Por último, debes especificar siempre el nombre del host de origen en la opción Explicit hosts de Conditions.

Como se ha descrito anteriormente, los datos piggyback también se transportan a otros hosts con la salida del agente del host de origen. La salida del agente Checkmk es un formato simple basado en texto, que se muestra en el artículo sobre agentes de monitorización.

La novedad es que se permite una línea en la salida que empiece por <<<< y termine por >>>>. En medio hay un nombre del host. Todos los datos de monitorización posteriores que empiecen por esta línea se asignan entonces a este host. He aquí un extracto de ejemplo que asigna la sección <<<esx_vsphere_vm>>> al host 316-VM-MGM:

Se puede utilizar una línea con el contenido <<<<>>>> para finalizar esta asignación. Cualquier salida posterior pertenece de nuevo al host de origen.

Al procesar la salida del agente, Checkmk extrae las partes destinadas a otros hosts y las coloca en archivos bajo ~/tmp/check_mk/piggyback. Debajo de éste hay un subdirectorio para cada host de destino (por ejemplo, para cada VM) -es decir, si nos ceñimos a nuestro ejemplo con el nombre B. En este subdirectorio habrá entonces un archivo separado con los datos reales de cada host de origen. Sus nombres serían A en nuestro ejemplo. ¿Por qué es esto tan complicado? Bueno -un host puede de hecho obtener datos piggyback de múltiples hosts, por lo que un único archivo no sería suficiente.

Consejo: Si tienes curiosidad por saber qué aspecto tienen los datos piggyback, busca la salida del agente de los hosts de tu sitio de monitorización en el directorio ~/tmp/check_mk/cache. A continuación encontrarás un resumen de todos los archivos y directorios implicados.

Si trabajas en un entorno en el que los hosts cambian automáticamente el host de origen, te recomendamos que utilices la configuración dinámica de host. Si no puedes o no quieres utilizar la configuración dinámica de host, por ejemplo, porque las máquinas virtuales se mueven manualmente, es posible que recibas datos piggyback de un host que ni siquiera has creado en Checkmk. Esto puede ser intencionado, pero también puede tratarse de un error, por ejemplo, porque un nombre no coincide exactamente.

En los "Tesoros" encontrarás un script llamado find_piggy_orphans con el que tu Checkmk puede buscar datos piggyback para los que no haya ningún host en monitorización. Simplemente llama a este script sin argumentos. El script emitirá una lista con una línea -ordenada por nombre- para cada host piggyback no monitorizado que se encuentre:

Esta salida es "limpia" y puede, por ejemplo, procesarse en un script.

Ten en cuenta que, actualmente, en entornos distribuidos, el host de origen y los host piggyback deben monitorizarse en el mismo site. Esto se debe simplemente a que -por razones de eficiencia- la transmisión de datos entre los hosts se realiza mediante el intercambio local de archivos que se ejecuta a través del directorio ~/tmp/check_mk.