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

Im ersten Teil dieser Blogserie ging es darum zu zeigen, warum man beim End-to-End-Monitoring von Applikationen sprichwörtlich "zu Ende" denken sollte. Infrastruktur-Monitoring ist ohne Zweifel wichtig und essentiell, überwacht es doch die Basis, auf der Applikationen erst aufsetzen. Doch nur Tests oberhalb der OSI-Schicht 7 sind imstande, wertvolle Einblicke in die "End-User-Experience" von Software zu gewinnen.

Dieser Artikel basiert auf einer älteren Version von Robotmk (0.19 / Checkmk 1.6), ist in weiten Teilen aber noch gültig. Robotmk ist für den Einsatz unter Linux und Windows entwickelt worden. Bevor Sie jedoch Ihr End-to-End-Monitoring mit Checkmk und Robotmk einrichten, müssen Sie zuvor Robot Framework und Selenium auf ihrem System installiert haben. Außerdem benötigen Sie Python 3, dann können Sie Robot Framework inklusive Libraries problemlos mit pip install installieren. Für Selenium ist außerdem noch ein Webdriver notwendig, der quasi als Bindeglied zwischen Robot und dem Browser fungiert.

Nach einer kurzen Erläuterung der Teststruktur erklärt der Artikel, wie man das Robotmk-MKP in Checkmk installiert und den Checkmk-Agenten für Windows mit Hilfe der Bakery mit dem Robotmk-Plugin versorgt. Zuletzt geht der Artikel auf die verschiedenen Möglichkeiten der Check-Konfiguration ein:

• So funktioniert Robotmk
• Die Robot-Framework-Testsuite
• Robotmk installieren
• Das Plugin bereitstellen
• Monitoring Ihrer E2E-Tests
• Schwellwerte und Leistungsdaten
• Service Discovery Level
• Dokumentation
• Zusammenfassung
• Status
• Ausblick
• Fazit

TL;DR: So funktioniert Robotmk

• Das Robotmk-Plugin wird samt YML-Steuerdatei auf dem Client bereitgestellt.
• Der CheckMK-Agent führt das Plugin im vorgegebenen Intervall aus.
• Das Robotmk-Plugin liest aus der von der Agent Bakery erstellten YML-Steuerdatei ein, welche Robot-Suites mit welchen Parametern zu starten sind. Diese werden sequentiell ausgeführt.
• Am Ende einer jeden Robot-Suite übergibt das Plugin das von Robot geschriebene XML-Resultfile zusammen mit dem Robotmk-Section-Header <<<robotmk>>> an den Checkmk-Agenten.
• Der Robotmk-Check auf Checkmk-Seite wertet den <<<robotmk>>>-Abschnitt aus. Das RobotXML wird geparst und anhand der Monitoring-Regeln auf Laufzeitüberschreitungen etc. überprüft.

Robot-Framework-Testsuite

Das Robotmk-Plugin, welches später den Test ausführen soll, erwartet die Robot-Framework-Tests standardmäßig im Agenten-Verzeichnis C:\ProgramData\checkmk\agent\robot. Theoretisch lassen sich .robot-Dateien direkt dort ablegen; es empfiehlt sich aber, diese von vornherein durch Unterverzeichnisse voneinander zu trennen. Das erleichtert nicht nur die Versionskontrolle (z.B. durch GIT), sondern sorgt auch für mehr Überblick.

In das Verzeichnis wird nun das untenstehende Robot-File seleniumeasy.robot (siehe Listing) kopiert.

seleniumeasy.robot ist ein absichtlich einfach gehaltener Test, der dennoch ein paar Robot-typische Merkmale aufweist.

Struktur einer Testsuite

Die Strukturierung von Robot-Files lässt sich im Code-Beispiel erkennen:

• *** Settings *** Import der Selenium-Library, Aktionen vor (Setup) und nach (Teardown) dem Start der Suite.
• *** Variables *** Deklaration von Variablen.
• *** Test Cases *** Eine Suite besteht aus mindestens einem Test. Robot Framework versucht immer, alle Tests auszuführen; schlägt ein Test fehl, wird der nächste gestartet. Deshalb sind Tests immer so zu verfassen, dass sie möglichst ohne Vorbedingungen laufen. Für gemeinsame Vorbedingungen (hier: Start des Browsers, Öffnen der Seite, Schließen des Pop-ups) ist das Keyword-Setup zuständig, welches als Suite Setup in den Settings genannt ist.
• *** Keywords *** Benutzerdefinierte Abfolgen bestehender Keywords. Keywords lassen sich beliebig tief verschachteln, um den Test zu abstrahieren; Einrückungen von mindestens 2 Spaces zeigen die Schachtelungstiefe an.

