End-to-End-Monitoring mit Checkmk – Robotmk konfigurieren

Das End-to-End-Monitoring von Applikationen ist ebenso kritisch wie das Monitoring der IT-Infrastruktur. Im vorherigen Teil unserer Serie “End-to-End-Monitoring – oder: zu Ende gedacht", haben wir erörtert, was genau das bedeutet. In diesem Artikel widmen wir uns nun dem “Wie” – also der praktischen Umsetzung. 

Dabei werden wir einerseits darauf eingehen, wie Sie Ihre Entwicklungsumgebung so einrichten, dass sie einen Robot-Framework-Test in VS Code einfach starten, debuggen und entwickeln können. Andererseits werden wir die einzelnen Schritte durchgehen, die erforderlich sind, um diesen Test mithilfe des Robotmk-Schedulers in Checkmk zu integrieren. 

Hinweis: Der Artikel basiert auf Robotmk Version 2, das seit Version 2.3 Bestandteil von Checkmk ist. Diese Robotmk-Version konzentriert sich auf Windows-Hosts als Testknoten; wenn Sie Tests auf Linux-Hosts ausführen müssen, ist die Version 1 von Robotmk weiterhin als MKP verfügbar und kann über das Checkmk Exchange heruntergeladen werden. 

Unser Beispiel starten wir mit einer frischen virtuellen Maschine mit Windows 11, auf der weder Python noch Robot Framework oder andere zugehörige Bibliotheken installiert sind. Diese saubere Umgebung ist entscheidend, da sie dem Szenario entspricht, das jemand vorfindet, wenn man einen Robot-Framework-Test mit VS Code starten möchte.

Auf dem System ist lediglich der Checkmk-Vanilla-Agent für eine sehr grundlegende Überwachung installiert: 

Schauen wir uns nun einen sehr einfachen Webtest an, der auf der Browser-Bibliothek für Robot Framework basiert. Sie können das Beispiel von hier herunterladen: 

https://github.com/Checkmk/robotmk-examples/tree/main/templates/web

Für eine erste manuelle Ausführung ist es in Ordnung, das Verzeichnis z. B. im Ordner Dokumente zu speichern: 

Genrell empfehlen wir, dass Sie Ihre Robot-Framework-Suiten in speziellen Ordnern verwalten. Das hilft nicht nur bei der Verwaltung der Suiten, sondern vereinfacht auch die Integration mit anderen Tools oder die Versionskontrolle mit Git. In unserem Fall befindet sich unter dem Ordner "Documents" ein Unterordner mit dem Namen cmk_google_search, der die Robot-Framework-Suite für unser Beispiel enthält.

Die Datei cmk_google_search.robot in diesem Ordner wird als "Robot Framework-Suite" bezeichnet. Eine "Suite" ist in der Terminologie von Robot Frameworks (RF) eine Sammlung von Testfällen.

Zum Bearbeiten von RF-Suite-Dateien können Sie einen beliebigen Texteditor verwenden. Für die beste Benutzererfahrung und die Möglichkeit, die Tests auszuführen und zu debuggen, empfehlen wir jedoch die Installation von VS Code und der darin enthaltenen großartigen Erweiterung RobotCode. Diese Erweiterung bietet Code-Vervollständigung, Debugging, Refactoring und mehr, um die Arbeit an RF-Testsuites zu erleichtern.

So sieht eine Robot-Framework-Suite in VS Code aus. Achten Sie auf die blauen Zeilen mit Sternen; sie markieren die verschiedenen Abschnitte mit ihrer besonderen Bedeutung:

Zunächst müssen Sie RCC von der offiziellen Download-Seite herunterladen.

Als wir den Artikel erstellt haben, war 17.18 die letzte stabile Version, die Sie verwenden sollten.

Legen Sie die Datei rcc.exe in einem bin-Ordner ab, zum Beispiel direkt unter unserem Windows-Benutzerprofil-Ordner:

c:\Benutzer\simon_meggle\bin

Anschließend fügen Sie diesen Pfad der Umgebungsvariablen %PATH% in den "Erweiterten Einstellungen" des Windows-Systems hinzu: 

Nun testen wir, ob RCC in der Lage ist, die Umgebung für unsere Beispiel-Suite zu erstellen. Öffnen Sie eine neue CMD im Ordner des Beispiels und geben Sie ein:

rcc task shell

Was macht dieser Befehl?

Er liest die in der Datei conda.yaml hinterlegten Umgebungsspezifikation aus und erstellt die definierte Umgebung – das kann jedoch einige Minuten dauern. Anschließend befinden Sie sich direkt in der aktivierten Umgebung. "Aktiviert" bedeutet in diesem Fall, dass Sie nun auf magische Weise Python, Node.js oder robot ausführen können – je nachdem was Sie in der Datei conda.yaml zur Installation angegeben haben.

In einer solchen aktivierten Umgebung lässt sich Robot Framework am einfachsten über die Befehlszeile ausführen, indem Sie folgenden Befehl eingeben: 

robot tests.robot

