Supervision synthétique avec Robotmk

Plusieurs composants fonctionnent ensemble pour créer cette supervision de bout en bout ; en voici donc un bref aperçu.

Vous trouverez le planificateur Robotmk sous Setup > Agent rules > Robotmk scheduler (Windows). La règle étant assez complète, voici un aperçu de la configuration vide :

Tout d'abord, le planificateur a besoin du répertoire de base dans lequel se trouvent toutes vos suites de tests. Saisissez ce chemin d'accès explicite et arbitraire sous Base directory of suites, par exemple C:\robots.

Les « Parallel plan groups » qui s’affichent actuellement constituent un concept propre à Checkmk.

Pour l'expliquer, nous devons d'abord descendre d'un niveau dans la hiérarchie : vous pouvez voir ici l'élément « Sequential plans ». Un tel plan séquentiel définit quelles suites doivent être exécutées avec quels paramètres. Robot Framework traitera ces suites l’une après l’autre. La raison en est simple : dans la pratique, les tests sont parfois exécutés sur le bureau et plusieurs suites de tests pourraient se gêner mutuellement en même temps (imaginez qu’elles se disputent le contrôle du pointeur de la souris).

Les groupes de plans constituent désormais une encapsulation pour les plans exécutés séquentiellement — et sont eux-mêmes exécutés en parallèle. Là encore, le raisonnement est simple : cela permet aux suites de tests qui ne dépendent pas du bureau d’être exécutées dans leurs propres plans sans délai — la suite de tests utilisée dans cet article est un bon exemple d’un tel processus.

Revenons au dialogue : le seul paramètre explicite est l'intervalle d'exécution, que vous définissez sous « Group execution interval ».

Il est maintenant temps de configurer le premier plan. Vous pouvez saisir n’importe quel nom sous « Application name ». Ce nom n’a pas besoin d’être unique ! Le nom de l’application soumise à la supervision est tout à fait approprié ici, par exemple « OnlineShop », ou simplement « MyApplication » dans cet exemple. Bien sûr, il peut arriver que cette boutique en ligne soit testée plusieurs fois, soit par d’autres suites de tests, soit par la même suite de tests avec des paramètres différents. Dans de tels cas, le champ « Variant » (Nom de l’application) est utilisé pour obtenir des résultats sans ambiguïté malgré des noms identiques. Par exemple, si l’application OnlineShop est testée une fois en allemand et une fois en anglais (via les paramètres correspondants), vous pourriez utiliser ici les abréviations correspondantes. La supervision renverra alors des résultats pour My OnlineShop_en et My OnlineShop_de.

Toutefois, la spécification sous Relative path to test suite file or folder est nécessaire. Le chemin d'accès est relatif au répertoire de base spécifié ci-dessus, par exemple mybot\test.robot pour C:\robots\. Il est également possible de spécifier ici un répertoire (contenant plusieurs fichiers robot), auquel cas il s'agirait simplement de mybot.

Poursuivez avec l’option « Execution configuration. » Sous « Limit per attempt », vous définissez la durée maximale — par tentative — pendant laquelle une suite de tests peut s’exécuter. Avec « Robot Framework re-executions », vous pouvez désormais demander à Robot Framework de répéter les suites de tests dans leur intégralité ou de manière incrémentielle si les tests échouent. Si les tests individuels d’une suite de tests sont indépendants les uns des autres, la stratégie incrémentielle est le meilleur moyen de gagner du temps. Si, en revanche, la suite de tests vérifie une séquence logique, telle que « Login > Affichage de la page produit > Ajout du produit au panier > Paiement », la suite de tests doit bien sûr être entièrement réexécutée. Au final, il n’y a toujours qu’un seul résultat.

Dans le cas de nouvelles tentatives complètes, seuls les résultats des suites autonomes sont pris en compte pour le résultat final : si un test échoue lors de sa dernière nouvelle tentative, la suite de tests est considérée comme un échec. Dans le cas de réessais incrémentiels, le résultat final est constitué des meilleurs résultats partiels : si certains tests ne s’exécutent avec succès qu’à la troisième tentative, le résultat final est également considéré comme un succès. Rappel : la combinaison des tentatives et des durées d’exécution maximales de tous les plans d’un groupe de plans détermine leur intervalle d’exécution minimal.

