Monitorización sintética de Checkmk con Robotmk

Múltiples componentes trabajan juntos para crear esta monitorización de extremo a extremo, por lo que a continuación te ofrecemos una breve visión general.

Puedes encontrar el programador de Robotmk en Setup > Agent rules > Robotmk scheduler (Windows). Como la regla es bastante extensa, a continuación te mostramos 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.

El Parallel plan groups que se muestra ahora es un concepto específico de Checkmk.

Para explicarlo, primero debemos descender un nivel jerárquico: aquí puedes ver el item Sequential plans. Un plan secuencial de este tipo define qué suites deben ejecutarse con qué parámetros. Robot Framework procesará estas suites una tras otra. La razón de esto es sencilla: en la práctica, las pruebas se ejecutan a veces en el escritorio y varias suites de pruebas podrían estorbarse entre sí al mismo tiempo (piensa que se roban mutuamente el control del puntero del ratón).

Los grupos de planes son ahora una encapsulación para los planes ejecutados secuencialmente, y ellos mismos se ejecutan en paralelo. De nuevo, el razonamiento es sencillo: esto permite que los conjuntos de pruebas que no dependen del escritorio se ejecuten en sus propios planes sin demora -el conjunto de pruebas utilizado en este artículo es un buen ejemplo de dicho proceso.

Volvamos al diálogo: El único ajuste explícito es el intervalo de ejecución, que estableces en Group execution interval.

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 el nombre de la aplicación que se va a monitorizar, por ejemplo OnlineShop, o aquí en este ejemplo simplemente MyApplication. Por supuesto, puede ocurrir que esta tienda online sea probada varias veces, ya sea por otros conjuntos de pruebas o por el mismo conjunto de pruebas con diferentes parámetros. En tales casos, el campo Variant se utiliza para obtener resultados inequívocos a pesar de que los nombres sean idénticos. Por ejemplo, si la aplicación OnlineShop se prueba una vez en alemán y otra en inglés (mediante parámetros correspondientes), podrías utilizar aquí las abreviaturas correspondientes. La monitorización devolverá entonces resultados para My OnlineShop_en y My OnlineShop_de.

Sin embargo, es necesario especificar Relative path to test suite file or folder. La ruta es relativa al directorio base especificado anteriormente, por ejemplo mybot\test.robot para C:\robots\. También se puede especificar aquí un directorio (con varios archivos robot ), en cuyo caso sería simplemente mybot.

Continúa con Execution configuration.En Limit per attempt defines el tiempo máximo transcurrido -por intento- que puede ejecutarse un conjunto de pruebas. Con Robot Framework re-executions puedes indicar ahora a Robot Framework que repita los conjuntos de pruebas por completo o de forma incremental si las pruebas fallan. Si las pruebas individuales de un conjunto de pruebas son independientes entre sí, la estrategia incremental es la mejor forma de ahorrar tiempo. Si, por el contrario, el conjunto de pruebas comprueba una secuencia lógica, como "Inicio de sesión → Llamar a la página del producto → Producto en la cesta de la compra → Pago", el conjunto de pruebas debe, por supuesto, volver a procesarse por completo. Al final, siempre hay un único resultado.

En caso de reintentos completos, para el resultado final sólo se tienen en cuenta los resultados de las suites autónomas: Si una prueba falla en su último reintento, el conjunto de pruebas se cuenta como un fracaso. En el caso de los reintentos incrementales, el resultado final se compone de los mejores resultados parciales: Si algunas pruebas sólo 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 a través de RCC se activa en Automated environment setup (via RCC), para lo que debes introducir dos valores. En primer lugar, RCC requiere que se especifique dónde se encuentra el archivo robot.yaml. Su finalidad principal es hacer referencia al archivo conda.yaml, que se encarga de configurar el entorno de Python, es decir instalar Python y las 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 pueden guardarse en subdirectorios, pero la mejor práctica es el directorio superior de la suite. Para el directorio base anterior C:\robot\ y el directorio de la suite C:\robot\mybot es en consecuencia mybot\robot.yaml.

Con el siguiente límite de tiempo para construir el entorno Python, debes tener en cuenta que a veces es necesario descargar y configurar grandes volúmenes de datos. Especialmente para los navegadores necesarios, se acumulan rápidamente varios cientos de megabytes, pero sólo para la primera ejecución. RCC sólo reconstruye los entornos si el contenido de conda.yaml ha cambiado.

En Robot Framework parameters tienes la posibilidad de utilizar algunos de los parámetros de la línea de comandos de Robot Framework (que también se muestran con el comando robot --help). Si quieres utilizar parámetros adicionales, te ayudará la opción Argument files. Un archivo especificado aquí puede contener cualquier parámetro del robot. Puedes encontrar más información sobre los parámetros individuales en la ayuda en línea.

Para nuestro proyecto de ejemplo, sólo se activa la opción Variables y se establece una variable MYVAR con el valor My Value. ¿Recuerdas el comando Log ${MYVAR} en la parte superior del archivo tests.robot? Ésta es la referencia correspondiente.

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, en consecuencia, tiene acceso a las aplicaciones gráficas del escritorio.

Con Assign plan/test result to piggyback host, los resultados del plan/prueba pueden asignarse a otro host. Por ejemplo, si Robot Framework está probando el proceso de pedido de una tienda online, los resultados pueden asignarse al servidor web correspondiente.

Cada ejecución de prueba produce 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 suites de pruebas más complejas y capturas de pantalla incrustadas, por ejemplo, esto puede sumar rápidamente varios megabytes de datos. Dependiendo del intervalo de ejecución, del tamaño del informe y de tus requisitos de documentación, debes intervenir en tal situación.

Una vez aquí, ahora 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 planificador Robotmk.

RCC profile configuration te permite especificar los servidores proxy y hosts que deben excluirse.

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 debe fallar. El inicio puede retrasarse manualmente mediante un periodo de gracia.

Esto completa la configuración y puedes crear un nuevo agente con el Plugin y luego desplegarlo, manualmente o mediante las actualizaciones automáticas del agente.

En la monitorización, encontrarás servicios para el estado del programador de Robotmk, así como para los planes y pruebas individuales, aunque no hayas creado ninguna regla de servicio por separado.

Si el programador no recibe ningún dato, es probable que la construcción del entorno no haya funcionado. Una razón común para ello son los problemas de red, por ejemplo, debido a los cuales no se pueden cargar determinadas dependencias. En este caso, echa un vistazo al archivo de registro correspondiente en C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.

Este es un error especialmente interesante que puedes encontrar en sistemas Windows nuevos. El conda.yaml también puede contener instrucciones que deben ejecutarse después de la instalación de las dependencias, por ejemplo, la inicialización del navegador Robot Framework. Por tanto, aquí deben ejecutarse los comandos de Python. Por defecto, Windows 11 tiene alias para python.exe y python3.exe que remiten a la Tienda Microsoft. Debes desactivar estos alias en "Configuración/Alias para la ejecución de apps".