Das sollte bereits funktionieren, idealerweise verwenden Sie dafür jedoch VS Code als Editor. Da Sie sich ohnehin schon in einer aktivierten Umgebung befinden, ist es sinnvoll, VS Code direkt von hier aus aufzurufen: 

code .

Das bedeutet, Sie öffnen den aktuellen Ordner (=den Punkt), in VS Code.

Sie stellen jetzt fest, dass der Editor zwei grüne "Play"-Knöpfe anzeigt. Gleichzeitig erhalten Sie unter dem Reagenzglas-Symbol auf der linken Seite eine Baumstruktur der Suite-Datei und ihrer Tests. 

An dieser Stelle kommen wir zum wirklich interessanten Teil: Wie bringen wir Checkmk bei, einen Robot-Framework-Test auszuführen, sodass wir seinen Status in das Monitoring integrieren können? 

Die Integration der Tests in Checkmk beginnt mit der Erstellung eines neuen Agentenpakets, das den Robotmk-Scheduler, das Robotmk-Agenten-Plugin, die RCC-Binärdatei und eine Konfigurationsdatei enthält, in der die auszuführenden Suiten angegeben sind. 

Wenn Sie im Setup-Menü nach dem Begriff “Roboter” suchen, gelangen Sie zur erforderlichen Regel “Robotmk scheduler (Windows)”: 

Zunächst sollten Sie den Geltungsbereich der Regel auf bestimmte Hosts oder Host-Labels beschränken, um sicherzustellen, dass die Tests nur bei Bedarf durchgeführt werden. Zweitens setzen Sie das Basisverzeichnis ganz oben in der Regel auf c:\robots. 

Die Bakery-Regel in Robotmk v2 ist der Regel in Robotmk v1 sehr ähnlich. Die wichtigste Änderung ist, dass wir auf dieser Seite nicht mehr von "Suiten", sondern von "Plänen" sprechen. 

Was ist also der Unterschied zwischen einer “Suite” und einem "Plan"? 

Eine "Suite" bezieht sich immer auf das, was durch eine .robot-Datei dargestellt wird, wie wir oben gesehen haben. Mit einfachen Worten: Es handelt sich um etwas, das Robot Framework direkt ausführen kann. 

Ein "Plan" definiert alle Einstellungen und Parameter für Robotmk, um eine Suite auszuführen. Er enthält den Pfad zur Suite und Einstellungen, die sich auf Checkmk beziehen.

Gehen wir als nächstes kurz die wichtigsten Felder innerhalb eines Plans durch:

• Application name: Hier geben Sie für die Anwendung, die Sie testen, einen beliebigen Namen an.
• Variant: Falls Sie dieselbe Suite mit unterschiedlichen Parametern mehrmals ausführen wollen, müssen Sie das Feld Variant ausfüllen, sodass Checkmk zwischen den Varianten unterscheiden kann.
• Relative path to test suite file or folder: An dieser Stelle legen Sie den Pfad zum RF-Suite-Ordner oder direkt zu einer bestimmten “.robot”-Datei relativ zum Basisverzeichnis fest.
• Limit per attempt: Standardmäßig führt Robotmk eine Suite genau einmal aus, was als Versuch (Attempt) bezeichnet wird. Das Timeout gibt an, wie lange ein solcher Versuch laufen darf. 
• Robot Framework re-executions: Robotmk kann eine fehlgeschlagene Suite eine bestimmte Anzahl von Versuchen wieder ausführen, wenn ein oder mehrere Tests fehlgeschlagen sind. Das Endergebnis wird aus allen Versuchsergebnissen berechnet. Sie können zwischen zwei Strategien wählen: inkrementell (einzelne Tests werden wieder ausgeführt) und vollständig (wenn Tests voneinander abhängen, wird die gesamte Suite wieder ausgeführt).
• Automated environment setup (via RCC): Für Systeme ohne vorinstallierte Python-Umgebung können Sie RCC so konfigurieren, dass es die erforderliche Umgebung automatisch einrichtet. Dazu müssen sie den relativen Pfad zur RCC-Hauptkonfigurationsdatei robot.yaml angeben, die RCC zur Erstellung der Umgebung, Ausführung von Aufgaben und Skripten verwendet. Weitere Informationen über diese Datei finden Sie in der offiziellen Dokumentation
• Robot Framework parameters: In diesem Feld legen Sie die gängigsten Befehlszeilen-Parameter für Robot Framework fest. Der vielleicht wichtigste Parameter ist "Variables''. Er ermöglicht es Ihnen, Variablen zu konfigurieren, die dann Teil des globalen beziehungsweise Suite-Bereichs beim Ausführen der Suite sind. Erinnern Sie sich an die Variable "SEARCH_TERM" in der .robot-Datei? Wenn Sie diese, wie auf dem Screenshot zu sehen ist, mit "Checkmk Conference" überschreiben, verwendet der Test anstelle der in der Suite-Datei definierten Standardabfrage nun den in Checkmk angegebenen Variablenwert.

Sie fragen sich vielleicht, wo Sie das Intervall für den Plan festlegen können. Dafür müssen wir zunächst ein übergeordnetes Konzept namens "parallele Plangruppen" erklären. Ein Plan ist immer Teil einer solchen Gruppe, die ein individuelles Ausführungsintervall hat. 