Par défaut, l'exécution via RCC est activée sous Automated environment setup (via RCC), pour laquelle vous devez saisir deux valeurs. Tout d'abord, RCC nécessite de spécifier l'emplacement du fichier d'robot.yaml. Son objectif principal est de référencer le fichier conda.yaml, qui est chargé de configurer l'environnement Python, c'est-à-dire d'installer Python et ses dépendances. Cette spécification est relative au répertoire de base que vous avez défini ci-dessus sous Relative path to test suite file or folder. Les fichiers YAML peuvent être enregistrés dans des sous-répertoires, mais la meilleure pratique consiste à les placer dans le répertoire supérieur de la suite. Pour le répertoire de base C:\robot\ et le répertoire de la suite C:\robot\mybot mentionnés ci-dessus, l'emplacement correspondant est donc mybot\robot.yaml.

Compte tenu de la limite de temps suivante pour la création de l'environnement Python, vous devez garder à l'esprit que des volumes importants de données doivent parfois être téléchargés et configurés. En particulier pour les navigateurs requis, plusieurs centaines de mégaoctets s'accumulent rapidement — mais uniquement lors de la première exécution. RCC ne recrée les environnements que si le contenu de conda.yaml a changé.

Sous Robot Framework parameters, vous avez la possibilité d’utiliser certains des paramètres de ligne de commande de Robot Framework (qui sont également affichés par l’instruction robot --help). Si vous souhaitez utiliser des paramètres supplémentaires, l’option Argument files vous sera utile. Un fichier spécifié ici peut contenir n’importe quel paramètre de robot. Vous trouverez de plus amples informations sur les différents paramètres dans l’aide en ligne.

Pour notre projet d'exemple, seule l'option Variables est activée et une variable MYVAR est définie avec la valeur My Value. Vous vous souvenez de l'instruction Log ${MYVAR} en haut du fichier tests.robot ? Il s'agit de la référence correspondante.

L'option Secret environment variables mérite une attention particulière, car il ne s'agit pas d'une fonction native de Robot Framework. Vous pouvez définir ici des variables d'environnement secrètes, destinées aux mots de passe en association avec la bibliothèque Robot Framework CryptoLibrary. Les variables définies ici n'apparaissent pas dans les journaux, mais sont écrites en texte clair dans les fichiers de configuration Checkmk sur les ordinateurs hôtes respectifs.

À la fin de la configuration de la suite, trois options s’offrent à vous, dont la signification est en grande partie évidente.

Execute plan as a specific user Permet d’exécuter Robotmk dans le contexte d’un compte utilisateur spécifique. Contexte : par défaut, Robotmk est exécuté dans le contexte de l’agent Checkmk (compte LocalSystem), qui ne dispose d’aucune autorisation pour accéder au bureau. Vous pouvez ici spécifier un utilisateur qui doit être connecté en permanence à une session de bureau et qui dispose donc d’un accès aux applications graphiques du bureau.

Cependant, ne vous précipitez pas : les navigateurs constituent ici une exception ! Ils peuvent s’exécuter et afficher des pages web en mode sans interface graphique. Vous ne devriez checker la case pour un utilisateur spécifique que si une application de bureau dédiée est lancée en dehors des navigateurs — notamment pour des raisons de sécurité.

Avec Assign plan/test result to piggyback host, les résultats du plan/test peuvent être attribués à un autre ordinateur hôte. Par exemple, si Robot Framework teste le processus de commande d’une boutique en ligne, les résultats peuvent être attribués au serveur web correspondant.

Chaque exécution de test produit des données qui sont stockées sous C:\ProgramData\checkmk\agent\robotmk_output\working\suites\. Par défaut, les résultats des 14 derniers jours sont conservés, mais vous devez garder à l’esprit que de grands volumes de données peuvent rapidement s’accumuler ici. Au moins 500 kilo-octets de données sont générés par exécution — avec des suites de tests plus complexes et des captures d'écran intégrées, par exemple, cela peut rapidement représenter plusieurs mégaoctets de données. En fonction de l'intervalle d'exécution, de la taille du rapport et de vos exigences en matière de documentation, vous devriez intervenir dans une telle situation.

Une fois ici, vous pouvez désormais créer d'autres plans dans ce groupe de plans ou d'autres groupes de plans.

À la fin, deux options supplémentaires s’offrent à vous, qui concernent la configuration complète du planificateur Robotmk.

RCC profile configuration vous permet de spécifier les serveurs proxy et les ordinateurs hôtes à exclure.

Grace period before scheduler starts peut également s’avérer très utile : le planificateur démarre en même temps que l’agent Checkmk avant la connexion au bureau — ce qui, bien sûr, signifie que tout test sur le bureau échouera. Le démarrage peut être retardé manuellement à l’aide d’un délai de grâce.

La configuration est maintenant terminée et vous pouvez créer un nouvel agent à l’aide du plugin, puis le déployer, manuellement ou via les mises à jour automatiques des agents.

Dans la supervision, vous trouverez des services pour l'état du planificateur Robotmk ainsi que pour les plans et tests individuels, même si vous n'avez créé aucune règle de service distincte.

En principe, vous pourriez simplement archiver le répertoire complet du robot avec les fichiers standard (robot.yaml, conda.yaml, test.robot).

Cependant, ces tests sont souvent gérés via Git et, par conséquent, il existe régulièrement des fichiers qui ne doivent pas être distribués — ceux-ci sont généralement gérés via un fichier gitignore. Pour vous aider à garantir des archives propres, voici deux petits scripts pour Windows et Linux qui créent des archives sans les fichiers à ignorer. Utilisez ces scripts uniquement à titre d’aide et testez toujours au préalable le fonctionnement sur votre système.

Pour cette variante, vous n’avez pas besoin d’apporter de modifications à vos tests eux-mêmes. Il vous suffit d’ouvrir la règle « Robotmk KPI discovery » et de saisir les mots-clés à superviser sous forme d’expressions régulières ou de noms très spécifiques.

Attention : si l'expression régulière correspond à plusieurs mots-clés dans le même test, un seul mot-clé sera reconnu et son statut de service sera UNKNOWN (car Checkmk ne sait pas quelle correspondance est réellement souhaitée).

Pour une identification via un marqueur, vous devez suivre les étapes suivantes :

Pour l'installation, le fichier « conda.yaml » ci-dessus doit être complété par « robotframework-robotmklibrary ». Les modifications par rapport à la suite ci-dessus sont surlignées en jaune :

La suite de tests tests.robot doit être complétée par la bibliothèque (dans la zone Settings) et un marqueur. Les KPI font souvent référence à des mots-clés d'utilisateurs individuels ; c'est pourquoi le mot-clé Foobar est ajouté ici (qui n'appelle que le mot-clé standard Log et est lui-même appelé par le cas de test My Test).

Le mot-clé Robotmk Monitor Subsequent Keyword Runtime sert de marqueur pour (déclencher Checkmk afin de) surveiller le mot-clé suivant (Foobar) ; plus précisément, son temps d'exécution. L'argument facultatif discover_as permet de spécifier un nom individuel pour le service dans la supervision — le mot-clé Foobar apparaît donc dans la supervision sous la forme d'un service appelé My user keyword.

Le grand avantage ici par rapport à l’identification basée sur des modèles est que le même mot-clé peut également faire l’objet d’une supervision explicite plusieurs fois au sein d’un même test.

Voici l’exemple ci-dessus, complété par deux appels à Foobar :

Les trois appels au mot-clé Foobar apparaîtraient donc dans la supervision sous la forme My user keyword, Foobar_2 et Foobar_3.

Quelle que soit la variante utilisée pour la supervision des mots-clés, l'étape suivante consiste toujours à configurer l'évaluation : À quel moment d'exécution les services doivent-ils être redirigés vers WARN ou CRIT ? Pour ce faire, définissez les niveaux correspondants dans la règle Robotmk KPI monitoring.

Les services de mots-clés apparaissent dans la supervision selon l'un de ces deux modèles :

La différence réside donc uniquement dans l'indication de l'origine entre parenthèses, juste avant le mot-clé.

Comme le montre la capture d'écran ci-dessus avec deux services de mots-clés Foobar, la suite a dû être légèrement étendue :

Les deux mots-clés Foobar et Barfoo apparaissent tous deux sous le nom Foobar dans la supervision, mais peuvent être distingués par l'indication de l'origine entre parenthèses.

L'exemple avec deux mots-clés différents sur une liste sous le même nom sert principalement à clarifier les informations d'origine.

Comme déjà mentionné ci-dessus, l'objectif réel de « discover_as » est de pouvoir appeler un mot-clé plusieurs fois dans un test tout en nommant chaque occurrence individuellement.

La pratique est bien plus simple que le contexte technique — en particulier lorsque l’on travaille avec un catalogue sous forme d’archive ZIP (ou d’archive tar.gz sous Linux). En gros, il suffit de créer le catalogue en spécifiant la variable ROBOCORP_HOME, de l’exporter sous forme d’archive, puis de le distribuer manuellement. Vous trouverez ci-dessous le chemin d’accès détaillé. Les chemins d’accès dans les exemples suivants sont limités à Windows — ces instructions ne seront spécifiées explicitement que si Linux nécessite des instructions différentes.

Tout d’abord : RCCRemote n’est pas un outil autonome, vous ne trouverez aucune documentation ni même de page produit chez Robocorp/Sema4. Le serveur distant n’est qu’une partie de RCC et est intégré lors de la compilation de RCC. Le serveur est généralement exploité via un conteneur. Pour l’exploitation en conteneur, il existe désormais un projet sur les pages GitHub d’Elabit, le développeur du plugin Robotmk d’origine, appelé RCCRemote-Docker. Cependant, RCCRemote et RCCRemote-Docker ne font pas partie de Checkmk Synthetic Monitoring et ne sont pas couverts par le support Checkmk !

Les catalogues pour ce chemin d'accès peuvent être créés de deux manières : les catalogues exportés sous forme de fichiers ZIP (voir ci-dessus) peuvent être utilisés aussi bien sous Windows que sous Linux. Sous Linux uniquement, il est également possible de créer les catalogues directement dans le conteneur Docker RCCRemote, ce qui élimine complètement toute intervention manuelle.

Vous trouverez des informations sur la configuration de RCCRemote-Docker, la gestion des certificats et l'importation des catalogues sur les pages du projet.

La configuration côté Checkmk est à nouveau — en général — assez simple : l'option « Environment dependency handling » est cette fois-ci définie sur « Fetch from RCC remote server » et complétée par l'adresse du serveur.

Il manque encore un dernier paramètre, selon que votre serveur RCCRemote utilise un certificat auto-signé ou signé par une autorité de certification (CA). Dans les deux cas, vous devez généralement définir l'option « Robotmk scheduler (Windows|Linux) » de RCC profile configuration à Custom profile.

Pour un certificat auto-signé, il suffit de laisser la case « Validate TLS certificates » décochée :

S'il s'agit toutefois d'un certificat signé par une autorité de certification, cette option doit être activée et le certificat de l'autorité de signature doit être enregistré sous Root CA (au format PEM) :

Si le planificateur ne reçoit aucune donnée, la création de l'environnement n'a probablement pas fonctionné. Cela est souvent dû à des problèmes de réseau, qui empêchent par exemple le chargement de certaines dépendances. Dans ce cas, veuillez consulter le fichier journal correspondant à l'adresse C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.

Il s'agit d'une erreur particulièrement intéressante que vous pourriez rencontrer sur des systèmes Windows récents. Le fichier conda.yaml peut également contenir des instructions à exécuter après l'installation des dépendances, par exemple l'initialisation du navigateur Robot Framework. Les instructions Python doivent donc être exécutées ici. Par défaut, Windows 11 dispose d'alias pour python.exe et python3.exe qui renvoient vers le Microsoft Store. Vous devez désactiver ces alias sous « Paramètres/Alias pour l'exécution des applications ».

Attention : sous Linux, le planificateur Robotmk ne crée pas son propre fichier journal (sous Windows, le fichier « robotmk_scheduler_rCURRENT.log »), mais consigne les informations via l'agent et syslog. L'instruction correspondante :