 |
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
El mecanismo «piggyback» lleva en uso desde los inicios de Checkmk, como parte de la monitorización de VMware. Te explico una situación en la que hay que consultar datos de un host concreto porque esos datos solo están en ese host (por ejemplo, de un sistema host ESX o del vCenter), pero en la monitorización los datos se refieren a un host completamente diferente (una máquina virtual, por ejemplo).
Esto no se puede hacer con el mecanismo normal de Checkmk, ya que este asigna automáticamente los datos y servicios que obtiene de un host. Además, sería muy poco práctico para la monitorización que toda la información de todas las máquinas virtuales apareciera siempre directamente en el host ESX o incluso en el vCenter.
El término «piggyback» describe el proceso por el cual los datos de monitorización del host B se «acoplan» (por así decirlo) a los datos consultados del host A.
Hoy en día, el piggyback se utiliza en muchos otros Plugins de monitorización, por ejemplo, al monitorizar
Además de los entornos de virtualización, el mecanismo piggyback también se puede utilizar para la supervisión de dispositivos móviles o la monitorización climática en el centro de datos (MQTT). Dado que las interfaces de consulta son muy sencillas, es muy fácil utilizar el mecanismo piggyback por tu cuenta. Puedes utilizarlo, por ejemplo, al implementar tus propios check plugins para realizar el mapeo de datos de una fuente a cualquier otro host.
2. El principio del «piggyback»
El principio básico del piggyback funciona como se muestra en el siguiente diagrama: El host A no solo tiene sus propios datos de monitorización, sino también los de otros hosts —o, en términos más generales, los de otros objetos—. Por ejemplo, un host ESX registra el estado y muchas métricas actuales de cada una de sus máquinas virtuales (VM). A este host A se le denomina host piggyback.
Si Checkmk recupera ahora los datos de monitorización de A en sus intervalos habituales de un minuto —ya sea desde el agente Checkmk normal o desde un agente especial a través de la API de un fabricante—, en la respuesta también recibe datos de informes especialmente marcados de los otros hosts/objetos B, C, y así sucesivamente. Estos datos piggyback se guardan luego en archivos en el servidor Checkmk para su procesamiento posterior. A los hosts B, C, etc., se les llama hosts piggyback.
Si más adelante Checkmk necesita los datos de monitorización de B o C, estos ya están en los archivos locales y se pueden procesar directamente sin tener que consultar a un agente:
También es posible y útil combinar la monitorización normal con el piggybacking. Tomemos de nuevo el ejemplo de VMware: Es posible que hayas instalado un agente Checkmk en tu máquina virtual B que evalúa información local de la máquina virtual que el host ESX desconoce (por ejemplo, los procesos que se ejecutan en la máquina virtual). En este caso, no solo se consultará al agente, sino que sus datos también se combinarán con los datos piggyback recibidos del host A:
3. El piggyback en la práctica
3.1. Configuración del piggyback
Primero, la buena noticia: el mecanismo de piggyback suele funcionar de forma totalmente automática:
Si al consultar a A se detectan datos piggyback de otros hosts, estos se guardan automáticamente para su posterior evaluación.
Si se encuentran datos piggyback de otro host al consultar B, se utilizarán automáticamente.
Sin embargo —como es habitual en Checkmk— todo es configurable. Concretamente, en las propiedades de un host (como el host B), en la caja «Monitoring agents» puedes configurar cómo debe reaccionar ante datos piggyback existentes o ausentes:
El valor predeterminado 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 simplemente utiliza sus «propios» datos de monitorización.
Con la configuración «Always use and expect piggyback data» (Forzar datos piggyback), obligas a que se procesen los datos piggyback. Si los datos faltan o están desactualizados, el servicio Check_MK emitirá una advertencia.
Y con Never use piggyback data, cualquier dato piggyback que se encuentre simplemente se ignora, una configuración que solo necesitarás en casos excepcionales.
3.2. Los hosts deben estar presentes
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 administración dinámica del host y crear automáticamente hosts para los que haya datos piggyback disponibles.
3.3. Nombres del host y sus asignaciones
En los esquemas anteriores, resultaba lógico que los datos sobre el 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 complementos —como Docker— también tienen varias opciones sobre qué se debe utilizar como nombre.
 |
