Häufige Fragen

Beide beantworten unterschiedliche Fragen.

Checkmk überwacht Systeme: Läuft der Server? Ist die Datenbank erreichbar? Wie voll ist die Platte? Alle Ampeln können auf Grün stehen, während der Fachbereich meldet, dass die Bestellstrecke im Shop seit zwei Stunden hängt.

Robotmk schließt genau diese Lücke. Es bringt Synthetic Monitoring in Checkmk: automatisierte Tests, die Anwendungen so bedienen wie ein realer Anwender — einloggen, klicken, Formular abschicken, Ergebnis prüfen. Überwacht wird damit nicht mehr nur die Infrastruktur, sondern die Benutzererfahrung.

Ein zweites Werkzeug ist dafür nicht erforderlich: Die Testergebnisse erscheinen als reguläre Services in Checkmk — mit denselben Regeln, Benachrichtigungen und Dashboards wie alle übrigen Services.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Es sind zwei getrennte Projekte, die eng zusammenarbeiten.

Checkmk wird von der Checkmk GmbH entwickelt und vertrieben. Synthetic Monitoring ist dort fester Bestandteil des Produkts — inklusive Support und Dokumentation.

robotmk.org ist diese Seite: ein unabhängiges Projekt der ELABIT GmbH. Ich bin der Erfinder von Robotmk und arbeite in Teilzeit als Produktmanager bei Checkmk an der Integration mit. Parallel dazu setze ich Robotmk als Berater in Kundenprojekten ein.

Diese Doppelrolle ist der eigentliche Punkt: Praxiserfahrung aus Projekten fließt in die Produktentwicklung zurück — und das Produktwissen wird hier weitergegeben.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Nein. Robotmk ist Teil von Checkmk und wird ausschließlich über checkmk.com lizenziert — Synthetic Monitoring ist eine Subscription-Erweiterung der Checkmk-Installation.

Diese Seite bietet das Umfeld dazu: Wissen, Praxiserfahrung und auf Wunsch Unterstützung bei der Einführung.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Nicht mehr. Robotmk startete als Open-Source-Projekt auf GitHub und war jahrelang eine der meistinstallierten Checkmk-Erweiterungen.

Mit der Integration in Checkmk wurde daraus ein kommerzielles Produkt, das von der Checkmk GmbH entwickelt, gepflegt und supportet wird. Die frühere Open-Source-Version (v1) wird nicht mehr weiterentwickelt.

Die Robot-Framework-Welt selbst — das Framework und sein gesamtes Library-Ökosystem — bleibt davon unberührt und ist weiterhin vollständig Open Source.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Das ist nachvollziehbar — die Entscheidung ist mir nicht leichtgefallen.

Der Hintergrund: Ein Projekt dieser Größe benötigt verlässliche Weiterentwicklung, getestete Releases und belastbaren Support. Das ist nebenbei nicht zu leisten. Ein erheblicher Teil des heutigen Funktionsumfangs — die tiefe Integration in Checkmk, das automatische Environment-Management, die robuste Verarbeitung der Ergebnisse — wäre als nebenher gepflegtes Open-Source-Paket nicht entstanden.

Die kommerzielle Basis ist damit nicht der Preis für weniger Offenheit, sondern die Voraussetzung für den heutigen Funktions- und Qualitätsstand.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Keine. Diese Erwartung ist verbreitet, daher ausdrücklich:

Robotmk bzw. Synthetic Monitoring ist die Lösung, um Ergebnisse von Robot-Framework-Tests in Checkmk zu integrieren. Das Schreiben dieser Tests bleibt Aufgabe des Kunden — und das ist sachgerecht, denn die Kenntnis der eigenen Geschäftsprozesse liegt im Unternehmen.

Der Einstieg beginnt dabei nicht bei null: Das Robot-Framework-Ökosystem stellt fertige Libraries für praktisch jede Technologie bereit, und robotmk-starter enthält CI-getestete Beispiel-Testfälle als Ausgangspunkt.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Es steht inzwischen eine Reihe geeigneter Einstiege zur Verfügung:

• Checkmk-Dokumentation — die verbindliche Referenz für Synthetic Monitoring.
• Checkmk-YouTube-Kanal — unter anderem „Getting Started with Synthetic Monitoring“ (Testclient aufsetzen, ersten Test schreiben) und „Integrating Robot Framework tests in Checkmk“ (Robotmk konfigurieren, Services discovern, Monitoring einrichten).
• Robot Framework Slack — eine ausgesprochen hilfsbereite Community.
• Dieses Blog — Tutorials, Best Practices und Neuigkeiten aus der Praxis.
• robotmk-starter — CI-getestete Boilerplate-Testfälle als Referenz.
• Robotmk Academy — mein Online-Kurs, zugeschnitten auf Synthetic Monitoring mit Robot Framework und Checkmk. Er bereitet zugleich auf die RFCP-Prüfung (Robot Framework Certified Professional) vor. Details unter Services.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Nein. Das ist eine bewusste Entscheidung, keine fehlende Funktion.

Hintergrund der Frage ist meist der Vorbehalt gegenüber dem „Programmieren“. Robot Framework hat keine grafische Test-Oberfläche; die Tests werden als Code geschrieben. Dank der Keyword-Syntax ist dieser Code allerdings ausgesprochen gut lesbar — einer der Gründe, aus denen Robot Framework überhaupt entstanden ist.

Gegen einen Recorder spricht der Aufbau eines Tests. Er besteht aus drei Ebenen:

• der Test-Logik (was zu tun ist),
• der Test-Technik (wie es umgesetzt wird),
• den Testdaten (womit getestet wird).

Ein Recorder vermischt alle drei. Das Ergebnis wirkt zunächst brauchbar, skaliert aber nicht: Jeder ähnliche Test muss erneut aufgezeichnet werden, und bei Änderungen an Anwendung, Logik, Technik oder Testdaten sind sämtliche betroffenen Tests neu aufzunehmen. Der Codebestand wächst dabei schnell ins Unwartbare.

Robot-Framework-Code lässt sich stattdessen schichten: Die oberste Keyword-Ebene beschreibt allein die Logik („WAS wird getestet?“), die darunterliegende Ebene die Teilschritte mit den Testdaten, die unterste die technische Umsetzung. Änderungen betreffen dann genau eine Schicht.

Ein Vergleich aus der HiFi-Technik verdeutlicht das Prinzip: Eine Anlage aus Einzelkomponenten — Quelle, Verstärker, Lautsprecher — weist jeder Komponente eine Aufgabe zu. Jede lässt sich reparieren, ersetzen und modernisieren; solche Anlagen halten entsprechend lange. Test-Recorder entsprechen Kompaktanlagen: zunächst praktisch, im Fehlerfall aber kaum zu reparieren, weil alles in einem Gehäuse verbaut ist.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Eine Suite ist eine Textdatei mit Robot-Framework-Code, in der ein oder mehrere Tests (auch „Test Cases“ genannt) beschrieben sind. Robotmk führt diese Suites auf den überwachten Hosts aus — unter Windows wie unter Linux.

Suites dienen in erster Linie der Gruppierung von Tests.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Ein Test Case ist ein einzelnes Szenario, das einen bestimmten Aspekt einer Anwendung prüft. Eine Suite kann mehrere Test Cases enthalten, die nacheinander ausgeführt werden.

Test Cases sollten so granular wie möglich gehalten werden: Ein Test Case = ein Szenario. Das erleichtert die Wartung, macht die Ergebnisse aussagekräftiger und erlaubt eine gezieltere Alarmierung.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Keywords sind die Bausteine, aus denen Tests bestehen. Sie verhalten sich wie Funktionen in einer Programmiersprache: Sie nehmen Parameter entgegen, können Rückgabewerte liefern und lassen sich beliebig tief ineinander verschachteln.

Genau diese Verschachtelung macht Robot-Framework-Tests lesbar und langfristig wartbar.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Der Robotmk-Check auf dem Checkmk-Server wertet die Rohdaten der Robot-Framework-Ausführungen aus und legt für jeden Test einen eigenen Service an — den Test-Service.

Dieser Service zeigt den Zustand des Tests (erfolgreich / fehlgeschlagen), beinhaltet dessen menschenlesbares HTML-Logfile und alarmiert auch bei Laufzeitüberschreitungen.

Die Summe aller Test-Services innerhalb einer Checkmk-Subscription bestimmt den Umfang für Synthetic Monitoring — sie ist die einzige Größe, die für die Lizenzierung zählt.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Unterstützt werden Windows- sowie Debian-/Ubuntu-Testclients mit mindestens 4 CPU-Kernen und 8 GB RAM.

Der Client muss von Checkmk überwacht werden können und sollte Internetzugang haben, damit die benötigten Python-Umgebungen automatisch aufgebaut werden können.

Die jeweils aktuellen und verbindlichen Anforderungen stehen in der Checkmk-Dokumentation.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Alle Tests, die die grafische Oberfläche einer lokal installierten Anwendung bedienen — etwa SAP GUI, Citrix-Clients oder klassische Windows-Software. Ohne angemeldete, entsperrte Benutzersitzung existiert dort keine bedienbare Oberfläche. Das ist keine Einschränkung von Robotmk, sondern eine technische Grundbedingung.

Alles, was ohne GUI auskommt, läuft headless — also ohne Desktop-Sitzung. Dazu zählen auch Web-Tests: Firefox, Chromium und WebKit lassen sich im Headless-Modus betreiben.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

v1 war die Community-Erweiterung: ein MKP, das eigenständig installiert und gepflegt wurde. Die Python-Umgebungen auf den Testclients mussten von Hand aufgesetzt und aktuell gehalten werden.

v2 ist Synthetic Monitoring als fester Bestandteil von Checkmk. Die wesentlichen Unterschiede:

• Integriert statt nachinstalliert — Konfiguration über die reguläre Checkmk-Regelverwaltung, kein separates MKP.
• Automatisches Environment-Management über RCC: Pro Suite wird in einer YAML-Datei beschrieben, was der Test benötigt; die passende Umgebung entsteht auf dem Client selbstständig und reproduzierbar.
• Offizieller Support und Dokumentation durch die Checkmk GmbH.
• Deutlich robustere Ausführungssteuerung und Ergebnisverarbeitung.

v1 wird nicht mehr weiterentwickelt.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Schrittweise — ein Stichtagswechsel ist nicht erforderlich.

Das v1-MKP lässt sich auf Checkmk 2.3+ parallel installieren und beeinträchtigt das integrierte v2 nicht. Die Migration kann daher Suite für Suite erfolgen, während der übrige Bestand unverändert weiterläuft.

An den Robot-Framework-Suites selbst ist keine Änderung nötig. Der einzige zusätzliche Schritt: Je Suite ist eine Environment-Spezifikation (YAML) zu erstellen, damit die passende Umgebung automatisch erzeugt werden kann.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Ja. Bis zu drei Test-Services lassen sich in Checkmk ohne Subscription betreiben — im sogenannten „Free Tier“ genügt das, um Synthetic Monitoring mit echten Tests in der eigenen Umgebung kostenlos zu evaluieren.

Zu beachten ist dabei: Dieses Kontingent ist ein Testangebot, kein Dauerrabatt. Mit Abschluss einer Synthetic-Monitoring-Subscription entfallen die drei freien Test-Services. Ab diesem Zeitpunkt gilt der Einsatz als produktiv — und da jedem produktiv überwachten Test-Service ein Gegenwert gegenübersteht, zählt dann jeder einzelne in den Umfang der Subscription.

Die jeweils gültigen Konditionen sind auf checkmk.com dokumentiert.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Nichts — abgesehen von einer höheren Auflösung der Testdaten.

Genau an dieser Stelle steigen die Kosten bei aktionsbasierten Wettbewerbern: Dort wird pro Testlauf oder pro Aktion abgerechnet. Bei Checkmk bleiben die Kosten konstant, weil ausschließlich die Anzahl der Test-Services zählt.

Die Tragweite dieses Unterschieds ist unter Warum Robotmk im Detail vorgerechnet.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Dafür genügen zwei Kennzahlen des Bestandssystems:

1. die Anzahl der Metriken bzw. Zustände, die es heute liefert, und
2. die durchschnittliche Laufzeit der zugrunde liegenden Tests.

Die erste Zahl entspricht näherungsweise der Anzahl der in Checkmk benötigten Test-Services — und damit dem Umfang der Subscription. Für eine erste belastbare Abschätzung ist mehr nicht erforderlich.

Gerne bin ich behilflich, die Zahlen im Rahmen eines Clarity Callsin eine konkrete Checkmk-Subscription zu übersetzen.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Standorte sind für die Lizenzierung keine eigene Größe — ebenso wenig wie die Anzahl der Robotmk-Hosts in Checkmk. Es wird weder pro Standort noch pro Host abgerechnet.

Maßgeblich ist ausschließlich die Gesamtzahl der Test-Services innerhalb einer Subscription. Wird dieselbe Suite an mehreren Standorten ausgeführt, entstehen dort jeweils eigene Test-Services — der Preis folgt jedoch weiterhin dieser einen, gut planbaren Größe.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Nein.

Das Ausführungsintervall der Robot-Framework-Suites ist vollständig unabhängig vom Check-Intervall des Checkmk-Agenten. Der Agent übernimmt lediglich die zuletzt vorliegenden Ergebnisse; die Häufigkeit dieser Abholung hat auf die Lizenzierung keinen Einfluss.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Ja, vollständig. Robot Framework und seine Libraries sind Open Source und frei verfügbar — Browser-Automatisierung, SAP, Citrix, REST, Datenbanken und vieles mehr. Der Einstieg ist unmittelbar möglich, ohne vorherigen Erwerb.

Eine Subscription ist erst für Robotmk erforderlich — die Integrationsschicht, die Robot-Framework-Tests mit Checkmk verbindet. Bis zu drei Test-Services lassen sich zur Erprobung ohne Subscription betreiben.

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →

Noch offen? Frage direkt über das Chat-Widget einreichen. Oder kostenlosen Clarity Call buchen →