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

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

By Simon Meggle on Feb 05, 2021

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.

In diesem Artikel soll es nun konkret darum gehen, wie sich mit der Checkmk-Erweiterung "Robotmk" (Version 0.19) ein End2End-Test (auf Basis von "Robot Framework") in Checkmk 1.6 integrieren auf einem Windows-System lässt. 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:

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.

Ablage der .robot-Datei im AgenturverzeichnisAblage der Robot-Suite im Agentenverzeichnis.

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.

Strukturierung der Robot-FilesDie Strukturierung der Robot-Files lässt sich am Code ganz gut nachvollziehen.

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.

Die RobotMK-Erweiterung in CheckmkDas installierte Robotmk-Paket in Checkmk.

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:

Auffinden der Regel über die SuchfunktionDie Suchfunktion hilft, die Bakery-Regel für Robotmk zu finden.

Nach dem Anlegen der neuen Robotmk-Regel legt man unter Type of execution zunächst fest, wie das Robotmk-Plugin auf dem Ziel-Host ausgeführt werden soll; zur Auswahl stehen Async (default) und Spooldir.

Ausführungsarten des PluginsFestlegung der Ausführungsart der Plugins.

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

Die Session-ID 0 erlaubt keinen Desktop-ZugriffDie Session-ID 0 des Dienst-Kontos erlaubt keinen Desktop-Zugriff.

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.

Das Test-Intervall lässt sich individuell festlegenScheduling der Suite 'selenium_test' im 2-Minuten-Intervall.

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.

Festlegen der Robot-VariablenSetzen von Robot-Variablen.

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.

Encoding des Agenten-OutputsEncoden des Ergebnisses + Logfile-Rotation.

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.

Hier sind unterhalb der Testsuite die beiden exemplarisch vergebenen Testvariablen zu sehen:

# Created by Check_MK Agent Bakery.
# This file is managed via WATO, do not edit manually or you
# lose your changes next time when you update the agent.

global:
   agent_output_encoding: utf_8
   cache_time: 120
   execution_mode: cmk_async
   log_rotation: '14'
   robotdir: C:\ProgramData\checkmk\agent\robot
   robotframework:
      console: ''
      log: ''
      report: ''
suites:
   selenium_test:
      variable:
         TOOL1: RobotFramework
         TOOL2: RobotMK

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:

Checkmk hat unsere Robot-Suite selenium_test als neuen Service erkanntDie Robot-Suite "selenium_test" wurde als neuer Service erkannt.

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

Detailansicht des neu erkannten ServicesDie Detailansicht des neu erkannten Robotmk-Services.

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:

RobotMK-Regel "discovered services" steuert die Interpretation der ServicesDie Robotmk-Regel für Discovered Services steuert, wie der RobotMK-Check Ergebnisse interpretiert

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.

Setzen von Schwellwerten und LeistungsdatenDie Regel zum Pattern-basierten Setzen von Runtime-Thresholds und Perfdaten.

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

RobotMK meldet LaufzeitüberschreitungenRobotmk meldet Laufzeitüberschreitungen.

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:

Frisch erstelle Graphen unserer TestsGraph für 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:

Aktivierung von Subnode-NachrichtenEinblenden der Sub-node-Nachrichten.

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.

Alarm mit Subnode-NachrichtOhne Sub-node-Messages.

Alarm ohne Subnode-NachrichtMit Sub-node Messages.

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:

Die Regel 'Service Discovery Level' in der WATODie Regel Service Discovery Level.

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:

XML-Knoten-Struktur eines Robot-ErgebnissesXML-Knoten-Struktur eines Robot-Ergebnisses.

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:

Festlegung eines benutzerdefinierten Präfix für neu erkannte ServicesSetzen eines benutzerdefinierten Präfix für neu erkannte Services.

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.

Neu erzeugte Services in CheckmkAuf Basis der Tests neu erzeugte Services.

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.

RobotMK liefert eine KontexthilfeDie Kontexthilfe von Robotmk.

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

Robotmk wird bereits produktiv in den Checkmk-Systemen großer IT-Umgebungen von Mobilfunk-Providern, Behörden und Hosting-Providern zum End2End-Monitoring geschäftskritischer Applikationen eingesetzt.
Die Verbesserung von Robotmk schreitet voran, regelmäßig kommen neue Features (siehe "Ausblick") hinzu. Die Versionen können für sich gesehen als "stabil" betrachtet werden; nicht immer ist aber garantiert, dass ein Update von Robotmk abwärtskompatibel ist.

Ausblick

Auf der Roadmap des Robotmk-Entwicklers steht unter anderem:

  • "Master"-Kontroll-Check, der den Zustand des Test-Setups und der Robotmk-Spoolfiles auf einem Host überwachen kann.
  • Neugestaltung der WATO-Regel zur Einstellung der Output-Detailtiefe.
  • Parallele Ausführung von Robot-Tests, individuelles Scheduling von Tests auf einem Host.
  • Docker-basierte Robotmk-Testcontainer.
  • JSON-basiertes Transportformat; Übermittlung von Robot-HTML-Logs samt eingebetteter Fehler-Screenshots zu Checkmk, Verarbeitung und Speicherung durch den Robotmk-Check; Aufruf der Logs per Action-Menü.
  • Entwicklung einer eigenen Robotmk-Library für Robot Framework. Mittels spezieller Keywords lassen sich beliebige applikationsinterne Werte (Metriken, Strings) zu Checkmk übermitteln und mit WATO-Regeln überwachen, um möglichst viel Auswertungs-Logik vom Robot-Test in Checkmk zu verlagern.

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

Wanted: IT Monitoring Superheroes

Do you have an interesting story about working with Checkmk?

We'd like to hear from you!

Learn more
checkmk superhero

By posting a comment to this blog article or by subscribing to our blog notification system, you agree to our Privacy and Cookie Policy and consent that tribe29 GmbH can process your data and may contact you, if needed, in regards to the above mentioned purposes.

We want to give you a good experience on this website.

In light of the General Data Protection Regulation, we are asking our audience to consent to the use of cookies by Checkmk and its partners to continue to our site.These cookies are used to personalize your user experience and support and improve the site. Please click “I Agree” below to consent to the use of this technology on the Checkmk website. Visit our Privacy Policy to learn more.

Your choices regarding cookies on this site.
Your preferences have been updated.
In order for the changes to take effect completely please clear your browser cookies and cache. Then reload the page.