Pläne innerhalb der gleichen Gruppe werden nacheinander ausgeführt (daher auch die Bezeichnung "sequential" in der Option der Benutzeroberfläche). Das ist erforderlich, wenn Sie Tests haben, die zwar auf dieselbe Ressource zugreifen, dabei jedoch kein paralleler Zugriff erlaubt ist. Das ist vor allem bei desktopbasierten Tests der Fall. Stellen Sie sich zwei RF-Tests vor, die gleichzeitig auf einem Desktop um die Maus kämpfen…

Pläne in verschiedenen Gruppen lassen sich hingegen einzeln und parallel ausführen. Die einzige Einschränkung hierbei sind die vorhandenen Maschinenressourcen: für Robotmk empfehlen wir mindestens 8 GB RAM und 4, besser 8 vCPUs. Selbst wenn parallele Ausführungen mit dieser Konfiguration funktionieren, können Sie nicht wissen, ob die knappen Ressourcen des Rechners diese möglicherweise verlangsamen! Geben Sie dem Rechner also besser gleich eine großzügige Menge an Ressourcen, damit Sie nicht in diese Falle tappen.

Speichern Sie abschließend das Dialogfenster und wenden Sie die Regel an. Gehen Sie zur Bakery und erstellen Sie ein neues MSI-Paket:

Nachdem Sie den neuen Agenten installiert und gestartet haben, startet dieser sofort "robotmk_scheduler.exe" als Sidecar-Prozess. Selbst wenn Sie diesen Prozess beenden sollten, wird der CMK-Agent immer dafür sorgen, dass er läuft und ihn gegebenenfalls neu starten. 

Wenn Sie auf dem Host nun eine Service-Discovery durchführen, erhalten Sie einen neuen Service, der den Zustand des Schedulers darstellt. 

Zunächst ist der Scheduler mit der Erstellung der Umgebung durch RCC beschäftigt.

Bitte beachten Sie, dass dass die Erstellung der Umgebung immer die erste Aufgabe ist, die der Scheduler nach seinem Start ausführt. Nachdem er alle Umgebungen erstellt hat, folgt die Planausführung. Das hat einen einfachen Grund: Der Prozess beansprucht eine ganze Menge an Systemressourcen und auf diese Weise lässt es sich vermeiden, dass die Laufzeit bzw. Ergebnisse der laufenden Tests beeinflusst werden.

Nach einiger Zeit sollte der Scheduler mit der Erstellung der Umgebung fertig sein und in seine zweite Phase eintreten: der Ansetzung der Plangruppen.

Das heißt, dass Sie einige Zeit nach der ersten Ausführung der Discovery in der Lage sind, zwei weitere Services zu erkennen:

Robotmk v2 erkennt standardmäßig alle Tests einer Suite und nimmt diese als Service in Checkmk auf. Sie stellen den jeweiligen Status der Tests dar. 

Die Plan-Services wiederum richten sich an Adminis: Sie informieren diese über interne Probleme, etwa bei der Erstellung der Umgebung, veraltete Ergebnisse usw.

Durch diese Trennung der Bereiche – Planer, Pläne und Tests – haben Sie die volle Kontrolle über die Benachrichtigungskanäle für die verschiedenen Beteiligten. 

Was wäre das Monitoring ohne Schwellwerte? Die Überwachung von Laufzeiten innerhalb eines Tests nimmt bei Robotmk eine besondere Rolle ein.

Robotmk profitiert von der Funktion des Robot Frameworks, dass alle Elemente einer Suite (d.h. Sub-Suites, Tests, Keywords und Sub-Keyowords) mit Start- und Endzeiten in der erzeugten XML-Datei erfasst sind. 

Und da diese XML-Datei im Rohformat in Checkmk zur Verfügung steht, hat das Monitoring-Team alle Freiheiten, diese Daten für die Überwachung der Laufzeiten zu verwenden – wie in Checkmk üblich, unter Anwendung von Monitoring-Regeln.

Sie finden die entsprechenden Regeln im Setup-Menü, indem Sie nach "robot" suchen:

In diesem Artikel haben wir Ihnen gezeigt, wie Sie mit Robotmk die ersten Schritte für die erfolgreiche Einführung von Synthetic-Monitoring in Ihrem Unternehmen umsetzen können. Da wir noch weitere Artikel geplant haben, lassen Sie uns bitte wissen, welche Themen rund um Robotmk Sie am meisten interessieren würde.

Die neue Version 2 von Robotmk deckt alle Funktionen der vorherigen Version 1 ab. Unterm Strich hat sich mit der neuen Version viel getan: Wir haben das Tool komplett in Rust statt in Python neu programmiert. 

Durch die RCC-Integration und der parallelen Ausführung von Tests durch den Scheduler haben wir zudem die Basis für eine ganze Reihe zusätzlicher Features gelegt, die mit kommenden Versionen ausgerollt werden.  Unser Ziel ist es, Robotmk und das synthetische Monitoring mit Checkmk immer weiter zu verbessern.