Gestern auf dem Münchner Linux Stammtisch stand als Thema Monitoring auf dem Programm. Scheinbar so gut besucht wie nie, lauschten 62 Teilnehmer den Dozenten Mathias Kettner (mein Chef), der für Check_MK sprach, und Bernd Erk (von Netways), welcher Icinga 2 vorstellte.
Wie zu erwarten war, gab es natürlich eine Diskussion, welches Konzept das bessere ist. Einer der Diskussionspunkte war: “Ein Automatisches Discovery oder eine Manuelle bzw. CMDB gestützte Konfiguration?”
Klar, darüber kann man streiten. Discovery wurde als Argument für Check_MK gesehen, Manuelles Konfigurieren als Argument für Icinga. Was wohl aber gerne verdrängt wird: selbst der Manuelle Ansatz lässt sich mit Check_MK einfacher einrichten als mit Icinga. Statt mit dem Discovery zu arbeiten, kann man alle Checks auch manuell zuweisen. Ob man dies nun in Wato macht, in den Konfigurationsdateien, oder diese von einem externen Tool generieren lässt, kann man selbst entscheiden.
Einmal angeklickt, präsentieren sich die verschiedenen Check Typen:
Was ist nun aber der Vorteil, wenn man den manuellen Ansatz per Check_MK konfigurieren möchte? Die Regelbasierte Konfiguration:
Statt einen Check “Explicit” einem Host zuweisen zu müssen, kann man alternativ dazu die frei definierbaren “Host Tags” verwenden, oder auch einen Regulären Ausdruck (bei Verwendung einer Tilde am Anfang des Hostnamens wird der folgende String als regulärer Ausdruck behandelt).
Das Ganze findet sich dann wie folgt in den Konfigurationsfiles wieder:
static_checks['filesystem'] = [
( ('df', 'C:', {'levels': (80.0, 90.0)}), [], ['server1', 'server2'] ),
] + static_checks['filesystem']
Da es sich hier um Python handelt, ist es ein Leichtes, dies extern generieren zu lassen. Die Verwendung von Schleifen ist dadurch hier auch möglich.
Meine Meinung ist: Der Wunsch einer Manuellen Konfiguration ist weder ein Argument gegen Check_MK noch eines für Icinga.
Und jetzt nicht böse sein Bernd, du hast gestern gesagt: Die durchschnittliche Icinga Umgebung sind 10-20 Hosts. Bei Check_MK liegt sie (meine Erfahrung beim Consulting) etwas höher: zwischen 500 und 1000. Warum das so ist, konnte sich gestern sicher jeder denken :-)
Hallo Bestian
Gibt es eigentlich einen Performancevergleich zwischen Icinga 2 und Checkmk ?
grüße john s.
Hallo John,
man könnte nur Icinga 2 mit dem Check_MK Micro Core (cmc) vergleichen und selbst
das nicht wirklich. Check_MK ist ein komplettes Monitoring System. Mit einer Verbindung die oft unter einer Sekunde dauert
komme pro Host alle Checkergebnisse zurück. Das ist ein ganz anderes Konzept.
Würde man nur die Checkrate vergleichen kann ich mir aber denken wer schneller ist. Der CMC ist ein kleinstmöglich gehaltener Core der auf die Checkausführung optimiert ist. Das kann Icinga mit all seinen eingebauten Funktionen gar nicht schneller (Meine Meinung)
Hallo,
ich habe eine kleine Frage zu diesem Abschnitt:
“Die durchschnittliche Icinga Umgebung sind 10-20 Hosts. Bei Check_MK liegt sie (meine Erfahrung beim Consulting) etwas höher: zwischen 500 und 1000. Warum das so ist, konnte sich gestern sicher jeder denken :-)”
Jetzt nur rein aus Interesse: Wie kommen diese Zahlen zustande und sind sie wirklich repräsentativ? Sind das Zahlen aus produktiven Umgebunden oder werden hier evtl. auch Test-Installationen einbezogen und “verfälschen” somit die Zahlen, weil 10-20 Hosts…das ist ja wirklich mega wenig.
Die Nagios-Umgebungen, mit denen ich zu tun habe, enthalten i.d.R. auch zwischen 300-800 Hosts.
VG und Danke!
Tab
Hallo Tab,
die Zahl 10-20 wurde so von Bernd Erk aus dem Icinga Team so genannt.
Wie diese zustande kommt habe ich keine Ahnung.
Nochmal zu der Anzahl der Hosts:
Unabhängig von den genannten Zahlen geht ja daruas die Aussage hervor dass Icinga für kleinere Netzwerke “besser” oder zumindest häufiger in Verwendng ist als Check_mk.
Kann das jemand begründen?
Ich vergleiche z.Z. diverse Monitoring-Systeme und da check_mk und Icinga beide aus der Nagios ecke stammen (sage ichs mal so…) frage ich mich natürlich besonders worin sie sich unterschieden, also warum es gleich zwei Nagios-Altrnativen/Verbesserungen gibt.
Hi,
also ich muss sagen, das durch das einfache Discovery und dann auswählen was man monitoren will, check_mk es einem viel einfacher macht schnell eine Menge an checks zu haben, als wenn man sie manuell bei nagios/icinga anlegen müsste.
Leider ein Bericht, der zwanghaft auf check_mk zugeschnitten ist. Wir verwenden hier übrigens Icinga2 mit 2800 Hosts und ca. 24.000 Services. Also nichs mit 10 – 20 Hostobjekten ;-)
Zwanghaft nicht :) Ich bin halt ex Mitarbeiter und inzwischen Freiberuflicher Check_MK Consultant der zuletzt immer wieder Icinga 1 Umgebungen auf Check_MK migriert hat da dies einfacher war als die Migration zu Icinga 2 (true story).
Hallo,
hier sind leider zwei kritische Beiträge verschwunden. Nicht weil ich sie zensiert habe, sondern weil ich das automatische All in One WordPress export Backup vor ein paar Monaten aufgehört zu arbeiten hat. Und das war natürlich nicht im Monitoring. Nach dem Ausfall habe ich zwar problemlos die Seite wieder herstellen können, leider jedoch mit einer alten Sicherung.
Entschuldigung dafür.
Der damalige Ersteller der beiden Kommentare, wenn er das noch mal posten mag, sehr gerne.
Viele Grüße
Bastian Kuhn