Manueller Check zur Überprüfung

Bevor der Test automatisiert läuft, ist eine letzte manuelle Prüfung auf der Konsole sinnvoll:

robot .\seleniumeasy.robot
==============================================================================
Seleniumeasy
==============================================================================
Check How Tool1 is | PASS |
Foo is great
------------------------------------------------------------------------------
Check How Tool2 is | PASS |
Bar is great
------------------------------------------------------------------------------
Seleniumeasy | PASS |
2 critical tests, 2 passed, 0 failed
2 tests total, 2 passed, 0 failed
==============================================================================
Output: C:\Users\elabit\Documents\output.xml
Log: C:\Users\elabit\Documents\log.html
Report: C:\Users\elabit\Documents\report.html

Man beachte, dass der per Keyword Set Test Message gesetzte Text jeweils die Default-Variablen "Foo" und "Bar" enthält. In den nachfolgenden Schritten werden Sie u.a. lernen, diese Variablen von Checkmk aus zu setzen.

Installation von Robotmk

Im nächsten Schritt wird Robotmk auf dem Checkmk-System installiert. Der Standardweg ist hier die Installation über ein MKP-File, das man entweder auf Checkmk Exchange oder direkt auf der Github-Seite des Projektes in der aktuellsten Version herunterladen kann.

Bereitstellung des Robotmk-Plugins

Das soeben installierte MKP enthält unter anderem das Robotmk-Plugin. Dieses soll nun auf dem Windows-Host installiert werden. Auf "Checkmk Enterprise Edition"-Systemen kommt hier die Agent Bakery zum Zug, für die eine speziell entwickelte Robotmk-Regel existiert. Die Regel lässt sich am einfachsten finden, indem man unter WATO ➳ Host & Service Parameters nach dem Begriff “robot” sucht:

Nachdem Sie die neue Robotmk-Regel erstellt haben, geben Sie zunächst unter Type of execution an, wie das Robotmk-Plugin auf dem Ziel-Host ausgeführt werden soll – Sie können zwischen Async (Standard) und Spooldir wählen.

Async bewirkt, dass der Checkmk-Agent das Plugin in einem anderen Intervall als der standardmäßigen 1-minütigen Taktung zum Auslesen des Agenten startet. Das Execution interval lässt sich im Feld darunter setzen; zwischen den "echten" Ausführungen des Plugins liefert der Agent an den Checkmk-Server dann stets das zwischengespeicherte Ergebnis der letzten Ausführung.

An dieser Stelle ist es sehr wichtig zu wissen, dass sämtliche von Checkmk gestarteten Plugins im selben Benutzerkontext laufen wie der Agent - unter Windows ist es das Dienstkonto LOCAL_SYSTEM. Im Task Manager kann man sehen, dass der Prozess des Agenten in der Session ID 0 läuft. In diesem Kontext ist seit Windows 7 per Definition keine Interaktion mit dem Desktop möglich (daran ändert auch das Häkchen "Datenaustausch zwischen Dienst und Desktop zulassen" in den Dienst-Eigenschaften nichts; es ist eine Altlast).

Aus verschiedensten Gründen kann es also nicht möglich bzw. erwünscht sein, einen Test in dieser Session zu starten.

Auf den Spooldir-Modus weicht man also immer dann aus, wenn Robot Framework das SUT ("System under Test" = die zu testende Applikation) mit einem speziellen Benutzer starten muss oder es sich sogar um eine GUI-Applikation handelt, die zur Anzeige den Desktop benötigt. Das Starten des Robotmk-Plugins überlässt man in diesem Fall einem externen Mechanismus, z.B. dem Windows-Taskplaner oder cron/at unter Linux. Das Plugin schreibt die Ergebnisse dann automatisch in das Spool-Verzeichnis; der Agent ist dann nur für das "Einsammeln" der Daten zuständig.

Der Punkt Robot Framework test suites ist optional; spezifiziert man keine Suites, versucht das Plugin einfach, alle auffindbaren Suites im RobotDir auszuführen.

Allein schon aufgrund der zahlreichen Suite-spezifischen Einstellungen sollte man sich diese Option aber ruhig genauer ansehen: hier lassen sich die wichtigsten Commandline-Optionen von Robot Framework einstellen. Sie erlauben eine granulare Kontrolle der Ausführung.

Erwähnenswert ist beispielsweise die Möglichkeit, die Suite mit bestimmten Variablen zu starten (bzw. diese aus einer Datei einzulesen). Von dieser Möglichkeit machen wir hier Gebrauch; werden die Variablen TOOL1 und TOOL2 wie unten angegeben gesetzt, so überschreiben sie die Default-Werte Foo und Bar im Test.

Weiter ist es möglich, die Menge der in einer Suite enthaltenen Sub-Suites und Tests per Black-/Whitelisting einzugrenzen, sowie das Abbruchverhalten von Robot zu ändern: exitonfailure sorgt dafür, dass Robot nicht wie oben beschrieben versucht, stets alle Tests auszuführen, sondern beim ersten Fehlschlag die komplette Suite verlässt.

Die Optionen (Non-)Critical test tag dürften eingefleischte Monitoring-Admins auf eine falsche Fährte locken, denn hier geht es nicht im den "CRIT"-Status im Monitoring. Als "critical" werden im Robot-Kontext solche Tests bezeichnet, die den Status einer Suite negativ beeinflussen können - per default sind das alle. Möchte man dieses Verhalten einschränken, taggt man einzelne Tests und gibt das vergebene Tag anschließend hier an. Tests können dann fehlschlagen, ohne dass sie auf das Gesamtergebnis durschlagen.

Mit der Option Piggyback Host lässt sich das Robot-Ergebnis einem anderen Host zuordnen. Das ist sinnvoll, wenn man für die Ausführung verschiedener Tests einige wenige VMs verwenden, aber die jeweiligen Testergebnisse in Checkmk spezifischen Hosts zuweisen will.

Die Option Agent output encoding muss man im Normalfall nicht verändern, denn UTF-8 ist bei Checkmk die Standardcodierung der Agent-Ergebnisse. Wer sich beim Debuggen an den Newlines des Robot-XMLs stört und Wert auf eine kompakte Formatierung des Outputs legt, kann hier base64 wählen. Die dritte Option zlib-compressed ist besonders für ein zukünftiges Release interessant, wenn auch Bilder und Videos von Fehlersituationen im Agenten-Output übertragen werden. Hier schrumpft die Datenmenge auf unter 5 Prozent.

Die Ausführung von E2E-Tests ist in aller Regel Host-spezifisch; so ist es sinnvoll, am Ende der Regel ggf. noch die Option Explicit Hosts zu setzen, damit die Regel möglichst eng greift.

Wichtig: Damit das Robotmk-Plugin auf dem Remote-Host überhaupt zur Ausführung kommt, ist es erforderlich, die Liste der erlaubten Dateiendungen mit der zusätzlichen Checkmk-Regel Limit script types to execute durch .py zu erweitern.

Das "Backen" und Installieren des neuen Agenten folgt exakt den Schritten, wie sie in der Checkmk-Dokumentation beschrieben sind.

Nach der Installation des neu erzeugten MSI-Paketes lässt sich das Ergebnis auf dem Windows-Client überprüfen:

• C:\ProgramData\checkmk\agent\plugins sollte nun das Plugin robotmk.py enthalten
• C:\ProgramData\checkmk\agent\conf sollte die Datei robotmk.yml enthalten

Monitoring Ihrer E2E-Tests

Der Windows-Client ist jetzt einsatzbereit und hat die Suite selenium_test seit der MSI-Installation sehr wahrscheinlich im Hintergrund ein- oder mehrmals ausgeführt (der über Selenium gesteuerte Chrome-Browser ist imstande, "headless", also ohne GUI zu laufen).

Eine manuelle Inventarisierung des Windows-Hosts bringt einen neuen Service zum Vorschein:

Nach dem Speichern lohnt es sich, die Detailansicht des neu hinzugefügten Services zu öffnen, sie verdient eine genauere Betrachtung:

Man erkennt:

• Robot Framework interpretiert Verzeichnisse (selenium_test) und Robot-Files (seleniumeasy) als Suites ([S]). Die "Root"-Suite ist in der ersten Output-Zeile enthalten.
• Die Übergabe der Variablen TOOL1 und TOOL2 hat funktioniert: sie wurden vom Robotmk-Plugin korrekt an den Robot-Framework-Test übergeben und in den Keywords Set Test Message eingesetzt, um den Text des Tests zu setzen.
• Die Selenium-Keywords geben detailliert Auskunft darüber, welche Selektoren zum Zugriff auf die Elemente der Website zum Einsatz kamen.

Schwellwerte und Leistungsdaten

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

Robotmk macht sich die Eigenschaft von Robot Framework zunutze, sämtliche Elemente einer Suite (also Subsuites, Tests, Keywords und Sub-Keywords) bereits mit Start- und Endzeit im Ergebnis-XML erfasst zu haben. Und weil dieses XML im Rohformat auf die Checkmk-Seite transportiert wurde, hat der Checkmk-Admin alle Freiheiten, diese Daten fürs Monitoring der Laufzeiten zu verwenden: per WATO-Regel definiert er nur noch Regex-Patterns für die Namen der Robot-Nodes (Suites, Tests, Keywords) und setzt dafür die gewünschten WARN/CRIT-Schwellwerte.

Den Rest erledigt der Check beim rekursiven Verarbeiten des XML-Ergebnisses. Mit dem gleichen Pattern-System legt der Administrator im Übrigen auch fest, für welche Elemente er von Checkmk Performance-Graphen erzeugen lassen will.

Als Beispiel soll Checkmk eine Warnung generieren, wenn die Laufzeit des Tests Check How Tool2 is über 0.3 Sekunden dauert. Zusätzlich soll es für beide Tests Graphen erstellen.

Zuständig hierfür (und einiges mehr) ist die Robotmk-Regel für Discovered Services:

Der Punkt Runtime thresholds gliedert sich (ebenso wie Perfdata creation) jeweils in Abschnitte für Suites, Tests und Keywords. Die im Screenshot eingetragenen Schwellwerte dürften selbsterklärend sein; ebenso die beiden Patterns (man beachte, dass der Perfdata-Pattern nur auf den zweiten Test zutrifft).

Gerade bei neu erstellten End2End-Tests kann es hilfreich sein, die überwachte Laufzeit nicht nur dann im Output anzuzeigen, wenn sie überschritten wurde, sondern jederzeit. Die Option Show monitored runtimes also when in OK state steuert dies.

Include execution date fügt in die Zeile von Tests und Suites den Timestamp der Ausführung ein. Das ist besonders hilfreich, wenn der Zeitstempel des letzten Ergebnisses in Checkmk nicht ausreicht, sondern genau festgestellt werden muss, wann der Test mit dem SUT in Kontakt war.

Nach dem Aktivieren der Regel und Re-Schedulen des Checks zeigt sich der Service in diesem Zustand:

Deutlich zu sehen ist, wie die überschrittene Laufzeit des zweiten Testcases den Test-Status auf WARN setzt, sowie auch den der beiden übergeordneten Suites.

Der folgende Screenshot zeigt einen der beiden Graphen für die Laufzeit der Testcases:

Je nach Anwendungsfall kann es nützlich sein, nicht nur den Nicht-OK-Zustandes nach oben an Tests und Suites zu propagieren, sondern auch dessen Ursache (die Laufzeitüberschreitung). Aktiviert man in der eben bearbeiteten Regel noch die Option Show messages of sub-nodes, so wird der Output noch aussagekräftiger:

Hilfreich ist die Angabe für die Ursache des Alarms z.B. bei SMS-Benachrichtigungen, bei denen nur die 1. Zeile verschickt wird - die Rufbereitschaft ist sicher dankbar!

Die Zweckmäßigkeit dieser Option muss man allerdings je nach Umfang einer Robot-Suite und der Anzahl an möglichen, gleichzeitigen Alarmen entscheiden.

Service Discovery Level

Stellen Sie sich vor, dass Team A nur die Alarme des Tests Check How Tool1 is erhalten möchte, Team B entsprechend die des Tests für Tool B. Sie möchten/können die Robot-Suite aber nicht zerteilen, um zwei separate Checkmk-Services zu bekommen.

Hier bietet Robotmk ein interessantes Feature namens Service Discovery Level, zu finden als gleichnamige Regel in der WATO-Regelverwaltung:

Wie oben bereits beschrieben, generiert Robot Framework Suites aus Robot-Files und Verzeichnissen, die solche enthalten. Robot-Files wiederum sind die "Container" für Tests (nicht verschachtelbar), die aus ineinander verschachtelten Keywords bestehen.

Jedes Robot-Ergebnis besteht aus immer genau einer Suite, woraus Robotmk per default einen Service erzeugt. Das Service Discovery Level lässt sich per Regel so anpassen, dass die Service-Generierung nicht auf obersten Ebene "0" (Folder-Suite), sondern z.b. auf Ebene der Tests (hier: 2) startet:

Gleichzeitig erlaubt diese Regel auch, per Discovery neu erkannte Services mit einem Präfix zu versehen. Der etwas sperrig aussehende Platzhalter %SPACE% verhindert, dass ein absichtlich eingegebenes Leerzeichen nach dem Präfix von der WATO entfernt wird; er wird erst während der Laufzeit der Inventarisierung in ein Leerzeichen umgewandelt und trennt dann wie gewünscht das Präfix vom Namen:

Nach dem Speichern der Regel ist eine Neu-Inventarisierung der Services notwendig. Der bisher einzelne Service (generiert aus Level 0) verschwindet. Stattdessen erkennt Checkmk nun zwei neue Services. Sie repräsentieren die Tests der Suite.

Dank der Regel Service Discovery Level kann der Quellcode dieser Robot-Suite unangetastet bleiben; die unterschiedliche Alarmierung der beiden Services lässt sich mit Checkmk-Bordmitteln erledigen.

Dokumentation

Da es möglich ist, Robotmk vollständig über die WATO zu konfigurieren, wurde viel Wert auf eine umfassende Kontexthilfe gelegt. Klickt man auf das Buch-Icon in der oberen rechten Bildschirmecke der Checkmk-Oberfläche, so blenden die Robotmk-Regeln bei jeden Eingabefeld einen ausführlichen Hilfetext ein. Robot-Framework-spezifische Themen sind ggf. mit der Dokumentation von Robot Framework verlinkt.

Zusammenfassung

Robotmk schlägt die Brücke zwischen zwei technologisch höchst unterschiedlichen Tools, die in vielerlei Hinsicht wiederum optimal zueinander passen:

• Die Wirkungsbereiche im OSI-Modell ergänzen sich jeweils perfekt (siehe Teil 1 dieses Artikels: End-to-End-Monitoring – oder: zu Ende gedacht),
• modularer Aufbau und vielseitige Einsatzmöglichkeiten,
• Open Source,
• lange Marktpräsenz und Kontinuität seit über 10 Jahren,
• weltweit wachsende, starke Community und
• jährliche Konferenzen, Meetups, Workshops etc.

Status und Ausblick

Der Autor arbeitet inzwischen als Produktmanager für "Synthetic Monitoring" bei Checkmk daran, dass Robotmk als Enterprise-Lösung in Checkmk 2.3 voll integriert sein wird.

Neue Features in Robotmk v2 sind unter anderem die parallele Ausführung von Test-Suites und das vollautomatische Provisionieren der Python-Umgebungen. 

Fazit

Dass eine derartige Integration von Ergebnissen aus Tests mit Robot Framework in ein Monitoring-System überhaupt möglich ist, liegt an der Tatsache, dass Checkmk die Erhebung der Daten strikt von deren Auswertung trennt: nicht das Plugin auf dem Client wird parametrisiert, sondern der Server-seitige Check, welcher die erhobenen Daten auswertet.

Robotmk macht reichlich Gebrauch von der Möglichkeit, den zugrunde liegenden Python-Code mit den eigens dafür gebauten WATO-Masken zu beeinflussen. Im Übrigen ist unter anderem deshalb eine Kompatibilität zu anderen Monitoring-Systemen (Naemon, Icinga2, Zabbix, etc.) auch ausgeschlossen.

Der Robotmk-Check benötigt zur Auswertung lediglich die XMLs der Ergebnisse, die Robot-Tests selbst sind Monitoring-agnostisch. Das ergibt doppelten Nutzen: bestehende Robot-Tests (z.b. aus einer CI-Pipeline) können ohne Anpassung parallel im Monitoring verwendet werden; neu erstellte Applikationstests sind auch außerhalb von Checkmk verwendbar.

Hinweis zum Autor:

Simon ist aktives Mitglied der Checkmk-Community und stellt in unserem Blog sein Checkmk-Plugin Robotmk vor, das auf dem Robot Framework basiert und ein End-to-End-Monitoring mit Checkmk ermöglicht. Simon ist Geschäftsführer von Elabit und Spezialist für IT-Themen wie Monitoring (Checkmk), Konfigurations-Management (Ansible) oder RPA/Robotiv Process Automation und Testautomatisierung (Robot Framework, Robotmk).