 |
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. Monitorización sintética con Robot Framework
La monitorización sintética de Checkmk está disponible en las ediciones comerciales de Checkmk, pero requiere una suscripción adicional.
No obstante, puedes probar la función con hasta tres pruebas de forma gratuita y sin límite de tiempo.
Con Checkmk puedes realizar la monitorización de tu propia infraestructura muy de cerca, hasta el punto de saber si un servicio concreto, como un servidor web, funciona correctamente. Si tu sitio web se opera a través de un servicio en la nube de terceros, no tendrás acceso al servicio en sí, pero puedes usar una check HTTP para verificar si se puede acceder al sitio web. Pero, ¿eso dice algo sobre la experiencia del usuario? El hecho de que se pueda acceder a una tienda online no significa que la navegación, los procesos de pedido y demás funcionen sin problemas.
Aquí es donde entra en juego Checkmk Synthetic Monitoring. Con el Plugin Robotmk, Checkmk ofrece una verdadera monitorización de extremo a extremo, es decir, la monitorización de las aplicaciones en ejecución desde la perspectiva del usuario. Las pruebas propiamente dichas las lleva a cabo el software Open Source Robot Framework, del que Checkmk GmbH también es miembro.
El software de automatización permite replicar por completo el comportamiento de un usuario, por ejemplo, para simular procesos de pedido en tiendas online, «clic a clic».
Lo especial de Robot Framework es que las pruebas no se escriben en un lenguaje de programación completo, sino que se definen mediante palabras clave fáciles de usar, como «Open Browser» o «Click Button».
Basta con un «Open Browser checkmk.com» para acceder al sitio web de Checkmk.
A continuación, varios casos de prueba se combinan en los llamados conjuntos de pruebas (en forma de un archivo .robot).
Robotmk puede ahora distribuir estos conjuntos de pruebas de Robot Framework en el host y realizar la monitorización de su ejecución y resultados como servicios en Checkmk. En la interfaz web de Checkmk encontrarás entonces el estado, los gráficos de rendimiento asociados y las evaluaciones originales del propio Robot Framework.
1.1. Componentes
Varios componentes trabajan juntos para crear esta monitorización de extremo a extremo, así que aquí tienes una breve vista general.
servidor Checkmk
La monitorización sintética de Checkmk se lleva a cabo a través de Robotmk, que utiliza un plugin de agente como recopilador de datos, y el programador de Robotmk (en el host monitorizado) para activar los proyectos de Robot Framework. La monitorización sintética se activa y configura a través de la reglaRobotmk Scheduler . Aquí se especifica qué conjuntos de pruebas deben ejecutarse y cómo exactamente debe iniciarlos Robot Framework, resumido en un plan. Una vez distribuido, el programador de Robotmk en el host de destino garantiza la ejecución programada de tus conjuntos de pruebas de Robot Framework.
En la monitorización se generarán varios servicios nuevos: RMK Scheduler Status muestra el estado del propio programador, es decir, si las suites de pruebas se han podido iniciar correctamente. También hay servicios para todos los planes de pruebas configurados (como RMK MyApp1 Plan) y pruebas individuales de las suites de pruebas (como RMK MyApp1 Test). Los servicios de las pruebas individuales también incluyen los informes originales de Robot Framework.
Además, hay dos reglas de servicio opcionales: Robotmk plan y Robotmk test permiten realizar un ajuste preciso en los servicios de planes y pruebas, por ejemplo, para aplicar cambios de estado en determinados momentos de ejecución.
Por último, pero no menos importante, hay dos reglas para la monitorización de KPI: KPI significa «Key Performance Indicator» (indicador clave de rendimiento) y, en este contexto, se refiere a palabras clave individuales. Con la regla Robotmk KPI discovery, las palabras clave se pueden incorporar a la monitorización como servicios independientes y evaluarse en consecuencia mediante Robotmk KPI monitoring. Te mostraremos exactamente cómo funciona la monitorización de palabras clave en un capítulo aparte más adelante.
Algo aparte de las reglas normales, también está la función «Managed robots» en el área de Setup. La versión resumida: robots que se gestionan en el servidor Checkmk y se distribuyen a través del agente Checkmk; de nuevo, hay un capítulo aparte disponible con más detalles al respecto.
Máquina de pruebas
Puedes proporcionar los conjuntos de pruebas de Robot Framework en un host Windows (a partir de Windows 10 o servidor Windows 2019) o Linux. Para su ejecución, Robot Framework requiere acceso a sus dependencias (Python, bibliotecas, controladores para la automatización del navegador, etc.). Esta configuración es independiente de Checkmk y se puede almacenar de forma declarativa en un paquete portátil. Esto se realiza con la herramienta de línea de comandos Open Source RCC. Esta herramienta utiliza tus archivos de configuración en formato YAML para crear entornos virtuales de Python que incluyen las dependencias y el propio Robot Framework. El programador de Robotmk, que se ejecuta como un proceso en segundo plano, activa esta compilación y luego ejecuta las pruebas por sí mismo.
Este paquete de automatización RCC, que incluye la configuración del paquete (robot.yaml), la definición del entorno de ejecución (conda.yaml) y los conjuntos de pruebas (tests.robot), también se denomina robot.
RCC y el programador se distribuyen con el agente Checkmk; el paquete de automatización debe estar disponible en el host.
La gran ventaja de RCC es que el propio host de ejecución de pruebas no requiere un entorno Python configurado.
El agente solo es necesario para la transferencia de resultados, registros y capturas de pantalla. Esto también permite la monitorización de conjuntos de pruebas de muy larga duración o que consumen muchos recursos a nivel local, siempre que tu host de pruebas tenga la capacidad necesaria.
Un apunte sobre los sistemas operativos que usan los hosts de prueba: los sistemas Windows y Linux se comportan de forma ligeramente diferente. Ten en cuenta, sobre todo, que las rutas de archivo definidas difieren; en los siguientes ejemplos solo usamos rutas de archivo de Windows (a menos que se requieran rutas explícitas). En caso de que RCC tenga que funcionar sin conexión, también hay diferencias en cuanto al contexto de usuario del programador de Robotmk y los comandos necesarios; aquí, por supuesto, abordamos explícitamente ambos sistemas.
Y aunque no esté directamente relacionado con Checkmk: La biblioteca del navegador de Robot Framework utiliza Playwright, y Playwright no funciona en todos los sistemas Linux compatibles con Checkmk. Ten en cuenta los requisitos del sistema correspondientes (mientras que, en nuestro caso, RCC proporciona Node.js).
Requisitos del sistema para la máquina de pruebas:
CPU: al menos 4 cores, se recomiendan 8 cores
RAM: 8 gigabytes, se recomiendan 16 gigabytes
Acceso a internet (si hay que descargar paquetes)
Para pruebas basadas en web (biblioteca del navegador de Robot Framework, basada en Playwright): Debian 12/13, Ubuntu 22.04/24.04
2. Monitorización de conjuntos de pruebas con Robotmk
A continuación, te mostraremos cómo incluir un conjunto de pruebas en la monitorización. Como ejemplo, utilizaremos un sencillo conjunto «Hello World» que solo genera dos cadenas de texto y espera un breve lapso entre cada una. Por supuesto, este artículo no trata de ofrecer una introducción a Robot Framework, pero es necesario echar un vistazo rápido al paquete de automatización y al conjunto de pruebas de demostración para que puedas ver qué datos van a parar a cada parte de la monitorización.
El ejemplo se ejecuta sobre la base de RCC, por lo que no es necesario configurar el host de Windows por separado.
El servidor de pruebas (rcc.exe) se distribuye con el agente y se encuentra en C:\ProgramData\checkmk\agent\bin\.
Puedes descargar el conjunto de pruebas de ejemplo como archivo ZIP a través de GitHub.
El directorio del conjunto de pruebas:
conda.yaml
robot.yaml
tests.robot |
RCC también puede procesar conjuntos de pruebas basados en otros lenguajes de programación, pero para su uso en Checkmk debe ser la declaración de Robot Framework. |
El directorio de la suite contiene ahora dos archivos importantes:
La declaración del entorno necesario para la ejecución en el archivo conda.yaml y las pruebas propiamente dichas en el archivo tests.robot (la suite).
El archivo robot.yaml no es relevante para su uso en Checkmk, pero es necesario para RCC.
Para completar, aquí tienes un breve vistazo al archivo robot.yaml:
En primer lugar, tasks define qué tareas, en este caso pruebas, se van a ejecutar.
Sin embargo, aunque esta parte es un requisito formal de RCC, Robotmk no la utiliza.
|
Robot Framework distingue entre pruebas y tareas, que representan automatizaciones. Sin embargo, ambas se utilizan exactamente de la misma manera. |
En el área «environmentConfigs», solo se hace referencia a «conda.yaml», que se encarga del entorno real.
En este caso, solo se instalan las dependencias de Python, Pip y Robot Framework para el entorno. La compilación del entorno aparece posteriormente en la monitorización como «RCC environment build status». Las pruebas solo se pueden procesar y, por lo tanto, supervisar si el entorno se ha compilado correctamente.
El conjunto de pruebas actual tiene ahora este aspecto:
*** Settings ***
Documentation Template robot main suite.
*** Variables ***
${MYVAR} Hello Checkmk!
*** Test Cases ***
My Test
Log ${MYVAR}
Sleep 3
Log Done.Aquí solo se muestra el valor de la variable «MYVAR»; tras una espera de 3 segundos, se mostrará «Done».
Puedes establecer el valor de la variable más adelante en la interfaz web de Checkmk; de lo contrario, se utilizará el valor por defecto «Hello Checkmk!» especificado aquí.
|
Puedes ejecutar este conjunto de pruebas manualmente.
Para ello, el agente y el RCC deben estar ya instalados (o puedes descargar tú mismo el binario del RCC).
Primero ve al directorio de tu conjunto de pruebas, donde también se encuentra el archivo |
Y esto es exactamente lo que hace el programador de Robotmk en cuanto se activa el plugin de agente.
2.1. Configurar una regla para el plugin de agente
Puedes encontrar el programador de Robotmk en Setup > Agent rules > Robotmk scheduler (Windows). Como la regla es bastante extensa, aquí tienes un vistazo a la configuración vacía:
En primer lugar, el programador necesita el directorio base en el que se encuentran todos tus conjuntos de pruebas.
Introduce esta ruta de archivo arbitraria y explícita en Base directory of suites, por ejemplo, C:\robots.
Los «Parallel plan groups» que se muestran ahora son un concepto específico de Checkmk.
Para explicarlo, primero debemos bajar un nivel en la jerarquía: aquí puedes ver el item «Sequential plans». Este plan secuencial define qué conjuntos de pruebas se deben ejecutar y con qué parámetros. Robot Framework procesará estas suites una tras otra. La razón es sencilla: en la práctica, las pruebas a veces se ejecutan en el escritorio y varias suites de pruebas podrían interferir entre sí al mismo tiempo (piensa en que se roban mutuamente el control del puntero del ratón).
Los grupos de planes son ahora una encapsulación de planes ejecutados secuencialmente, y se ejecutan ellos mismos en paralelo. De nuevo, el razonamiento es sencillo: esto permite que las suites de pruebas que no dependen del escritorio se ejecuten en sus propios planes sin retrasos; la suite de pruebas utilizada en este artículo es un buen ejemplo de este tipo de proceso.
Volvamos al diálogo: el único ajuste explícito es el intervalo de ejecución, que se configura en «Group execution interval».
|
Los planes del grupo de planes tienen, naturalmente, sus propios tiempos de ejecución, determinados por el timeout de una sola ejecución y el número máximo de ejecuciones repetidas en caso de pruebas fallidas. Por lo tanto, el intervalo de ejecución del grupo de planes debe ser mayor que la suma de los tiempos de ejecución máximos de todos los planes del grupo. El tiempo de ejecución máximo de un plan se calcula de la siguiente manera: Limit per attempt × (1 + Maximum number of re-executions). |
Ahora es el momento de configurar el primer plan.
Puedes introducir cualquier nombre en Application name.
¡Este nombre no tiene por qué ser único!
Aquí tiene sentido poner el nombre de la aplicación para la monitorización, por ejemplo OnlineShop, o en este ejemplo simplemente MyApplication.
Por supuesto, puede ocurrir que esta tienda online se pruebe varias veces, ya sea con otros conjuntos de pruebas o con el mismo conjunto de pruebas pero con parámetros diferentes.
En tales casos, el campo «Variant» se utiliza para obtener resultados inequívocos a pesar de los nombres idénticos.
Por ejemplo, si la aplicación OnlineShop se prueba una vez en alemán y otra en inglés (mediante los parámetros correspondientes), podrías usar aquí las abreviaturas correspondientes.
La monitorización devolverá entonces resultados para My OnlineShop_en y My OnlineShop_de.
Sin embargo, es necesaria la especificación en Relative path to test suite file or folder.
La ruta es relativa al directorio base especificado anteriormente, p. ej., mybot\test.robot para C:\robots\.
Como alternativa, también se puede especificar aquí un directorio (con varios archivos robot), en cuyo caso sería simplemente mybot.
Continúa con la configuración de «Execution configuration.» En «Limit per attempt» defines el tiempo máximo transcurrido —por intento— que puede ejecutarse una suite de pruebas. Con «Robot Framework re-executions» ahora puedes indicar a Robot Framework que repita las suites de pruebas de forma completa o incremental si las pruebas fallan. Si las pruebas individuales de una suite de pruebas son independientes entre sí, la estrategia incremental es la mejor forma de ahorrar tiempo. Si, por el contrario, la suite de pruebas comprueba una secuencia lógica, como «Inicio de sesión > Abrir la página del producto > Añadir el producto al carrito > Finalizar la compra», la suite de pruebas debe, por supuesto, volver a procesarse por completo. Al final, siempre hay un único resultado.
En el caso de los reintentos completos, solo se tienen en cuenta los resultados de los conjuntos autónomos para el resultado final: si una prueba falla en su último reintento, el conjunto de pruebas se cuenta como un fallo. En el caso de los reintentos incrementales, el resultado final se compone de los mejores resultados parciales: si algunas pruebas solo se ejecutan con éxito en el tercer intento, el resultado final también se cuenta como un éxito. Recordatorio: la combinación de intentos y tiempos máximos de ejecución de todos los planes de un grupo de planes determina su intervalo mínimo de ejecución.
Por defecto, la ejecución mediante RCC se activa en Automated environment setup (via RCC), para lo cual debes introducir dos valores.
En primer lugar, RCC requiere que se especifique dónde se encuentra el archivo robot.yaml.
Su objetivo principal es hacer referencia al archivo conda.yaml, que se encarga de configurar el entorno de Python, es decir, de instalar Python y sus dependencias.
Esta especificación es relativa al directorio base que has establecido anteriormente en Relative path to test suite file or folder.
Los archivos YAML se pueden guardar en subdirectorios, pero lo más recomendable es el directorio superior de la suite.
Para el directorio base anterior C:\robot\ y el directorio de la suite C:\robot\mybot, sería mybot\robot.yaml.
Con el siguiente límite de tiempo para la creación del entorno de Python, debes tener en cuenta que a veces es necesario descargar y configurar grandes volúmenes de datos.
Especialmente en el caso de los navegadores necesarios, se acumulan rápidamente varios cientos de megabytes, pero solo en la primera ejecución.
RCC solo vuelve a crear los entornos si ha cambiado el contenido de conda.yaml.
En Robot Framework parameters tienes la posibilidad de utilizar algunos de los parámetros de línea de comandos de Robot Framework (que también se muestran con el comando robot --help).
Si quieres utilizar parámetros adicionales, la opción Argument files te será de ayuda.
Un archivo especificado aquí puede contener cualquier parámetro de robot.
Encontrarás más información sobre los parámetros individuales en la ayuda en línea.
Para nuestro proyecto de ejemplo, solo se activa la opción Variables y se establece una variable MYVAR con el valor My Value.
¿Recuerdas el comando Log ${MYVAR} al principio del archivo tests.robot?
Esta es la referencia correspondiente.
robot
La opción Secret environment variables merece una atención especial, ya que no es una función original de Robot Framework.
Aquí puedes establecer variables del entorno secretas, destinadas a contraseñas en combinación con la biblioteca CryptoLibrary de Robot Framework.
Las variables establecidas aquí no aparecen en los registros, sino que se escriben en texto sin formato en los archivos de configuración de Checkmk en los respectivos hosts de prueba.
Al final de la configuración de la suite, hay tres opciones que se explican por sí mismas.
Execute plan as a specific user permite ejecutar Robotmk en el contexto de una cuenta de usuario específica. Antecedentes: Por defecto, Robotmk se ejecuta en el contexto del agente Checkmk (cuenta LocalSystem), que no tiene autorización para acceder al escritorio. Aquí se puede especificar un usuario que debe estar permanentemente conectado a una sesión de escritorio y que, por lo tanto, tiene acceso a las aplicaciones gráficas del escritorio.
Sin embargo, no te precipites: ¡los navegadores son una excepción aquí! Pueden ejecutar y renderizar páginas web en modo sin interfaz gráfica. Solo debes checkear la casilla para un usuario específico si se inicia una aplicación de escritorio dedicada fuera de los navegadores, sobre todo por razones de seguridad.
Con Assign plan/test result to piggyback host, los resultados del plan/prueba se pueden asignar a otro host. Por ejemplo, si Robot Framework está probando el proceso de pedido de una tienda online, los resultados se pueden asignar al servidor web correspondiente.
Cada ejecución de prueba genera datos que se almacenan en C:\ProgramData\checkmk\agent\robotmk_output\working\suites\.
Por defecto, se conservan los resultados de los últimos 14 días, pero debes tener en cuenta que aquí pueden acumularse rápidamente grandes volúmenes de datos.
Se generan al menos 500 kilobytes de datos por ejecución; con conjuntos de pruebas más complejos y capturas de pantalla incrustadas, por ejemplo, esto puede sumar rápidamente varios megabytes de datos.
Dependiendo del intervalo de ejecución, el tamaño del informe y tus requisitos de documentación, deberías intervenir en tal situación.
Una vez aquí, ya puedes crear más planes en este grupo de planes o en otros grupos de planes.
Al final hay dos opciones más, que a su vez se refieren a la configuración completa del programador de Robotmk.
RCC profile configuration te permite especificar servidores proxy y hosts que deben ser excluidos.
Grace period before scheduler starts también puede ser muy útil: el programador se inicia junto con el agente Checkmk antes del inicio de sesión en el escritorio, lo que, por supuesto, significa que cualquier prueba en el escritorio fallará. El inicio se puede retrasar manualmente utilizando un periodo de gracia.
Con esto se completa la configuración y puedes crear un nuevo agente con el Plugin y, a continuación, distribuirlo, ya sea manualmente o mediante las actualizaciones automáticas de agentes.
Datos en la salida del agente
La salida del agente es bastante extensa:
los mensajes de error, el estado, la configuración y los datos de prueba se transmiten en varias secciones.
Estos últimos se pueden encontrar en la sección «robotmk_suite_execution_report»; aquí tienes un extracto abreviado:
<<<robotmk_suite_execution_report:sep(0)>>>
{
"attempts": [
{
"index": 1,
"outcome": "AllTestsPassed",
"runtime": 20
}
],
"rebot": {
"Ok": {
"xml": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n
<robot generator=\"Rebot 6.1.1 (Python 3.10.12 on win32)\"
generated=\"20240319 16:23:19.944\"
rpa=\"true\"
schemaversion=\"4\">\r\n<suite id=\"s1\"
name=\"Mybot\"
source=\"C:\\robots\\mybot\">\r\n<suite id=\"s1-s1\"
name=\"Tests\"
source=\"C:\\robots\\mybot\\tests.robot\">\r\n<test id=\"s1-s1-t1\"
name=\"Mytest\"
line=\"6\">\r\n<kw
name=\"Sleep\"
library=\"BuiltIn\">\r\n<arg>3 Seconds</arg>\r\n<doc>Pauses the test executed for the given time.</doc>\r\n<msg
timestamp=\"20240319 16:23:02.936\"
level=\"INFO\">Slept 3 seconds</msg>\r\n<status
status=\"PASS\"
starttime=\"20240319 16:23:00.934\"
endtime=\"20240319 16:23:02.936\"/>"
}
},
"suite_id": "mybot",
"timestamp": 1710861778
}
...
"html_base64":"PCFET0NUWVBFIGh0bWw+DQo8aHRtbCBsYW ...Hay dos áreas que revisten especial interés aquí.
En primer lugar, «rebot»: la herramienta «rebot» ha generado el informe de estado real de Robot Framework a partir de varios resultados parciales (de ahí «re-bot»).
En segundo lugar, la última línea «html_base64»: los informes HTML de Robot Framework se codifican entonces en base64.
Las capturas de pantalla tomadas durante las pruebas también se transfieren de esta manera; el volumen de salida/datos en el agente puede ser, en consecuencia, muy extenso.
Datos en la monitorización
En cuanto se hayan ejecutado el programador de Robotmk y el conjunto de pruebas, el descubrimiento de servicios generará tres nuevos servicios:
El servicio RMK Scheduler Status existe desde el momento de la distribución. Los servicios para planes y pruebas, en este caso RMK MyApplication_mybot Plan y RMK MyApplication_mybot Test: /Test: My Test, se añaden a la monitorización en cuanto se ejecutan por primera vez las suites asociadas.
2.2. Configuración de reglas de servicio
Crear una regla para el estado del plan
Recordatorio: Los tiempos de ejecución máximos para los planes se definieron en la regla del agente anterior. Estos tiempos de ejecución se pueden evaluar con la regla «Robotmk plan». Por ejemplo, puedes configurar el servicio en CRIT cuando se haya alcanzado el 90 % de todos los tiempos de espera calculados.
En la caja «Conditions» (Restringir a planes), existe la opción de restringir la regla a planes específicos.
Creación de una regla para el estado de la prueba
También se pueden recuperar datos adicionales para pruebas individuales en los conjuntos de pruebas a través de la regla «Robotmk test».
Aquí volverás a encontrar la opción de realizar la monitorización de los tiempos de ejecución, tanto para pruebas como para palabras clave.
La monitorización de palabras clave es una función específica de Checkmk.
Por lo tanto, el estado interno del conjunto de pruebas en el informe de Robot Framework también podría ser «OK» porque el conjunto de pruebas se procesó dentro del tiempo de ejecución máximo permitido; en Checkmk, sin embargo, sería «WARN» o «CRIT», porque se produce un cambio de estado, por ejemplo, al 80 % de este tiempo de ejecución máximo permitido.
Además, la opción «Enable metrics for high-level keywords» se puede utilizar para generar métricas para palabras clave de nivel superior. Esto resulta especialmente útil si tus pruebas están organizadas de tal manera que las palabras clave de nivel superior describen el «qué» y las de nivel inferior describen el «cómo», lo que te proporciona evaluaciones más abstractas.
En este ejemplo, los valores umbral para el tiempo de ejecución máximo de una prueba son 2 y 4 segundos. Verás los efectos más adelante en el capítulo Robotmk en la monitorización.
Una vez más, hay una opción de filtro explícita en la caja «Conditions», en este caso para pruebas individuales.
2.3. Robotmk en la monitorización
En la monitorización, encontrarás servicios para el estado del programador de Robotmk, así como los planes y pruebas individuales, incluso si no has creado ninguna regla de servicio por separado.
Estado del programador
El servicio RMK Scheduler Status está en estado «OK» si el programador está en ejecución y ha creado correctamente los entornos de ejecución.
Aquí, en la imagen, puedes ver la nota «Environment build took 1 second.»
¿Un segundo para crear un entorno virtual de Python con Pip y Robot Framework?
Esto es posible porque RCC es inteligente: los archivos que ya se han descargado se reutilizan y solo se lleva a cabo una nueva compilación después de que se hayan realizado cambios en conda.yaml.
La primera compilación habría tardado 30 segundos o más.
Estado del plan
El estado de un plan se refleja en un servicio cuyo nombre incluye el nombre de la aplicación y la suite, por ejemplo, RMK MyApplication_mybot Plan.
Estado de las pruebas
La evaluación de las pruebas es donde la cosa se pone realmente interesante.
En la imagen puedes ver ahora el efecto de los valores umbral establecidos anteriormente para el tiempo de ejecución de las pruebas —en este caso, los 2 segundos para el estado WARN.
Como la instrucción Sleep 3 Seconds en la propia prueba ya garantiza un tiempo de ejecución más largo, este servicio debe pasar a WARN aquí, aunque la prueba haya tenido éxito.
El hecho de que la prueba haya tenido éxito se muestra en el informe de Robot Framework, al que puedes acceder a través del icono de registro 
.
El informe muestra ahora claramente que la prueba y el conjunto de pruebas se han ejecutado correctamente.
En la parte inferior de los datos también puedes ver las palabras clave individuales, aquí por ejemplo Log ${MYVAR} junto con el valor My value establecido en Checkmk para MYVAR.
Dashboards
Por supuesto, puedes crear tus propios dashboards como de costumbre, pero también encontrarás dos dashboards integrados en Monitor > Synthetic Monitoring.
Requisito previo: para que los dashboards funcionen, el inventario de HW/SW debe estar activado en los hosts en cuestión.
3. Robots gestionados
Hasta ahora hemos supuesto un escenario en el que los conjuntos de pruebas ya están disponibles en los hosts de pruebas. Sin embargo, con la función «managed robots», los robots también se pueden gestionar de forma centralizada en el servidor Checkmk y distribuirse a través de los agentes Checkmk.
Por el procedimiento anterior ya conoces toda la configuración de los robots existentes que utilizan la regla «Robotmk scheduler (Windows|Linux)».
Además, solo tienes que introducir el archivo comprimido (ver más abajo) con el robot empaquetado. Aquí, en la captura de pantalla, en «Plan Settings » puedes ver el campo de carga para el robot: las mismas opciones que en el programador. Presta atención al nombre que aparece arriba, en «Properties. ». Es obligatorio, ya que el robot se configurará más tarde en el programador utilizando este nombre.
Para utilizar un robot gestionado de este tipo (Managed robot), se vuelve a utilizar la regla «Robotmk scheduler (Windows|Linux)». Pero en lugar de programar aquí la ejecución del robot, simplemente especifica el robot deseado y preconfigurado en «Sequence of plans». Si es necesario, aquí puedes seguir adaptando la configuración del plan para el robot preconfigurado para esta aplicación. En la práctica, por lo tanto, la función suele limitarse a externalizar la configuración conocida y a que el agente distribuya los archivos del robot.
A continuación, el agente transfiere los archivos especificados a los hosts deseados y los almacena en el directorio del agente en robomk_output/managed, donde se descomprimen y, finalmente, se ejecutan.
3.1. Creación de un archivo de robot
En principio, podrías simplemente archivar el directorio completo del robot con los archivos estándar (robot.yaml, conda.yaml, test.robot).
Sin embargo, estas pruebas suelen gestionarse a través de Git y, por lo tanto, a menudo hay archivos que no deben distribuirse; estos suelen gestionarse mediante un archivo gitignore.
Para ayudarte a garantizar que los archivos estén limpios, aquí tienes dos pequeños scripts para Windows y Linux que crean archivos sin los archivos que deben ignorarse.
Usa estos scripts solo como ayuda y comprueba siempre de antemano que funcionan en tu sistema.
- Windows
- Linux
4. Monitorización de los indicadores clave de rendimiento (KPI)
Ya has visto anteriormente que los tiempos de ejecución de las palabras clave de alto nivel se pueden supervisar como parte de una prueba.
Sin embargo, también puedes incluir cualquier palabra clave como servicio individual en la monitorización.
Esto resulta especialmente útil para palabras clave de usuario muy abstractas, que a su vez invocan varias palabras clave simples (estándar) como Click o Log; en otras palabras, estas se utilizan básicamente como funciones.
Hay dos variantes disponibles para el descubrimiento de servicios: los patrones en Checkmk y los marcadores en los conjuntos de pruebas.
Para el descubrimiento basado en patrones, las palabras clave deseadas se almacenan como expresiones regulares utilizando reglas de Checkmk.
Para el descubrimiento basado en marcadores, estos se codifican directamente delante de las palabras clave en las propias pruebas. Estos marcadores se procesan utilizando la biblioteca propia de Robotmk.
Independientemente de cómo entren los datos de las palabras clave en la monitorización, deben configurarse allí mediante la regla de servicio «Robotmk KPI monitoring».
4.1. Variante 1: Descubrimiento mediante patrones
Para esta variante, no necesitas realizar ningún cambio en tus propias pruebas. Simplemente abre la regla «Robotmk KPI discovery» e introduce las palabras clave que se van a realizar la monitorización como expresiones regulares o nombres muy específicos.
Precaución: Si la expresión regular coincide con más de una palabra clave en la misma prueba, solo se reconocerá una palabra clave y su estado de servicio será UNKNOWN (porque Checkmk no sabe qué coincidencia se pretende realmente).
4.2. Variante 2: Descubrimiento mediante marcador
Para un descubrimiento mediante marcador, debes seguir estos pasos:
Instala la biblioteca Robotmk.
Importa la biblioteca Robotmk a la suite.
Coloca la palabra clave «marker» delante de las palabras clave relevantes.
Para la instalación, hay que ampliar el archivo «conda.yaml» anterior con «robotframework-robotmklibrary».
Las modificaciones respecto a la suite anterior están resaltadas en amarillo:
El conjunto de pruebas tests.robot debe ampliarse con la biblioteca (en el área Settings) y un marcador.
Los KPI suelen hacer referencia a palabras clave de usuarios individuales, por lo que aquí se añade la palabra clave Foobar (que solo llama a la palabra clave estándar Log y, a su vez, es llamada por el caso de prueba My Test).
*** Settings ***
Documentation Template robot main suite.
Library RobotmkLibrary
*** Variables ***
${MYVAR} Hello Checkmk!
*** Test Cases ***
My Test
Log ${MYVAR}
Sleep 3
Log Done.
Monitor Subsequent Keyword Runtime discover_as=My user keyword
Foobar
*** Keywords ***
Foobar
Log The foo barred!
La palabra clave de Robotmk Monitor Subsequent Keyword Runtime es el marcador para (activar Checkmk y que) supervise la siguiente palabra clave (Foobar); más concretamente, su tiempo de ejecución.
El argumento opcional discover_as se puede usar para especificar un nombre individual para el servicio en la monitorización; por lo tanto, la palabra clave Foobar aparece en la monitorización como un servicio llamado My user keyword.
La gran ventaja aquí, en comparación con el descubrimiento basado en patrones, es que la misma palabra clave también se puede realizar su monitorización explícita varias veces dentro de una misma prueba.
Aquí tienes el ejemplo anterior, ampliado con dos llamadas a Foobar:
*** Settings ***
Documentation Template robot main suite.
Library RobotmkLibrary
*** Variables ***
${MYVAR} Hello Checkmk!
*** Test Cases ***
My Test
Log ${MYVAR}
Sleep 3
Log Done.
Monitor Subsequent Keyword Runtime discover_as=My user keyword
Foobar
Monitor Subsequent Keyword Runtime discover_as=Foobar_2
Foobar
Monitor Subsequent Keyword Runtime discover_as=Foobar_3
Foobar
*** Keywords ***
Foobar
Sleep 3
Log The foo barred!Las tres llamadas a la palabra clave Foobar aparecerían, por lo tanto, en la monitorización como My user keyword, Foobar_2 y Foobar_3.
4.3. Configuración de la regla de servicio
Independientemente de cuál de las dos variantes de las palabras clave se utilice para la monitorización, el siguiente paso es siempre configurar la evaluación: ¿En qué momento de la ejecución deben los servicios ir a WARN o CRIT? Para ello, define los niveles correspondientes en la regla Robotmk KPI monitoring.
4.4. Palabras clave en la monitorización
Las palabras clave de los servicios aparecen en la monitorización siguiendo uno de estos dos patrones:
Basado en patrones: RMK MyApplication_mybot Test: /Test: My Test KPI (cmk): Foobar
Basado en marcadores: RMK MyApplication_mybot Test: /Test: My Test KPI (rf): Foobar
La diferencia está, por lo tanto, solo en la indicación del origen entre paréntesis justo antes de la palabra clave.
Como se muestra en la captura de pantalla anterior con dos servicios de palabras clave Foobar, fue necesario ampliar un poco la suite:
*** Settings ***
Documentation Template robot main suite.
Library RobotmkLibrary
*** Variables ***
${MYVAR} Hello Checkmk!
*** Test Cases ***
My Test
Log ${MYVAR}
Sleep 3
Log Done.
Foobar
Monitor Subsequent Keyword Runtime discover_as=Foobar
Barfoo
*** Keywords ***
Foobar
Sleep 3
Log The foo barred!
Barfoo
Sleep 11
Log The End of Barfoo
Las dos palabras clave Foobar y Barfoo aparecen ambas bajo el nombre Foobar en la monitorización, pero se pueden distinguir por la indicación del origen entre paréntesis.
El ejemplo con dos palabras clave diferentes que aparecen en una lista bajo el mismo nombre sirve principalmente para aclarar la información de origen.
Como ya se ha mencionado anteriormente, el objetivo real de discover_as es poder llamar a una palabra clave varias veces en una prueba, pero nombrando cada aparición de forma individual.
5. Modo sin conexión para entornos de prueba/RCC
Por defecto, RCC se encarga de configurar los entornos leyendo la configuración YAML y descargando los paquetes y dependencias correspondientes de la red.
Pero, ¿qué pasa si los hosts en los que se van a ejecutar las pruebas no tienen acceso a internet o este es muy limitado?
Checkmk, o más concretamente el programador Robotmk, puede ayudarte en este caso, ya que permite crear entornos RCC sin necesidad de una conexión directa a internet. En resumen: los entornos se crean por adelantado en cualquier ordenador y luego se distribuyen a través de un archivo ZIP o desde un servidor remoto.
Sigue leyendo para descubrir exactamente cómo funcionan estos dos métodos. Sin embargo, se necesitan algunos conocimientos sobre RCC para entenderlo —y tenemos que dar algunos detalles—: por un lado, para explicar los aspectos técnicos internos de RCC y, por otro, para explicar por qué en este contexto concreto no seguimos nuestra práctica habitual de remitirnos al fabricante.
5.1. RCC: una breve digresión
Historial de RCC
¿De dónde viene la herramienta? RCC fue desarrollado originalmente por la empresa Robocorp (hoy en día Sema4.ai). El modelo de negocio de Sema4.ai es una plataforma basada en la nube en la que los clientes pueden ejecutar sus propios scripts para automatizar procesos de negocio. RCC constituye la base para crear exactamente los mismos entornos virtuales tanto localmente en las instalaciones del cliente como en la nube.
En Checkmk usamos RCC para un caso de uso diferente: aquí, tus scripts de Robot Framework deberían poder ejecutarse tanto en tu ordenador local (de desarrollo) como en los hosts de prueba de Robotmk (Windows o Linux).
Durante la adquisición de Robocorp por parte de Sema4.ai en 2024, se renovó la licencia de RCC y ahora es software propietario. Lamentablemente, este proceso no fue muy transparente, de ahí esta breve explicación.
La variante que se entrega con Checkmk se basa en la última versión abierta de RCC y la mantenemos nosotros. Por lo tanto, la bifurcación de RCC es ahora parte integral de Checkmk y también está documentada aquí, en la medida en que sea relevante para su uso en Checkmk.
La cosa se complica un poco con el servidor remoto de RCC, la herramienta que se encarga de distribuir los entornos de RCC. Se trata simplemente de un componente de RCC que solo se crea durante la compilación, no es un producto en sí mismo. Por eso nunca ha habido documentación real de Robocorp, aparte de una aplicación muy específica para la plataforma de Robocorp.
Funcionamiento interno de RCC
Deberías estar familiarizado con algunos términos y conceptos para poder entenderlos:
| Término | Explicación | Nota |
|---|---|---|
Catálogo |
Plantilla para entornos |
Plantillas para crear entornos virtuales |
Hololib |
Colección de catálogos disponibles |
Hololib es un repositorio de planos donde cada archivo único se almacena solo una vez, y se puede usar para crear varios Espacios. |
Espacio |
Instancia de un entorno |
Se pueden crear varios Espacios a partir de un mismo catálogo |
Holotree (compartido) |
Colección de espacios disponibles |
Holotree (compartido) es un almacén de espacios, en el que cada archivo único se guarda solo una vez y está disponible para varios espacios. |
|
Variable del entorno |
Ruta donde RCC almacena Hololib y Holotree; por defecto, |
|
Variante segura con acceso de escritura limitado |
Ruta en la que Checkmk-RCC almacena Hololib y Holotree; debajo de |
Ruta de Holotree |
Ruta absoluta, debajo de |
En esta ruta, los planos de Hololib se compilan en espacios de Holotree; debe ser idéntica en el ordenador de origen y en el de destino dentro de un entorno. |
RCCRemote |
Servidor para el suministro de catálogos. |
Normalmente se opera a través del contenedor Docker RCCRemote. |
ROBOCORP_HOME
ROBOCORP_HOME requiere un análisis más detallado.
Esta variable del entorno define la ruta de archivo en la que RCC guarda Hololib y Holotree.
Todos los archivos binarios dentro de Hololib, es decir, la colección de plantillas, se compilan en una ruta absoluta: la denominada holotree path, una subcarpeta de ROBOCORP_HOME.
Esto también significa que las mismas rutas de archivo deben estar disponibles en los hosts de prueba en los que se ejecutarán posteriormente los robots, al igual que en el ordenador en el que creas los robots.
También es relevante en este proceso: el contexto de usuario.
En Windows, el programador de Robotmk se ejecuta por defecto como un subproceso del agente Checkmk bajo la cuenta LocalSystem (en el contexto SYSTEM).
En Linux, el programador se ejecuta bajo el mismo usuario que el agente Checkmk, es decir, root.
Si ahora se van a cambiar los contextos de usuario, Windows y Linux se comportarán de forma diferente.
Windows: El usuario del programador, SYSTEM, no se puede cambiar, pero se puede usar la opción Execute plan as a specific user para configurar un usuario para la ejecución de robots o planes individuales.
Linux: La regla Customize agent package (Unix) y su opción Customize user se pueden usar para cambiar el usuario del agente; sin embargo, no es posible ejecutar robots/planes individuales en otros contextos.
En Checkmk, el programador Robotmk se permite una medida de seguridad adicional para RCC:
Para garantizar que solo los programadores y los usuarios configurados manualmente tengan realmente acceso de escritura a ROBOCORP_HOME, aquí hay que definir una ruta de archivo muy específica —según la tabla anterior más un nivel jerárquico adicional para el contexto de usuario deseado (mira más abajo cómo se ve esto en la práctica).
Esto evita que archivos maliciosos se cuelen en Hololib/Holotree, es decir, la inyección de código (en pocas palabras: si ROBOCORP_HOME en la máquina de desarrollo se configurara como algo así como C:\foobar y si este directorio ya existiera en los hosts de prueba y contuviera malware, este podría ejecutarse).
5.2. Variante 1: archivos ZIP
La práctica es mucho más sencilla que los fundamentos técnicos, especialmente cuando se trabaja con un catálogo como archivo ZIP (o archivo tar.gz en Linux).
Básicamente, solo tienes que crear el catálogo especificando la variable ROBOCORP_HOME, exportarlo como archivo y luego distribuirlo manualmente.
A continuación se detalla el proceso.
Las rutas de los siguientes ejemplos se limitan a Windows; solo se especificarán explícitamente los comandos diferentes para Linux si este los requiere.
Establece ROBOCORP_HOME
El catálogo, es decir, la plantilla para entornos (espacios) implementados explícitamente, se puede crear en cualquier ordenador.
Primero, configura ROBOCORP_HOME en el terminal.
En Windows:
Para la ejecución sin interfaz gráfica con la cuenta LocalSystem:
Para robots que necesitan acceso al escritorio y un usuario correspondiente:
En Linux:
Para la ejecución sin interfaz gráfica como usuario estándar:
Para los robots que necesitan acceso al escritorio y un usuario correspondiente:
A continuación, puedes entrar en el directorio de tu bot y crear el entorno/catálogo:
Creación del catálogo ZIP
Ahora hay que exportar el catálogo como un ZIP.
Primero check si ya existe un catálogo Hololib con la ruta correcta del archivo Holotree.
Para ello, necesitas el hash de conda.yaml:
A continuación, muestra todos los catálogos Hololib disponibles (aquí se muestra una versión resumida):
Cuando encuentres el hash en la lista, puedes exportar:
Distribución del catálogo ZIP
El catálogo comprimido es fácil de distribuir:
Copia el archivo manualmente al host de prueba, por ejemplo, a C:\robotmk\holotrees\myrobot-env.zip.
En la regla Robotmk Scheduler (Windows|Linux) (o en Managed robots), configura la opción «Environment dependency handling» en «Load from ZIP file» e introduce la ruta de archivo deseada al catálogo comprimido, en este caso C:\robotmk\holotrees\myrobot-env.zip.
¡No confundas esta ruta con holotree path!
Esto solo sirve como repositorio para los archivos ZIP del catálogo Hololib que se van a importar.
Cuando se inicie el programador más adelante, importará todos los archivos ZIP de los catálogos de Hololib y creará los espacios a partir de estas plantillas, es decir, los entornos que realmente se van a utilizar. Así que, en lugar de descargar todas las dependencias a través de pip y Conda desde internet, solo se descomprime un archivo, lo cual no solo es offline, sino que también es mucho más rápido.
Y para evitar cualquier malentendido —los propios robots, por supuesto, deben seguir estando disponibles en el host de pruebas o distribuidos como robots gestionados—, ¡esto se refiere exclusivamente a los entornos!
5.3. Variante 2: servidor RCCRemote
Antes que nada: RCCRemote no es una herramienta independiente, no encontrarás ninguna documentación ni siquiera una página de producto de Robocorp/Sema4. El servidor remoto es simplemente una parte de RCC y se crea al compilar RCC. El servidor suele funcionar a través de un contenedor. Para el funcionamiento en contenedor, ahora hay un proyecto en las páginas de GitHub de Elabit, el desarrollador del Plugin Robotmk original, llamado RCCRemote-Docker. Sin embargo, RCCRemote y RCCRemote-Docker no forman parte de Checkmk Synthetic Monitoring y no están cubiertos por el soporte técnico de Checkmk.
Los catálogos para esta ruta de distribución se pueden crear de dos maneras: los catálogos exportados como archivos ZIP (véase más arriba) se pueden usar tanto en Windows como en Linux. Solo para Linux, también es posible crear los catálogos directamente en el contenedor Docker RCCRemote, lo que elimina por completo la necesidad de intervención manual.
Puedes averiguar cómo configurar RCCRemote-Docker, manejar certificados e importar catálogos en las páginas del proyecto.
La configuración por parte de Checkmk vuelve a ser, como es habitual, bastante sencilla: la opción «Environment dependency handling» se establece esta vez en «Fetch from RCC remote server» y se le proporciona la dirección del servidor.
Aún falta un último ajuste, dependiendo de si tu servidor RCCRemote utiliza un certificado autofirmado o firmado por una CA. En ambos casos, normalmente tienes que configurar la opción «Robotmk scheduler (Windows|Linux)» de RCC profile configuration a Custom profile.
Para un certificado autofirmado, basta con dejar la caja «Validate TLS certificates» sin marcar:
Sin embargo, si se trata de un certificado firmado por una CA, esta opción debe estar activada y el certificado de la autoridad de firma debe guardarse en Root CA (en formato PEM):
6. Solución de problemas
6.1. El programador de informes informa de un error «No Data
»
Si el programador no recibe ningún dato, es probable que la creación del entorno no haya funcionado.
Una causa habitual de esto son los problemas de red, por ejemplo, que impiden cargar ciertas dependencias.
En este caso, echa un vistazo al archivo de registro correspondiente en C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.
6.2. Fallo en la creación del entorno:post-install script execution
Este es un error especialmente interesante con el que te puedes encontrar en sistemas Windows recién instalados.
El archivo conda.yaml también puede contener instrucciones que deben ejecutarse tras la instalación de las dependencias, por ejemplo, la inicialización del navegador de Robot Framework.
Por lo tanto, aquí deben ejecutarse comandos de Python.
Por defecto, Windows 11 tiene alias para python.exe y python3.exe que remiten a la Tienda de Microsoft.
Debes desactivar estos alias en «Configuración/Alias para la ejecución de aplicaciones».
7. Archivos y directorios
7.1. Windows
| Ruta del archivo | Descripción |
|---|---|
|
Archivos de registro y resultados de las suites |
|
Archivos de registro para la creación de entornos virtuales |
|
Mensajes de la ejecución de RCC |
|
Archivo de registro del plugin de agente |
|
|
|
Plugin de agente |
7.2. Linux
| Ruta del archivo | Descripción |
|---|---|
|
Archivos de registro y resultados de las suites |
|
Archivos de registro para la creación de entornos virtuales |
|
Mensajes de la ejecución de RCC |
|
|
|
|
|
Ubicación de ejecución de los robots gestionados |
|
Ubicación de almacenamiento de los archivos de los robots gestionados |
Atención: En Linux, el programador Robotmk no crea su propio archivo de registro (en Windows es el robotmk_scheduler_rCURRENT.log), sino que registra a través del agente y syslog.
El comando correspondiente: