Checkmk Synthetic Monitoring mit Robotmk

Für dieses End-to-End-Monitoring spielen allerhand Komponenten zusammen, daher hier ein kurzer Überblick.

Den Robotmk-Scheduler finden Sie unter Setup > Agent rules > Robotmk scheduler (Windows). Da die Regel recht umfangreich ist, hier zunächst ein Blick auf die noch leere Konfiguration:

Zunächst benötigt der Scheduler die Angabe des Basisverzeichnisses, in dem all Ihre Test-Suites liegen. Tragen Sie diesen beliebigen, absoluten Pfad unter Base directory of suites ein, beispielsweise C:\robots.

Mit Parallel plan groups folgt nun ein Checkmk-eigenes Konzept.

Zur Erklärung müssen wir zunächst eine Hierarchieebene tiefer gehen: Hier sehen Sie den Punkt Sequential plans. Ein solcher sequenzieller Plan legt fest, welche Suites mit welchen Parametern ausgeführt werden sollen. Und Robot Framework arbeitet diese Suites dann nacheinander ab. Der Grund ist simpel: In der Praxis geht es manchmal um Tests, die auf dem Desktop ausgeführt werden und da könnten sich mehrere Test-Suites gleichzeitig in die Quere kommen (sich gegenseitig "die Maus klauen").

Die Plangruppen sind nun eine Kapselung für sequenziell ausgeführte Pläne — und werden selbst parallel ausgeführt. Auch hier ist der Grund simpel: So können Test-Suites, die eben nicht auf den Desktop angewiesen sind, ohne Verzögerung in eigenen Plänen ausgeführt werden — wie zum Beispiel die hier im Artikel eingesetzte Test-Suite.

Wieder zurück zum Dialog: Die einzige explizite Einstellung ist das Ausführungsintervall, das Sie unter Group execution interval setzen.

Nun geht es an die Konfiguration eines ersten Plans. Unter Application name können Sie einen beliebigen Namen eingeben. Dieser Name muss nicht eindeutig sein! Sinnvoll ist hier der Name der zu überwachenden Anwendung, beispielsweise OnlineShop oder hier im Beispiel schlicht MyApplication. Nun kann es natürlich vorkommen, dass eben dieser Online-Shop mehrfach getestet wird, sei es durch andere Test-Suites oder dieselbe Test-Suite mit unterschiedlichen Parametern. Um in solchen Fällen trotz identischer Namen dennoch eine Eindeutigkeit in den Ergebnissen zu erzielen, gibt es das Feld Variant. Wird die Anwendung OnlineShop etwa einmal auf Deutsch und einmal auf Englisch getestet (über entsprechende Parameter), könnten Sie hier entsprechende Kürzel verwenden. Im Monitoring gibt es dann Ergebnisse für My OnlineShop_de und My OnlineShop_en.

Notwendig ist hingegen die Angabe unter Relative path to test suite file or folder. Die Pfadangabe ist relativ zum oben angegebenen Basisverzeichnis, also beispielsweise mybot\test.robot für C:\robots\. Alternativ kann hier auch ein ein Verzeichnis (mit mehreren robot-Dateien) angegeben werden, dann wäre es schlicht mybot.

Weiter geht es mit der Execution configuration. Unter Timeout per attempt legen Sie fest, wie lange eine Test-Suite maximal laufen darf — pro Versuch. Mit Robot Framework re-executions können Sie nun Robot Framework anweisen, Test-Suites bei fehlgeschlagenen Tests komplett oder inkrementell zu wiederholen. Wenn die einzelnen Tests einer Test-Suite unabhängig voneinander sind, bietet sich die inkrementelle Strategie an, um Zeit zu sparen. Testet die Test-Suite hingegen eine logische Abfolge, etwa "Login → Aufruf Produktseite → Produkt in den Warenkorb → Checkout", muss die Test-Suite natürlich komplett neu abgearbeitet werden. Am Ende gibt es immer nur ein Ergebnis.

Bei kompletten Wiederholungen werden für das Endergebnis nur in sich abgeschlossene Suite-Ergebnisse berücksichtigt: Schlägt ein Test bei der letzten Wiederholung fehl, wird die Test-Suite als Fehlschlag gewertet. Bei inkrementellen Wiederholungen setzt sich das Endergebnis aus den besten Teilergebnissen zusammen: Laufen einige Tests erst im dritten Anlauf erfolgreich durch, wird auch das Endergebnis als Erfolg gewertet. Zur Erinnerung: Die Kombination aus Versuchen und maximalen Laufzeiten aller Pläne einer Plangruppe bestimmt deren minimales Ausführungsintervall.

Standardmäßig ist die Ausführung via RCC unter Automated environment setup (via RCC) aktiviert, für die Sie zwei Werte eintragen müssen. Zum einen benötigt RCC die Angabe, wo die Datei robot.yaml liegt. Deren primärer Zweck ist der Verweis auf die Datei conda.yaml, die für den Aufbau der Python-Umgebung verantwortlich ist, also die Installation von Python und Abhängigkeiten. Diese Angabe ist relativ zum Basisverzeichnis, das Sie oben unter Relative path to test suite file or folder gesetzt haben. Die YAML-Dateien können durchaus in Unterordnern gespeichert werden, Best-Practice ist aber das oberste Suite-Verzeichnis! Für das obige Basisverzeichnis C:\robot\ und das Suite-Verzeichnis C:\robot\mybot ist es entsprechend mybot\robot.yaml.

Beim folgenden Zeitlimit für den Bau der Python-Umgebung sollten Sie bedenken, dass bisweilen größere Datenmengen heruntergeladen und eingerichtet werden müssen. Insbesondere für die benötigten Browser fallen hier schnell einige Hundert Megabyte an — allerdings nur beim ersten Durchlauf. RCC baut Environments nur dann neu auf, wenn sich der Inhalt der conda.yaml geändert hat

Unter Robot Framework parameters haben Sie die Möglichkeit, einige der Kommandozeilenparameter von Robot Framework zu nutzen (die auch der Befehl robot --help anzeigt). Sollten Sie weitere Parameter nutzen wollen, hilft die Option Argument files. Eine hier angegebene Datei kann beliebige robot-Parameter beinhalten. Weitere Informationen über die einzelnen Parameter bekommen Sie über die Inline-Hilfe.

Für unser Beispielprojekt wird lediglich die Option Variables aktiviert und eine Variable MYVAR mit dem Wert My Value gesetzt — Sie erinnern sich an den Befehl Log ${MYVAR} oben in der Datei tests.robot? Dies ist die zugehörige Referenz.

Am Ende der Suite-Konfiguration gibt es noch drei weitgehend selbsterklärende Optionen. Execute plan as a specific user ermöglicht es, Robotmk im Kontext eines bestimmten Nutzerkontos auszuführen. Hintergrund: Standardmäßig wird Robotmk im Kontext des Checkmk-Agenten ausgeführt (LocalSystem-Konto), der keine Berechtigung für den Zugriff auf den Desktop hat. Hier kann nun ein Nutzer angegeben werden, der permanent an einer Desktop-Sitzung angemeldet sein muss und entsprechend Zugriff auf grafische Desktop-Anwendungen hat.

Mit Assign plan/test result to piggyback host lassen sich die Ergebnisse des Plans/Tests einem anderen Host zuweisen. Testet Robot Framework zum Beispiel den Bestellprozess eines Online-Shops, ließen sich die Ergebnisse so dem zugehörigen Webserver zuweisen.

Jeder Testdurchlauf produziert Daten, die unter C:\ProgramData\checkmk\agent\robotmk_output\working\suites\ abgelegt werden. Standardmäßig werden die Ergebnisse der letzten 14 Tage behalten, allerdings sollten Sie bedenken, dass sich hier schnell große Datenberge auftürmen. Pro Durchlauf fallen mindestens knapp 500 Kilobyte Daten an — mit komplexeren Test-Suites und beispielsweise eingebettete Screenshots können es aber auch schnell einige Megabyte sein. Je nach Ausführungsintervall, Größe des Reports und Anforderungen an Ihre Dokumentation, sollten Sie hier eingreifen.

Hier angelangt, könnten Sie nun weitere Pläne in dieser Plangruppe oder weitere Plangruppen erstellen.

Am Ende warten noch zwei Optionen, die sich wiederum auf die komplette Robotmk-Scheduler-Konfiguration beziehen.

RCC profile configuration erlaubt die Angabe von Proxy-Servern sowie davon auszunehmende Hosts.

Sehr nützlich kann auch Grace period before scheduler starts sein: Der Scheduler startet zusammen mit dem Checkmk-Agenten noch vor der Desktop-Anmeldung — was freilich dazu führt, dass etwaige Tests auf dem Desktop fehlschlagen müssen. Über eine Vorlaufzeit lässt sich der Start manuell verzögern.

Damit ist die Konfiguration abgeschlossen und Sie können einen neuen Agenten mit dem Plugin backen und anschließend ausrollen, manuell oder über die automatischen Agenten-Updates.

Im Monitoring finden Sie Services für den Status des Robotmk Schedulers sowie der einzelnen Pläne und Tests — natürlich auch, wenn sie keine separaten Service-Regeln angelegt haben.

Wenn der Scheduler keinerlei Daten bekommt, hat der Bau der Umgebung vermutlich nicht funktioniert. Ein häufiger Grund dafür sind Netzwerkprobleme, aufgrund derer zum Beispiel bestimmte Abhängigkeiten nicht geladen werden können. Schauen Sie in diesem Fall in die zugehörige Log-Datei unter C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.

Dies ist ein besonders interessanter Fehler, der Ihnen auf frischen Windows-Systemen begegnen könnte. In der conda.yaml können auch Anweisungen hinterlegt werden, die nach der Installation der Abhängigkeiten ausgeführt werden sollen — beispielsweise die Initialisierung des Robot-Framework-Browsers. Hier sollen also Python-Befehle ausgeführt werden. Nun hat Windows 11 standardmäßig Aliasnamen für python.exe und python3.exe vorgegeben, die auf den Microsoft-Store verweisen. Diese Aliasnamen müssen Sie unter Einstellungen/Aliase für App-Ausführung deaktivieren.