Los datos piggyback de los hosts cuyos nombres empiezan por un punto no se procesan en Checkmk.
Esto se aplica, por ejemplo, a nombres como |
Para que el mapeo funcione correctamente, el nombre del host correspondiente en Checkmk debe ser, por supuesto, idéntico, incluyendo mayúsculas y minúsculas.
Pero, ¿qué pasa si los nombres de los objetos en los datos piggyback son inadecuados o indeseables para la monitorización?
Son inadecuados, por ejemplo, los nombres de hosts piggyback que consisten únicamente en un punto o que empiezan por un punto, como .myhostname, ya que estos no se procesan en Checkmk.
Existe un conjunto de reglas especial Host name translation for piggybacked hosts, que puedes encontrar en el Menú de configuración en Setup > Agents > Agent access rules.
Para configurar un cambio de nombre, tendrás que hacer dos cosas:
Crear una regla y establecer la condición para acceder al host piggyback, es decir, el host A.
Crear un valor de asignación de nombre adecuado en la regla.
Aquí tienes un ejemplo del valor en una regla.
Primero, se elimina la parte del dominio de los nombres de host con Convert FQHN.
A continuación, todos los nombres de host de los datos piggyback se convierten a minúsculas.
Por último, los dos hosts vm0815 y vm081 se convierten en los hosts de Checkmk mylnxserver07 y mylnxserver08:
Más flexible es el método que utiliza expresiones regulares, que se encuentra en Multiple regular expressions. Esto resulta útil si es necesario renombrar muchos hosts y se hace siguiendo un esquema específico. Proceda de la siguiente manera:
Activa la opción Multiple regular expressions.
Añade una entrada de traducción con el botón «Add expression»: aparecerán dos campos.
En el primer campo —Regular expression— introduce una expresión regular que coincida con el nombre original del objeto y que contenga al menos un subgrupo, es decir, una subexpresión entre paréntesis. Para una buena explicación de estos grupos, consulta el artículo sobre expresiones regulares.
En «Replacement», especifica un esquema para el nombre del host de destino deseado en el que los valores que se «capturaron» con los subgrupos se sustituirán por
\1,\2, etc.
Un ejemplo de expresión regular sería, por ejemplo, vm(.*)-local.
El valor de sustitución myvm\1 traduciría entonces el nombre vmharri-local a myvmharri.
3.4. Datos piggyback obsoletos
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 ya no está disponible temporalmente —o incluso de forma permanente—? ¿Se tratan todos los datos piggyback de la misma manera o hay diferencias? Al igual que con muchos otros temas en Checkmk, el comportamiento aquí también es una cuestión de configuración y, por lo tanto, de reglas. Con la regla Processing of piggybacked host data, que puedes encontrar en Setup > Agents > Agent access rules, puedes configurar varias opciones.
En la sección Processing of piggybacked host data introduce 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 hosts/objetos para los que un host piggyback no proporciona (o ya no proporciona) datos piggyback. Con la opción «Keep hosts while piggyback source sends piggyback data only for other hosts» (Vida útil de los datos piggyback), especificas el tiempo tras el cual se eliminan los archivos afectados con datos piggyback. Asegúrate de que este periodo de tiempo sea al menos tan largo como el intervalo de check de los hosts 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 proporciona datos nuevos. Una vez transcurrido el periodo definido, los servicios basados en los datos piggyback se muestran como obsoletos. También defines el estado del servicio «Check_MK» durante este periodo. Puedes utilizar esto para evitar avisos innecesarios, especialmente si se producen repetidas interrupciones de conexión de corta duración.
Una vez que hayas definido cómo manejar los datos piggyback en general, puedes definir cómo manejar los datos piggyback de forma específica (siguiendo el mismo esquema) para hosts individuales en Exceptions for piggybacked hosts utilizando las opciones descritas.
Por último, siempre debes especificar el nombre del host piggyback en la opción Explicit hosts del Conditions.
4. La tecnología que hay detrás de este proceso
4.1. Transporte de los datos piggyback
Como se ha descrito anteriormente, los datos piggyback también se envían a otros hosts junto con la salida del agente del host piggyback. La salida del agente Checkmk tiene un formato sencillo basado en texto.
La novedad es que se permite una línea en la salida que empieza por <<<< y termina por >>>>.
En medio va el nombre del host.
Todos los datos de monitorización posteriores a esta línea se asignan entonces a este host.
Aquí tienes un ejemplo que asigna la sección <<<esx_vsphere_vm>>> al host 316-VM-MGM:
<<<<316-VM-MGM>>>>
<<<esx_vsphere_vm>>>
config.datastoreUrl url /vmfs/volumes/55b643e1-3f344a10-68eb-90b11c00ff94|uncommitted 12472944334|name EQLSAS-DS-04|type VMFS|accessible true|capacity 1099243192320|freeSpace 620699320320
config.hardware.memoryMB 4096
config.hardware.numCPU 2
config.hardware.numCoresPerSocket 2
guest.toolsVersion 9537
guest.toolsVersionStatus guestToolsCurrent
guestHeartbeatStatus green
name 316-VM-MGM
...
<<<<>>>>Para finalizar esta asignación, debes usar una línea con el contenido <<<<>>>>.
Cualquier salida posterior volverá a pertenecer al host piggyback.
Al procesar la salida del agente Checkmk, Checkmk extrae las partes destinadas a otros hosts y las coloca en archivos bajo ~/tmp/check_mk/piggyback.
Debajo de esto hay un subdirectorio para cada host piggyback (por ejemplo, para cada máquina virtual), es decir, si nos ceñimos a nuestro ejemplo con el nombre B.
En este subdirectorio habrá entonces un archivo independiente con los datos reales de cada host piggyback.
Sus nombres serían A en nuestro ejemplo.
¿Por qué es tan complicado?
Bueno, un host puede recibir datos piggyback de varios hosts, así que un solo archivo no sería suficiente.
|
Si tienes curiosidad por saber cómo son los datos piggyback, busca la salida del agente de los hosts de tu sitio de monitorización en el directorio |
El comando `cmk-piggyback list sources` devuelve una lista de todos los hosts piggyback que han proporcionado datos para otros hosts.
Su equivalente es `cmk-piggyback list piggybacked`, que muestra una lista de todos los hosts piggyback (independientemente de si ya están incluidos en la monitorización).
El comando cmk-piggyback también ofrece opciones adicionales para observar el tratamiento de los datos piggyback en la monitorización.
Por ejemplo, con cmk-piggyback track puedes ver todos los datos piggyback entrantes.
Puedes usar cmk-piggyback create-sections para crear datos piggyback de muestra.
4.2. Datos piggyback huérfanos
Si trabajas en un entorno en el que los hosts cambian automáticamente el host piggyback, te recomendamos utilizar la administración dinámica del host. Si no puedes o no quieres utilizar la administración dinámica del host, por ejemplo, porque las máquinas virtuales se mueven manualmente, puedes recibir datos piggyback de un host que ni siquiera has creado en Checkmk. Esto puede ser intencionado, pero también puede ser un error, por ejemplo, porque un nombre no tiene concordancia exacta.
El comando cmk-piggyback list orphans te muestra todos los objetos para los que hay datos piggyback disponibles, pero no existe ningún host en la monitorización.
Muestra una lista con una línea por cada host piggyback no monitorizado encontrado:
Esta salida está «limpia» y se puede, por ejemplo, procesar en un script.
4.3. Piggyback en la monitorización distribuida
En la monitorización distribuida, puedes organizar tus datos piggyback según tus estructuras operativas. Esto significa que los datos piggyback que llegan a la monitorización a través de un host pueden asignarse a otro host para su evaluación, incluso entre sitios. Los datos piggyback se reenvían a través del site central.
Por defecto, los datos piggyback siempre se procesan en el site en el que se detectan, y los datos se asignan automáticamente al host al que llegan. Puedes cambiar este comportamiento a través de las propiedades del host.
Selecciona aquí la sede alternativa deseada, ya sea la sede central o una sede remota en la que quieras realizar la monitorización de los datos piggyback. Lo siguiente también se aplica a los hosts de la «nueva» sede: los hosts deben estar presentes.
Para reducir la carga en tu site central, también puedes transferir los datos piggyback de un site remoto a otro directamente, es decir, sin involucrar al site central. Encontrarás más información sobre esta conexión peer-to-peer en el artículo «Monitorización distribuida».
5. Archivos y directorios
5.1. Rutas de archivos en el servidor Checkmk
| Ruta | Descripción |
|---|---|
|
Ubicación de almacenamiento de los datos piggyback |
|
Directorio para datos piggyback del Host B |
|
Archivo con datos piggyback del Host A para el Host B |
|
Metainformación de los hosts que crean datos piggyback |
|
Salida del agente del Host A — incluyendo cualquier dato piggyback existente en formato sin procesar |
|
Script helper con herramientas de análisis para funciones piggyback. Muestra información sobre su carga con |