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 Robot-Framework-Projekte, also Test-Suites liegen. Tragen Sie diesen beliebigen, absoluten Pfad unter Base directory of Robot Framework projects ein, beispielsweise C:\robots.

Mit Parallel running sequences of plans folgt nun ein Checkmk-eigenes Konzept.

Zur Erklärung müssen wir zunächst eine Hierarchieebene tiefer gehen: Hier sehen Sie den Punkt Sequence of plans. Eine jeder 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"). Bis hierhin haben Sie also eine Robot-Framework-typisch eine Sequenz mit mehreren Plänen.

Die Parallel running sequences of plans sind nun eine Kapselung für mehrere solcher Sequenzen — 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 Sequence 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 Limit 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 Sequenz 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 Unterverzeichnissen 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 Megabytes an — allerdings nur beim ersten Durchlauf. RCC baut Umgebungen 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 (die auch der Befehl robot --help anzeigt) sowie Umgebungsvariablen zu nutzen. 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.

Besonderes Augenmerk verdient die Option Secret environment variables, da sie keine originäre Robot-Framework-Funktion ist. Sie können hier geheime Umgebungsvariablen setzen, gedacht für Passwörter im Zusammenspiel mit der Robot-Framework-Bibliothek "CryptoLibrary". Die hier gesetzten Variablen tauchen nicht in Logs auf, werden allerdings im Klartext in die Checkmk-Konfigurationsdateien auf den jeweiligen Test-Hosts geschrieben.

Am Ende der Suite-Konfiguration gibt es noch drei weitgehend selbsterklärende Optionen.

Die erste Option gibt es exklusiv für Windows-Hosts. 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 Kilobytes 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 Sequenz oder weitere Sequenzen 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 verteilen, 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.

Grundsätzlich könnten Sie einfach das komplette Robot-Verzeichnis mit den Standarddateien (robot.yaml, conda.yaml, test.robot) archivieren — unter Windows als ZIP, unter Linux als tar.gz.

Allerdings werden solche Tests häufig per Git verwaltet und folglich finden sich regelmäßig Dateien, die nicht mit verteilt werden sollen — typischerweise verwaltet über eine gitignore-Datei. Als Hilfestellung für saubere Archive, hier zwei kleine Skripte für Windows und Linux, die Archive ohne die zu ignorierenden Dateien erstellen. Verstehen Sie diese Skripte lediglich als Hilfestellung und testen Sie die Funktionsweise für Ihr System vorab.

Windows:

Linux:

Für diese Variante müssen Sie keinerlei Veränderungen an Ihren Tests selbst vornehmen. Öffnen Sie einfach die Regel Robotmk KPI discovery und tragen Sie die zu überwachenden Keywords als reguläre Ausdrücke oder ganz konkrete Namen ein.

Achtung: Wenn der reguläre Ausdruck auf mehrere Keywords desselben Tests matcht, wird nur ein Keyword erkannt und dessen Service-Status geht auf UNKNOWN (weil Checkmk freilich nicht weiß, welcher Treffer denn gemeint ist).

Für die Erkennung via Marker müssen Sie folgende Schritte durchführen:

Für die Installation muss die conda.yaml von oben mit robotframework-robotmklibrary erweitert werden. Änderungen gegenüber der obigen Suite sind gelb unterlegt:

Die Test-Suite tests.robot muss um die Bibliothek (im Bereich Settings) sowie einen Marker erweitert werden. KPIs werden sich dabei häufig auf individuelle Nutzer-Keywords beziehen, daher hier eine Erweiterung um das Keyword Foobar (das lediglich das Standard-Keyword Log aufruft und seinerseits vom Testfall My Test aufgerufen wird).

Das Robotmk-Keyword Monitor Subsequent Keyword Runtime ist der Marker, um (Checkmk an zu triggern) das folgende Keyword (Foobar) zu überwachen; genauer gesagt dessen Laufzeit. Über das optionale Argument discover_as lässt sich hier ein individueller Name für den Service im Monitoring setzen — das Keyword Foobar taucht folglich im Monitoring als Service namens My user keyword auf.

Der große Vorteil gegenüber der Muster-basierten Erkennung: Ein und dasselbe Keyword lässt sich auch mehrfach innerhalb eines Tests ganz explizit überwachen.

Hier das obige Beispiel, erweitert um zwei Foobar-Aufrufe:

Die drei Aufrufe des Keywords Foobar würden folglich als My user keyword, Foobar_2 und Foobar_3 im Monitoring auftauchen.

Egal über welche der beiden Varianten die Keywords ins Monitoring kommen, der nächste Schritt ist immer die Konfiguration der Auswertung: Ab welcher Laufzeit sollen die Services auf WARN beziehungsweise CRIT gehen? Dazu legen Sie in der Regel Robotmk KPI monitoring die entsprechenden Level fest.

Die Keyword-Services tauchen im Monitoring unter einem dieser beiden Muster auf:

Der Unterschied liegt also lediglich in der Herkunftsangabe in Klammern direkt vor dem Keyword.

Für das obige Bild mit zwei Foobar-Keyword-Services musste die Suite noch etwas erweitert werden:

Die beiden Keywords Foobar und Barfoo tauchen beide unter dem Namen Foobar im Monitoring auf, sind aber unterscheidbar durch die Herkunftsangabe in Klammern.

Das Beispiel mit zwei unterschiedlichen Keywords, die unter dem gleichen Namen geführt werden, dient vor allem der Verdeutlichung der Herkunftsangaben.

Wie oben bereits erwähnt: Der eigentliche Anwendungszweck von discover_as liegt darin, ein Keyword mehrmals in einem Test aufzurufen und unterschiedlich zu benennen.

Die Praxis ist weitaus einfacher als die technischen Hintergründe — insbesondere bei der Arbeit mit einem Katalog als ZIP-Archiv (beziehungsweise tar.gz-Archiv unter Linux). Im Grunde bauen Sie nur den Katalog unter Angabe der ROBOCORP_HOME-Variable, exportieren ihn als Archiv und verteilen dieses dann manuell. Folgend der Weg im Detail. Die Pfade in folgenden Beispielen beschränken sich auf Windows — lediglich wenn Linux andere Kommandos erfordert, geben wir diese explizit an.

Gleich vorweg: RCCRemote ist kein eigenständiges Tool, Sie werden dazu keine eigene Dokumentation oder auch nur eine Produktseite seitens Robocorp/Sema4 finden. Der Remote-Server ist lediglich Teil von RCC und wird beim Kompilieren von RCC mitgebaut. Betrieben wird er in der Regel per Container. Für den Container-Betrieb gibt es mittlerweile ein Projekt auf den GitHub-Seiten von Elabit, dem Entwickler des ursprünglichen Robotmk-Plugins, namens RCCRemote-Docker. RCCRemote und RCCRemote-Docker sind jedoch nicht Teil von Checkmk Synthetic Monitoring und nicht vom Checkmk-Support gedeckt!

Kataloge für diesen Distributionsweg lassen sich auf zwei Wegen erstellen: Für Windows wie Linux lassen sich als ZIP exportierte Kataloge (siehe oben) verwenden. Ausschließlich für Linux besteht zudem die Möglichkeit, die Kataloge direkt im RCCRemote-Docker-Container zu bauen, womit sich händisches Eingreifen komplett erledigt.

Wie Sie RCCRemote-Docker aufsetzen, mit Zertifikaten umgehen und Kataloge importieren, können Sie auf den Projektseiten nachlesen.

Die Konfiguration auf Checkmk-Seite ist nun wieder — typisch — ganz trivial: Die Option Environment dependency handling wird dieses mal auf Fetch from RCC remote server gesetzt und mit der Adresse des Servers versorgt.

Eine letzte Einstellung fehlt noch, je nachdem, ob Ihr RCCRemote-Server ein selbst-signiertes oder ein CA-signiertes Zertifikat einsetzt. In beiden Fällen müssen Sie in der Regel Robotmk scheduler (Windows|Linux) die Option RCC profile configuration auf Custom profile setzen.

Bei einem selbst-signierten Zertifikat genügt es, das Häkchen bei Validate TLS certificates nicht zu setzen:

Handelt es sich um ein CA-signiertes Zertifikat, muss die Option hingegen aktiviert und das Zertifikat der signierenden Stelle unter Root CA hinterlegt werden (im PEM-Format):

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 beziehungsweise /var/lib/check_mk_agent/robotmk/scheduler/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.

Achtung: Unter Linux legt der Robotmk-Scheduler keine eigene Log-Datei an (unter Windows die robotmk_scheduler_rCURRENT.log), sondern protokolliert via Agent und Syslog. Der zugehörige Befehl: