© Mykhailo Orlov / 123rf.com

Die beiden Monitoring-Giganten Icinga und Checkmk haben zwar einiges gemeinsam, unterscheiden sich aber auch in vielen Punkten. Wir untersuchen, welche der beiden Lösungen sich für welchen Zweck besser eignet.

Moderne Setups sind ohne Monitoring schlicht undenkbar, es geht nicht ohne. In der Haut eines Administrators, der sich für eine Monitoring-Lösung entscheiden muss, möchte man indes auch nicht stecken, denn das Angebot ist riesig. In den vergangenen Jahren hatten die Anwendungen für Monitoring, Alerting und Trending massiven Zulauf. Sie basieren im Kern auf einer Zeitreihendatenbank und produzieren klassisches Monitoring eher als eine Art Nebenprodukt (Abbildung 1). Damit funktionieren sie intern völlig anders als die klassischen Monitoring-Werkzeuge der Linux-Welt, etwa Nagios oder Zabbix.

Abbildung 1: Metriksammler wie Prometheus im Gespann mit Grafana graben konventionellen Monitoring-Systemen das Wasser ab. Doch auch Icinga 2 und Checkmk liefern mittlerweile entsprechende Funktionalität. Quelle: Stars Liao, Github

Auch aus Deutschland kommen mehrere Tools, die sich bei Admins großer Beliebtheit erfreuen. Dazu gehören der einstige Nagios-Spinoff Icinga [1] sowie Checkmk [2], das dessen Autor Matthias Kettner ebenfalls auf Basis von Nagios startete. Inzwischen ist es aber wie Icinga längst flügge geworden und hat den kompletten alten Nagios-Core hinter sich gelassen.

Tatsächlich sprechen gute Gründe für den Einsatz dieser Lösungen. Beide sind am Markt gut etabliert, haben eine aktive Community und erfreuen sich umfassenden kommerziellen Supports der jeweiligen Hersteller. Doch auch die Unterschiede zwischen den Werkzeugen fallen durchaus beachtlich aus: Icinga ist, obgleich man es heute an vielen Stellen kaum mehr erkennt, ein Spinoff von Nagios und hat dessen Design-Prinzipien und Denkansätze bis heute in vielerlei Hinsicht beibehalten. Checkmk kann zwar Nagios- und damit auch Icinga-Plugins nutzen, funktioniert unter der Haube aber völlig anders. Das äußert sich in einer anderen Nutzererfahrung.

Dieser Artikel fühlt beiden Lösungen in direkten Vergleich auf den Zahn und geht auf ihre Stärken und Schwächen ein. Im Fokus steht dabei die Praxis: Wie einfach gelingt das Setup, wie leicht lassen sich neue Systeme und Dienste in die Lösung integrieren, wie gut skaliert das Produkt? Bietet das jeweilige System neben dem klassischen Monitoring von Diensten Zusatzfunktionen, zum Beispiel für das Trending? Welche Möglichkeiten stehen in Sachen Lizenz und Support zur Verfügung?

Grundlagen: Icinga

Weil das Monitoring-System in einem Setup eine absolut essenzielle Komponente ist, muss der Administrator dessen Architektur aus dem Effeff beherrschen. Zwischen Icinga und Checkmk ergeben sich dabei fundamentale Unterschiede, die zum Teil aus der Geschichte der Lösungen resultieren.

Icinga bestand bisher im Kern aus einer Datenbank (meist MySQL) mit einem Daemon, dem IDO, um Daten zentral zu speichern. Augenblicklich befindet sich die Software jedoch in einer Phase des Übergangs: Das bisherige IDO-Konstrukt ersetzt eine eigens für Icinga entwickelte Datenbank namens Icinga DB, die im Hintergrund auf Redis aufbaut. Der Dienst, der die Monitoring-Daten zusammenträgt und in die Datenbank einträgt, heißt Icinga 2. Er ist bis heute teilweise mit Nagios kompatibel, beruht aber auf praktisch völlig eigenständigem Code. Das Webinterface ist bei Icinga traditionell eine separate Komponente, die sich mit mehreren Icinga-Instanzen verbinden lässt (Abbildung 2).

Abbildung 2: Von der angestaubten Optik vergangener Tage ist bei Icinga 2 nichts mehr zu sehen. Icinga Web kommt als eigenständige Komponente daher und entspricht dem State of the Art. Quelle: Icinga

Viel Liebe haben die Icinga-Macher in die Skalierbarkeit ihrer Lösung gesteckt: Icinga 2 lässt sich im Master-Modus mit zahllosen Slave-Instanzen betreiben; auch Multi-Master-Setups sind möglich, was Hochverfügbarkeit unterstützt. Die faktische Trennung des eigentlichen Monitorings von der Datenablage, die durch die Icinga DB ein neues Level erreicht, ermöglicht diese Art der Funktionalität erst.

Der Kern von Icinga, also das eigentliche Icinga 2, vereint sämtliche Funktionen zur Überwachung und Alarmierung. Dabei funktioniert die Architektur einzelner Tests bei Icinga bis heute so wie bei Nagios auch: Im Filesystem liegen Dateien, die einzelne Checks vornehmen und via Textausgabe und Rückgabewert ein Ergebnis liefern. Dieses Resultat leitet Nagios einerseits dazu an, definierte Aktionen zu starten. Andererseits beschränkt das System die möglichen Zustände, die Nagios für einen Test kennt: Hier stehen bis heute lediglich die vier Optionen »OK«, »WARNING«, »CRITICAL« und »UNKNOWN« zur Verfügung. So bleibt Icinga komplett kompatibel zu Nagios-Checks. Mehr Komplexität wäre auf dieser Ebene ohnehin nicht automatisch besser.

Grundlagen: Checkmk

Beschäftigt man sich mit der Checkmk-Architektur, liegen die Dinge ein wenig anders. Wie eingangs erwähnt, fußte auch Checkmk ursprünglich im Kern auf Nagios und ließ sich lange auch mit dem Nagios-Core betreiben. Letzterer entspricht dabei ganz grob dem, was Icinga bis heute an Funktionalität in Icinga 2 verbaut.

Langfristig zufrieden war man bei Checkmk mit dieser Lösung aber nicht und begann langsam, sich von Nagios zu entfernen. Eine Art endgültiger Bruch fand statt, als die Checkmk-Entwickler Nagios als Kernkomponente durch CMC ersetzten, den Checkmk Micro Core. Er fungiert als zentrale Schnittstelle, um die eingehenden Ergebnisse von Nagios-Checks zu verarbeiten und Alarme sowie Benachrichtigungen zu generieren.

Die Einschränkung auf Nagios-Checks ist an dieser Stelle von Bedeutung, denn hier ergibt sich ein zentraler Unterschied zwischen Icinga und Checkmk. Während Icinga auf das klassische Check-Format von Nagios setzt, haben die Checkmk-Entwickler ihrer Lösung mittlerweile eine eigene Check-Engine spendiert. Sie dient als zentrale Anlaufstelle für Tests und soll nur noch dort durch Nagios-Checks ersetzt werden, wo Checkmk selbst keine entsprechenden Funktionen bietet.

Ganz ähnlich verhält es sich bei Checkmk im Vergleich mit Nagios bei der grafischen Oberfläche (Abbildung 3): Auch sie kommt als externe Komponente daher, redet im Hintergrund über definierte Interfaces mit dem CMC und exponiert ihrerseits wiederum eine Vielzahl von Schnittstellen zur Außenwelt. In der GUI spielt sich dabei ein großer Teil der Checkmk-Funktionalität ab: Konfigurationsänderungen, die Auswertung von Metrikdaten und deren grafische Darstellung, Hard- und Softwareinventare sowie das Reporting realisiert Checkmk unmittelbar in der grafischen Oberfläche.

Abbildung 3: Über die moderne Benutzeroberfläche von Checkmk lassen sich alle zentralen Aspekte der Lösung steuern. Die GUI hat vielfältige Darstellungsmöglichkeiten in petto. Quelle: Checkmk

Grundsätzlich unterscheiden sich Icinga und Checkmk im Kern mittlerweile zwar in vielerlei Hinsicht, andere Aspekte des Designs bleiben hingegen bis heute ähnlich oder sogar identisch. Das dürfte nicht zuletzt auf den gemeinsamen Urahn Nagios zurückzuführen sein.

Automatische Erkennung

In einem zentralen Aspekt unterscheiden die Lösungen sich dann aber doch, und der hat auf den Alltag von Administratoren durchaus unmittelbare Auswirkungen.

Die Checkmk-Entwickler nahmen die Implementierung einer eigenen Check-Engine nicht zuletzt deswegen in Angriff, um ein Auto-Discovery-Feature zu ergänzen. Es nimmt dem Admin die Arbeit ab, beim Hinzufügen von Servern die Konfiguration des Monitorings anzupassen, um den neuen Host oder Dienst im Monitoring-System bekannt zu machen. Stattdessen erkennt Checkmk neue Systeme und Dienste automatisch, versieht sie mit den passenden Checks und übernimmt sie direkt in das Setup. Die Lösung lässt dem Administrator freilich die Möglichkeit, im Nachgang Feinjustierungen auszuführen. Insgesamt senkt sie den Aufwand gegenüber dem manuellen Hinzufügen eines Hosts zum Setup signifikant, was sich in der Praxis schnell bemerkbar macht.

Auch Icinga wurde in den vergangenen Jahren deutlich weiterentwickelt, was das Setup von Checks und insbesondere Hosts angeht. Hier muss der Admin aber letztlich noch immer jeden aus der Ferne zu überwachenden Host und Dienst manuell in ein relativ komplexes Konstrukt in der Icinga-Konfiguration eintragen.

Die Icinga-Entwickler verweisen darauf, dass sie davon ausgehen, dass Administratoren ihre Icinga-Konfiguration ohnehin nicht mehr selbst warten. Dafür käme heute üblicherweise ein Werkzeug für das Management der Konfigurationsdateien zum Einsatz wie Chef, Puppet oder Ansible. Das wiederum kenne ja auf Grundlage des eigenen Inventars zwangsläufig ohnehin jeden Dienst und jede Maschine im Setup. Das ermögliche, die entsprechende Konfiguration direkt aus dem Konfigurationsmanagement heraus automatisch zu erstellen.

Dieser Ansatz greift in manchen Fällen allerdings zu kurz. So kann es in einem Setup durchaus Komponenten der Infrastruktur geben, die gar nicht Bestandteil von Puppet & Co. sind, weil sie sich mit diesen Diensten ohnehin nicht betanken lassen. Hier erweist sich der All-inclusive-Ansatz von Checkmk als praktischer, denn bei diversen Scans findet er auch solche Geräte automatisch und macht sie zu konfigurierbaren Einheiten in der eigenen Datenbank.

Problemloses Setup

Das führt zwangsläufig zur nächsten Frage, nämlich nach der Komplexität einer neu zu bauenden Monitoring-Lösung. Jeder Admin gelangt bei einem neuen Setup irgendwann an den Punkt, an dem er technisch ein Monitoring benötigt, es real aber noch nicht existiert.

Durch Docker, LXC und Podman hat sich bei Admins im Hinblick auf kritische Infrastrukturdienste in den letzten Jahren eine Art Vollkasko-Mentalität etabliert: Wo man früher noch händisch Pakete auf zuvor mühsam ausgerollten und konfigurierten Systemen installierte und mittels Ansible & Co. eine passende Konfiguration ausrollte, erwarten viele Admins heute eher Container samt passender Integration. Das heißt nicht zwangsläufig Kubernetes, bedeutet aber sehr wohl, dass man die Dienste eines Systems entsprechend vorzufinden erwartet.

Die Ansätze von Icinga und Checkmk im Hinblick auf ein einfaches Setup unterscheiden sich fundamental voneinander. Checkmk spielt auf der Hipster-Klaviatur das volle Programm und liefert seine verschiedenen Editionen in Form von Docker-Containern aus. Die Dokumentation enthält Hinweise, die das Ausrollen der Container erleichtern sollen und für verschiedene Situationen auch Troubleshooting-Tipps enthalten. Entsprechend gilt das Deployment von Checkmk per Docker als offiziell unterstützte Installationsvariante. Die Anzahl an Konfigurationsdateien oder geänderten Dateien, die der Admin den offiziellen Containern mit auf den Weg geben muss, hält sich in engen Grenzen: Die meisten Details von CMC und der Check-Engine lassen sich über die Interfaces steuern, die den Checkmk-Containern ebenfalls beiliegen.

Bei Icinga liegen die Dinge ein wenig anders. Auch von Icinga 2 gibt es auf Docker Hub Container, die das Projekt selbst pflegt und weiterentwickelt. Im Usage-Teil der Container-Beschreibung finden sich auch Anleitungen hinsichtlich der für die Container zu übergebenden Parameter, um etwa ein Master-Agent-Setup zu erreichen oder Icinga eine eigene Konfigurationsdatei mitzugeben. Alternativ kann der Node Wizard zum Einsatz kommen, ein Hilfsprogramm, das das Setup eines Knotens übernimmt und dabei vom Admin nur die unbedingt notwendigen Werte erfragt.

Eigentlich wünschen sich die Icinga-Entwickler aber einen anderen Deployment-Weg, um ein standardkonformes Icinga-Setup auszurollen. Dazu gibt es ein eigenes Werkzeug namens Icinga-installer, das nicht auf Container setzt, sondern auf einem passend vorbereiteten System die entsprechenden Icinga-Pakete samt Begleitdiensten und passender Konfiguration ausrollt. Was dem einen oder anderen Administrator dabei möglicherweise etwas sauer aufstößt: Diese Methode des Setups hat eine komplette Instanz von Puppet im Schlepptau, die es auf dem jeweiligen System einrichtet. Wer in seiner Umgebung bis dato also kein Puppet hatte, bekommt es dank der Icinga-2-Installation quasi übergebügelt – falls man nicht doch vom empfohlenen Weg abweicht und lieber auf die Container setzt.

In Summe ergeben sich hier also leichte Vorteile für Checkmk: Es nutzt eine sehr einfache Methode als Standard, statt eine komplexe Automationslösung quasi zur Bedingung für eine laufende Instanz zu machen. Der Vorsprung in Sachen Setup ist allerdings hauchdünn; wer Icinga im Kontext eines Container-Setups zum Laufen bekommen möchte, schafft das dank der offiziellen Abbilder ebenfalls. In Summe sind die technischen Unterschiede hier nicht gewichtig genug, um das Zünglein an der Waage deutlich zu beeinflussen.

Performance: Keine Blöße

Das beste Monitoring ist nichts wert, wenn es unter der Last eingehender Anfragen zusammenbricht. Tatsächlich wurden gerade Monitoring-Lösungen auf Nagios-Basis früher regelmäßig zum Nadelöhr einer Umgebung. So mancher Admin dürfte sich mit Schaudern an Momente erinnern, in denen das eigene Monitoring Sekunden statt Millisekunden brauchte, um auch nur die Statusanzeige zu präsentieren.

Diese Zeiten sind allerdings vorbei. Bei Icinga wie bei Checkmk flossen viele Stunden Arbeit in die Optimierung des Codes, auch im Hinblick auf dessen Geschwindigkeit – zum Glück: Gerade die großen skalierbaren Setups der Gegenwart stellen Monitoring-Tools vor ganz andere Herausforderungen als die im Vergleich dazu fast schon als niedlich zu bezeichnenden Mini-Setups der Vergangenheit. Bei Checkmk bietet allerdings nur die Enterprise-Edition der Lösung den entsprechend leistungsfähigen CMC. Auf die Checkmk-Varianten gehen wir im Folgenden noch im Detail ein, ebenso auf die kommerziellen Verteilmöglichkeiten von Icinga 2.

Der technische Ansatz der Lösungen, die schnelles und gutes Monitoring auch in großen Umgebungen ermöglichen, ist dabei übrigens durchaus ähnlich. Beide Werkzeuge erlauben ein Skalieren in die Breite – falls das überhaupt nötig sein sollte: Sowohl Icinga 2 als auch Checkmk sind mit einer einzelnen Instanz bereits problemlos in der Lage, über 2500 Hosts zu überwachen.

Skalierbarkeit

Falls eine einzelne Instanz von Icinga 2 oder Checkmk an die Grenzen ihrer Möglichkeiten stößt, bieten beide Lösungen eine Cluster-Funktion für das Skalieren in die Breite. Die funktioniert im Kern sogar ähnlich.

Bei Icinga muss es eine Master-Instanz geben, die Monitoring-Ergebnisse von verschiedenen Satellite-Instanzen empfangen und verarbeiten kann. Die Satellites übernehmen die eigentliche Monitoring-Arbeit und treiben Überwachungsergebnisse ein (Abbildung 4). Die Master-Instanz betätigt sich in diesem Modus im Grunde genommen nur noch als große Datenbank. Dadurch vermag sie ein Vielfaches der Arbeitsschritte abzuarbeiten, die eine Icinga-2-Instanz leisten kann, die selbst auch für das Ausführen der Checks verantwortlich ist. Zwar hat dieser Deployment-Modus ein theoretisches Limit, das im Fall eines Icinga-2-Setups mit multiplen Satelliten allerdings kaum ein Administrator je ausreizen dürfte.

Abbildung 4: Auch verteiltes Monitoring mit einer Master-Instanz und vielen Satellites beherrscht Icinga. Damit muss es sich in Sachen Skalierbarkeit nicht vor der Konkurrenz aus dem Cloud-Ready-Lager verstecken. Quelle: Icinga

Technisch ähnlich funktioniert das Skalieren bei Checkmk. Hier vernetzen sich in der Enterprise-Edition auf Zuruf des Admins mehrere Instanzen des CMC zu einem Cluster. Dazu aktiviert man die Funktion Livestatus und verbindet die CMC-Instanzen anschließend über die Distributed-Monitoring-Funktion (Abbildung 5). Pro Host lässt sich dann festlegen, welche der konfigurierten Checkmk-Instanzen das Monitoring ausführen soll, was freilich auch im Batch funktioniert.

Am Ende steht ein Setup, das einem Master-Satellite-Setup von Icinga in vielerlei Hinsicht ähnelt, auf der Anwendungsseite aber ein wenig mehr Konfigurationsmöglichkeiten bietet. An Grenzen der Monitoring-Funktionalität wird der Administrator auch mit Checkmk jedenfalls kaum jemals stoßen.

Abbildung 5: Wer die Enterprise-Edition von Checkmk nutzt, kann verschiedene CMC-Instanzen zu einem Cluster für verteilte Monitoring-Setups zusammenschalten. Quelle: Checkmk

Trending

Monitoring-Gurus verdrehen beim Schlagwort Trending genervt die Augen. Dennoch gehört das Thema in den skalierbaren Setups der Gegenwart auf den Tisch. Freilich hätten Administratoren die Möglichkeit, das Trending komplett extern zu betrachten und etwa ein Konstrukt aus InfluxDB und Grafana zu bauen, um das Thema abzufrühstücken.

Völlig zu Recht werden Kritiker dann aber einwenden, dass das einerseits einen zusätzlichen Point of Administration schafft und andererseits zusätzliche Last für die zu überwachenden Systeme impliziert. Schließlich grast das Monitoring ja alle Hosts und Services sowieso regelmäßig ab. Da liegt es auf der Hand, die einzusammelnden Metrikdaten gleich mitzunehmen und entsprechend zu verarbeiten. Dieser Umstand ist es, der die Popularität insbesondere von Prometheus überhaupt erst erklärt. Allerdings hatten traditionell weder Icinga noch Checkmk einen sonderlich funktionalen Ansatz im Hinblick auf Metrikdaten.

Icinga erbte von seinem Urahn PNP4Nagios, das jedoch stets daran krankte, dass es Zeitreihendaten in eine relationale Datenbank pressen wollte und dadurch mit zunehmendem Datenumfang quasi automatisch immer langsamer wurde. Diese Zöpfe hat Icinga allerdings längst abgeschnitten und bietet offiziell Trending für Metrikdaten an, teilt die Arbeit hinter den Kulissen aber in mehrere Arbeitsschritte ein. Den ersten Schritt erledigt Icinga selbst – oder eher die Checks, die der Administrator ausrollt. Ihnen fällt in diesem Konstrukt die Aufgabe zu, die Metrikdaten einzusammeln und an Icinga zurückzuspielen.

Icinga speichert die Daten dann aber anders als früher nicht selbst ab, sondern leitet sie beispielsweise an Graphite oder InfluxDB weiter. Bei beiden Lösungen handelt es sich um Zeitreihendatenbanken und mithin um exakt jene Art von DBMS, die solche Daten speichern sollte. Die grafische Darstellung lässt sich dann mittels Graphite, InfluxDB oder Grafana realisieren, und zumindest die Graphite-Darstellungen lassen sich unmittelbar auch in das Icinga-Webinterface einbinden. Hier gibt es also nur einen grafischen Point of Administration, was sehr zur Einfachheit der Bedienung beiträgt.

Einmal mehr handhabt Checkmk die Dinge durchaus ähnlich. Anders als Icinga kommt es aber ohne externe Komponente aus, um die Metrikdaten zu verarbeiten. Es setzt stattdessen auf RRD und sammelt die Daten der Zielsysteme in diesem Format ein. Checkmk speichert die Daten dann auch autark ab und verfügt in seiner grafischen Oberfläche mittlerweile über eigene Dashboard-Funktionen, um aus den RRD-Daten ansprechende, grafische Darstellungen zu erzeugen. Komplementär lassen sich Dienste wie Grafana ankoppeln, falls der von Checkmk selbst gebotene Funktionsumfang für eine spezifische Funktion nicht ausreicht. Das kann durchaus passieren, denn in Checkmk steht keine Query-Sprache zur Verfügung, die es mit der InfluxDB-Syntax oder mit PromQL von Prometheus aufnehmen könnte.

In Summe gilt, dass sich Metrikdaten (und in deren Gefolge auch Log-Daten) sowohl in Icinga 2 als auch in Checkmk darstellen lassen. Icinga kann entsprechende Daten über seine Checks einsammeln, in Checkmk übernimmt diese Funktionalität CMC selbst. Checkmk zeigt sich an dieser Stelle etwas umfangreicher, weil es das Auswerten der Metrikdaten selbst übernimmt. Im Gegenzug bekommen Icinga-Kunden mehr Flexibilität, denn durch das Weiterleiten der gesammelten Daten an Graphite oder InfluxDB stehen mehr Funktionen zur Verfügung als in der selbst gebauten Auswertungszentrale von Checkmk. “One tool for one job” gilt auch hier.

Editionen und Kosten

Bei einem Vergleich der beiden Lösungen darf die Frage nach den Kosten nicht fehlen. An dieser Stelle ergeben sich deutliche Unterschiede. Bei Icinga umfasst die Open-Source-Version sämtliche Funktionen der Software, die mithin jedem Administrator zur Verfügung stehen. Wer hier Geld für Support ausgibt, erhält Zugriff auf ein kuratiertes Paketverzeichnis mit geprüften Paketen und – abhängig vom gebuchten Level – auch technische Unterstützung. Subskriptionsvarianten, die bestimmte Funktionen erst freischalten, gibt es bei Icinga nicht.

Checkmk handhabt die Finanzen anders: Wer es produktiv einsetzen möchte, braucht im Grunde die Enterprise-Edition. Nur sie enthält CMC und damit das Gros der schönen Dinge, die sich Admins wünschen. Dafür fallen Gebühren an: Wer mit der auf 25 Knoten limitierten Free-Variante nicht auskommt, zahlt mindestens 780 Euro pro Jahr für 3000 zu überwachende Dienste. Laut Checkmk entspricht das etwa 100 Hosts. 1000 Hosts entsprechen 30 000 Diensten und schlagen mit 4500 Euro pro Jahr zu Buche, jedoch bei jährlicher Abrechnung. Angesichts des gebotenen Funktionsumfangs erscheint das aber keineswegs übertrieben. Verglichen mit anderen Werkzeugen, für die schnell fünf- bis sechsstellige Lizenzgebühren anfallen, nimmt Checkmk sich hier angenehm zurück.

Fazit

Wer im Duell zwischen Icinga und Checkmk einen eindeutigen Gewinner erwartet hat, sieht sich eines Besseren belehrt. Zwar hat je nach Disziplin mal das eine und mal das andere Werkzeug die Nase vorne, fundamentale Qualitätsunterschiede zwischen den Lösungen ergeben sich aber nicht. Sowohl mit Icinga 2 als auch mit Checkmk lassen sich kleine und große Setups vorzüglich überwachen.

Dass es sich bei beiden Werkzeugen um Nagios-Nachfahren handelt, merkt man ihnen im Alltag an, aber nicht in einer Art und Weise, die negativ auffiele. Manche Dinge erledigt Icinga anders als Checkmk, aber auch hier zählt eher die persönliche Präferenz des Administrators als die Qualität der Technik: Die erweist sich in jeder überprüften Disziplin dieses Vergleichs sowohl bei Icinga als auch bei Checkmk als makellos.

Wer eine der beiden Lösungen im eigenen RZ einführen möchte, tut vermutlich gut daran, sowohl Icinga 2 als auch Checkmk ausgiebig zu evaluieren. Hauptaugenmerk sollte dabei darauf liegen, welche Herangehensweise und welche Schnittstelle den eigenen Bedürfnissen eher entspricht. Weil harte Parameter wie Leistungsfähigkeit, Performance oder Qualität der implementierten Dienste nicht taugen, um eine Entscheidung zwischen beiden Lösungen zu treffen, müssen letztlich die weichen Kriterien herhalten.

Ganz unabhängig davon dürfen aber sowohl Icinga 2 als auch Checkmk als Schmuckstück der deutschen Ingenieurskunst gelten. Beide bestanden in unserem Vergleich sämtliche Prüfungen mit Bravour. (jcb)