Checkmk Synthetic Monitoring mit Robotmk

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

Sie können Test-Suites auch ohne Checkmk direkt mit CSM ausführen. Dafür muss das Tool aber noch eingerichtet werden — und zwar spezifisch für die verwendete Shell. Sie können Ihre Shell manuell angeben oder CSM selbst erkennen lassen:

CSM gibt darauf hin genaue Instruktionen aus, wie die Einbindung in Ihre Shell funktioniert — hier am Beispiel Powershell:

CSM ist im Wesentlichen ein Wrapper für Micromamba und über den init-Befehl werden entsprechende Einstellungen konfiguriert und hier auch direkt in die Shell-Konfiguration geschrieben, damit die Einstellung über die Session hinweg bestehen bleibt. Wenn Sie sehen wollen, welcher Code da generiert und in die Shell-Konfiguration geschrieben wird, führen einfach den CSM-Befehl für Ihre Shell solo aus:

Nun ist CSM einsatzbereit und die Arbeit mit virtuellen Umgebungen kann beginnen. Im Ordner Ihres CSM-Automationspakets führen Sie folgenden Befehl aus, um die Umgebung zu erstellen:

Ein erster sinnvoller Befehl wäre nun das Auflisten verfügbarer virtueller Umgebungen:

Nun ist es an der Zeit, die erstellte Umgebung zu aktivieren:

Einmal aktiviert, können Sie Robot-Framework-Befehle direkt in der virtuellen Umgebung absetzen (robot --version).

Aber natürlich geht das auch ohne manuelles Aktivieren:

Der Robotmk-Scheduler agiert in der Praxis auf dem Test-Host freilich ohne CSM direkt mit Micromamba. Zur Erinnerung: CSM ist ein rein nutzerseitiges Tool, das als Wrapper den Umgang mit Micromamba erleichtert.

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. Ein 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 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 Sequenzen 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 OnlineShop_de und 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 mybot1\sample.robot für C:\robots\. Alternativ kann hier auch 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: Durch die Kombination aus Versuchen und maximalen Laufzeiten aller Pläne einer Sequenz wird deren minimales Ausführungsintervall bestimmt.

Standardmäßig ist die Ausführung via Conda unter Automated environment setup aktiviert, für die Sie drei Werte eintragen müssen. Zum einen benötigt Conda die Angabe, wo die Datei robotmk-env.yaml liegt. Diese ist für den Aufbau der Python-Umgebung verantwortlich, 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\mybot1 ist es entsprechend mybot1\robotmk-env.yaml.

Es folgt die Pfadangabe für die robotmk-setup.yaml, die Anweisungen enthält, die nach dem Bau der Conda-Umgebung ausgeführt werden sollen — natürlich nur, wenn Sie diese Datei auch nutzen.

Beim folgenden Zeitlimit Environment build timeout 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.

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 sample.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 beispielsweise 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.

Aber nicht zu voreilig: Browser bilden hier eine Ausnahme! Diese können headless laufen und Webseiten rendern. Das Häkchen für einen spezifischen Nutzer sollten Sie wirklich nur setzen, wenn eine dedizierte Desktop-Anwendung abseits von Browsern gestartet wird — nicht zuletzt aus Sicherheitsgründen.

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 eingebetteten 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.

Conda configuration erlaubt die Angabe von Proxy-Servern, TLS- und SSL-Zertifikaten sowie davon auszunehmende Hosts.

Sehr nützlich kann auch Grace period before scheduler starts sein: Der Scheduler startet beim Neustart des Test-Hosts zusammen mit dem Checkmk-Agenten noch vor der Desktop-Anmeldung des Nutzers — 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 zum Beispiel per Autologin (Windows-Funktion zum Anmelden ohne manuelle Passworteingabe) der Desktop des technischen Benutzers (wieder) aktiv wird.

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 (robotmk-env.yaml, robotkmk-setup.yaml, sample.robot etc.) archivieren.

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 folgen 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.

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 robotmk-env.yaml von oben mit robotframework-robotmklibrary erweitert werden. Änderungen gegenüber der obigen Suite sind gelb unterlegt:

Die Test-Suite sample.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 Test1 aufgerufen wird).

Das Robotmk-Keyword Monitor Subsequent Keyword Runtime ist der Marker, um (Checkmk anzuweisen) 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.

Der einfachste Weg, die Ereignisse im Synthetic Monitoring zu beobachten, ist die Verfolgung der Log-Dateien in einer Live-Ansicht. Die genauen Speicherpfade finden Sie unten in der Übersicht.

Unter Linux bietet sich hierfür folgender Befehl an:

Unter Windows könnten Sie beispielsweise Notepad++ oder VS Code nutzen, aber auch viele andere IDEs bieten die Möglichkeit, Dateiänderungen live mitzuverfolgen.

Je nach Konfiguration Ihrer Pläne, Tests und Umgebungen kann dieser Weg natürlich einige Zeit dauern — er dient hauptsächlich zur Verfolgung der regulären Scheduler-Aktivität.

Alternativ können Sie den Scheduler auch manuell starten. Dafür muss dieser zuvor gestoppt und im Monitoring sollte eine Wartungszeit gesetzt werden, um Auswirkungen auf das Monitoring und einen automatischen Neustart des Schedulers zu verhindern.

Unter Windows stoppen Sie den Service mit Hilfe des Task-Managers, unter Linux lassen sich Stop und Start im Terminal durchführen:

Über den manuellen Start des Schedulers haben Sie etwas mehr Kontrolle, sind aber immer noch auf Log-Dateien angewiesen und die komplette Synthetic-Monitoring-Konfiguration wird ausgeführt.

Der Scheduler unterstützt jedoch auch die manuelle und einmalige Ausführung einzelner Pläne. In diesem Fall erfolgt die Ausführung umgehend, etwaige Wartezeiten oder sonstige Ausführungslogik spielen hier keine Rolle. Zudem bekommen Sie die Informationen ohne Umweg über Log-Dateien direkt im Terminal geliefert. Auch bei der Adhoc-Ausführung müssen Sie den laufenden Scheduler-Service zunächst stoppen und sollten im Monitoring eine Wartungszeit setzen.

Der Scheduler lädt auch in diesem Szenario die komplette Konfiguration, beschränkt die Ausführung aber auf den angegebenen Plan:

Die hier angebene Plan-ID entspricht der Angabe, die Sie in der Robotmk-Scheduler-Konfiguration unter Sequence of plans > Application name gemacht haben, gefolgt von einem Unterstrich und dem eigentlichen Bot-Namen, hier also beispielsweise myapp1_mybot1 (so wie der Service auch im Monitoring auftaucht).

Wichtig ist auch das Argument -vv für die erweiterte Ausgabe, da der Scheduler ansonsten nur wenig Rückmeldung gibt.

Ein letztes verfügbares Argument --no-plan-result verhindert, dass ein Resultat, also ein Robot-Framework-Bericht, in den entsprechenden Ordner kopiert wird — so dass es lediglich lokal verbleibt.

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.

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: