Archiv der Kategorie: omd

Check_MK vs Icinga?

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.

Link zu den Manual Checks
Link zu den Manual Checks in Wato

Einmal angeklickt, präsentieren sich die verschiedenen Check Typen:

Liste der Manual Checks in Wato
Unvollständige Liste der Manual Checks in Wato

Was ist nun aber der Vorteil, wenn man den manuellen Ansatz per Check_MK konfigurieren möchte? Die Regelbasierte Konfiguration:

Maske zum manuellen anlegen eines Checks
Maske zum manuellen Anlegen eines Checks

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:

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

Backup von OMD

Wer sich schon mal gefragt hat wie man seine OMD Installation sichern oder gar auf einen neuen Server übertragen kann,
der kann sich über ein neues Feature freuen welches Lars Michelsen letzte Woche in OMD eingebaut hat. Es handelt sich um eine Backup und Restore Funktion.

Backup

Sichert man innerhalb der Site reicht bereits,  das Kommando mit einem Zielpfad aufzurufen.

Als Root ist vor dem Backup Zielpfad nur die Angabe des Sitenamen nötig. Gibt man übrigens anstelle eines Zielpfades ein minus ein, wird das Backup auf STDOUT geschrieben.

Restore

Dieser klappt zur Zeit nur als root:

Hier kann man jetzt praktischerweise gleich noch einen neuen Sitenamen mit angeben.  Ersetzt man den Pfad hier mit einem minus,  liest das Kommando von STDIN.

Alle Fragen dazu beantwortet:

 

Monitoring mit OMD Einführung und Vorteile

Aufgrund einiger Nachfragen nach dem, was die OMD eigentlich ist, nun eine kleine Einführung. OMD steht wie bereits mehrfach beschrieben für Open Monitoring Distribution. OMD ist jedoch kein neues Programm, sondern wie der Name schon sagt, eine Distribution, man kann sagen, eine Zusammenstellung.

Zusammengestellt wurden bei OMD verschiedene bekannte Monitoring Produkte wie Nagios, pnp4nagios, nagvis, check_mk und auch nützliche Tools wie z.B.dokuwiki. Alles in allem steht eine stetig wachsende Anzahl von Programmen zu Verfügung.

Das Besondere dabei ist, dass bereits alles von Experten aufeinander abgestimmt wurde. Es ist also nicht weiter nötig, alles einzeln zu installieren, sondern man installiert nur noch das OMD Packet als eine ganze Einheit. Anschließend an die Installation kann man mit einem Kommando (omd create SITENAME) eine Monitoring Umgebung, genannt Site, erzeugen. Es lassen sich sogar beliebig viele (natürlich durch die Ressourcen des Servers begrenzt) parallele Sites erstellen und nutzen.

Jede dieser Sites läuft dann unter einem eigenen User und kann unabhängig von den anderen Sites gestoppt und gestartet werden. Nun aber zurück zu einer Site: Nach einem Kommando kann ich nun eine Site anlegen, in welche ich mit su – Sitename wechseln kann.

Bin ich in der Site, steht mir bereits alles fix und fertig eingerichtet zur Verfügung. Wir erinnern uns, es war nicht mehr nötig, als das OMD Packet zu installieren. In einem lokalen etc Verzeichnis finde ich nun die Unterordner meiner Monitoring Tools, in welche ich meine Konfigurationsdateien ablegen kann.

Mit dem Befehl omd config kann ich bequem Grundlegendes einstellen und mit omd start wird die Site dann gestartet. Unter der http://servername/sitename/ steht anschließend ein Startbildschirm bereit, in dem ich auch schon gleich die GUI auswählen kann, mit der ich arbeiten will. Neben der klassischen Nagios GUI gibt es hier zur Zeit die Multisite GUI sowie die Thrunk GUI. Links in die Dokuwiki und nach pnp4nagios wurden natürlich auch nicht vergessen.

Schon einmal so einfach ein komplettes Nagios mit Plugins aufgesetzt? Ich glaube nicht :)!

Jetzt ist hier aber noch nicht Schluss. Auch an ein Update-Konzept wurde gedacht. Die Zeiten, bei dem alles einzeln getestet und geupdatet werden musste, sind mit OMD auch vorbei.

Man installiert für ein Update nun erst einmal eine neue OMD Version. Dabei werden aber meine bestehenden Sites wieder nicht beeinflusst. Diese laufen so weiter, wie sie zuvor eingerichtet waren. In der Site kann ich dann mit omd update auf Wunsch Up- oder sogar Downgraden. Zur Auswahl stehen alle Installierten OMD-Versionen. Geupdatet wird automatisch alles. Die Freiheit, innerhalb der Site selbst andere Versionen von z.B. Nagios oder check_mk zum Testen zu installieren, bleibt natürlich. Man installiert einfach in die lokalen Pfade der Site.

Apropos Testen. Natürlich möchte ich erst einmal in Ruhe testen, bevor ich ein OMD-Update durchführe. Nichts ist leichter als das und zwar als root: Mit omd cp ProdSite TestSite kopiere ich einfach komplett meine Produktiv Site in die neue Site, hier mit Namen TestSite. In TestSite kann ich nun das Update ausführlich testen, bevor ich dann ProdSite update und TestSite einfach wieder lösche.

Zusammenfassung

Also nochmal in Kurzform:

  • OMD ist kein neues Programm, sondern fasst alle nötigen Monitoring-Tools zusammen
  • Das Konzept sieht unabhängige Sites vor, die parallel laufen
  • Jede Site hat ihre eigene Umgebung
  • Jede Site kann ihre eigenen Programmversionen benutzen
  • Sites kann man klonen
  • Alle Tools sind optimal aufeinander abgestimmt
  • Sie werden die Zeit bereuen, die Sie in Vergangenheit in Installation und Update Ihrer Nagios Umgebung gesteckt haben