Einstieg in die Benutzung von check_mk

Update: Diese Anleitungen gilt für ältere Versionen von Check_MK. Die Konfiguration kann in den neuen Versionen bequem in Wato, dem Webadministrationstool durchgeführt werden.

Nachdem ich in meinem letzten Artikel die Funktionen von check_mk beschrieben habe, möchte ich heute mehr ins Detail gehen, wie ich check_mk konkret konfiguriere.

Beispiel

Ich beschreibe es anhand eines fiktiven Beispiels dreier Rechner, die überwacht werden sollen. Rechner 1, srvfile1: Linux Fileserver. Normal erreichbar. Rechner 2, srvweb1: Ein Linux Web Server mit Apache und einem nrpe Check, der weiter benutzt werden soll. Rechner 3, srvdmz1: Ein Server in einer DMZ, der nur per SSH zu erreichen ist.

check_mk sollte bereits konfiguriert sein. Am einfachsten arbeiten wir wieder mit OMD, da ist schon alles dabei. Da die Pfade je nach Installation woanders sein können, bitte beachten, dass ich die Pfadangabe entsprechend OMD beschreibe. Lässt sich aber leicht ableiten.

Los gehts:

Pfade

OMD Nutzer wechseln als root durch su – sitename in ihre OMD site. In den Beispielen heisst meine site monitor. Alle Konfigurationen zu check_mk befinden sich unter ~/etc/check_mk .

main.mk

Für uns ist die main.mk interessant. Sie ist die Hauptkonfigurationsdatei. Es ist natürlich möglich, die Konfiguration auf mehrere Dateien aufzuteilen. Diese können mit der Endung .mk in den Ordner conf.d abgelegt werden. Beim Aufteilen auf mehrere Dateien muss nur beachtet werden, dass man die Konfigurationen in Python, also einer Programmiersprache schreibt. D.h. in Variablen, an die mehrfach etwas angehängt wird, also in der Regel mit +=. Ich erklär es gleich im Beispiel.

In der main.mk nehmen wir als ersten Schritt die drei Rechner auf, welche wir überwachen wollen:

Sie werden einfach in eine Liste mit dem Namen all_hosts gehängt. Teile ich die Konfiguration nun auf mehrere Datien auf, darf  ich in denen natürlich nicht wieder all_hosts = schreiben, sondern muss += verwenden.

Wichtig ist auch die korrekte Syntax beim schreiben. Die Klammern müssen wie ich es im Beispiel zeige gesetzt werden. Die erste nach dem =, die letze in eine neue Zeile. Dies liegt an Python, denn für Python ist normal newline das Zeilenende, außer ein Element ist eben noch offen. Dann ist das Zeilenende da, wenn das Element wieder geschlossen wird.

In unserem Beispiel gehen wir nun davon aus, das srvfile1 und srvweb1 im DNS aufgelöst werden. Hier muss ich also nichts weiter tun.

Extra IP Addressen

Anders sieht es aber nun mit dem srvdmz1 aus. Dieser steht nicht im DNS. Für diesen müssen wir die IP Adresse manuell zuweisen. Die funktioniert über ein Python Dict:

Wichtig wieder die Syntax und noch etwas: wenn man IP Adress-Zuweisung in mehreren Dateien durchführen will, geht dies nicht über +=. Man muss es mit

zusammenhängen.

Andere Datenquellen

Jetzt erinnern wir uns aber auch noch, das srvdmz1 nur über SSH zu erreichen war. Dazu müssen wir dem Rechner eine neue Datasource zuweisen.

In der main.mk schreiben wir dazu:

Wir konfigurieren damit, dass srvsdmz1 über ssh als root und einem bestimmten keyfile kontaktiert wird. Platzhalter hier ist

Konfigurationen an Hostags und mehrere Rechner zuweisen

Die Rechner-Liste kann auch mehrere Rechner enthalten:

oder gar einen (oder mehrere) Hosttags enthalten:

Den Hosttag ordne ich einach mit einem | dem Rechner zu:

Hosttags können für alle Konfigurationen verwendet werden. Erkannt werden sie durch das Schlüsselwort ALL_HOSTS. Würde das hier fehlen, würde dmz als Rechnername gesucht und nicht als Hosttag Name.

Für unser Beispiel habe ich dem srvweb1 auch gleich apache zugeordnet. Das bentzten wir später. Das Tag lnx habe ich nur zugeordnet, um zu zeigen, dass man auch mehrere Tags zuordnen kann.

Agents einrichten

Jetzt machen wir aber erst mal den dmz Rechner zu Ende: damit wir ihn kontakten können muss mit ssh-keygen ein Schlüsselpaar erzeugt werden. Dafür schreibe ich aber auch noch einen eigenen Beitrag. Ich setzte nun mal das ssh-Wissen vorraus.

Auf srvdmz1 muss nun einfach in /root/.ssh/authorized_keys der passende public_key zum privatekeyfile aus unsere Datesource liegen. Da wir natürlich nicht wollen, dass man sich vom Nagios Server einfach als root auf srvdmz1 verbindet, hinterlegen wir in authorized_keys für Keyfile noch einen command. command=”/usr/bin/check_mk_agent”. Dann wird bei einer Verbindung mit dem Key immer nur der Agent ausgeführt. Ein interaktiver Login mit dem Key findet nicht statt. Der Agent muss natürlich noch nach /usr/bin kopiert werden.

Auf srvfile1 und srvweb2 haben wir es etwas einfacher. Auf diesen beiden Server können wir einfach das normale Agent Paket installieren. Dieses legt automatisch einen Eintrag in xinted an, welches den Agent über TCP Post 6556 erreichbar macht.

Damit wäre die Grundkonfiguration und die Agent-Installation geschafft.

Inventur

Nun können wir auch schon eine Iventur machen:

Ohne jedes weitere Parameter wird jetzt eine Iventur über alle Rechner durchgeführt, welche in der Konfiguration eingetragen wurden. Es wird ermittelt, was für jeden Rechner überwacht werden könnte.

Natürlich lässt sich auch eine mit Leerzeichen getrennte Liste angeben, wenn ich nur bestimmte Rechner inventurisieren will. Beispielhaft sieht das nun so aus:

Dabei werden aber immer nur checks angezeigt, welche noch nicht bei einer früheren Iventur entdeckt wurden. Das funktioniert, da jede Inventur im Order ~/var/check_mk/autochecks abgelegt wird.

Das ist wichtig zu wissen, denn überwache ich z.B. ein Filesystem, welches später entfernt wird oder durch einen Fehler nicht mehr gefunden wird, merkt sich dies check_mk, um es melden zu können. Will ich bewusst dafür sorgen, dass es nicht mehr dazu gehört, muss es aus autochecks gelöscht werden. Dies geht mit check_mk -II rechnername. Zweimal II sorgt dafür, dass die autochecks zu den angegeben Rechnern vor der Iventur gelöscht werden.

Will ich übrigens nur einzelne Dienste inventurisieren, hilft der Parameter –checks checkname.

Alles im Nagios

Ist die Inventur geschafft, können wir uns das Ergebnis auch schon gleich mal in Nagios anschauen. Dazu muss aber check_mk die Nagios-Konfiguration erstellen und Nagios neu gestartet werden.

Dies kann nun mit einem Rutsch passieren, in dem man check_mk -R macht oder man kann Nagios nach einem check_mk -U auch selbst neu starten.

Abschluss

Wenn wir jetzt ins Nagios schauen, werden wir sehen, dass unser srvfile1 bereits fertig ist. Alle Dateisysteme, seine SAN Paths und seine lokalen Raids wurden erkannt. Festplattenbelegung wird alles bereits automatisch überwacht.

srvdmz1 ist mittlerweile auch perfekt.

Bei srvweb1 schaut es zwar auch schon sehr gut aus, jedoch fehlt noch die Überwachung unseres Webservers und unser alter NRPE-Check. Dies werde ich in weiteren Artikeln beschreiben. Den Dienst des Apachen werden wir über die Prozessüberwachung überwachen.  Seine Erreichbarkeit überwachen wir über einen klassischen check_http, welchen wir mit Legacy Checks einbinden. Seinen alten NRPE check werden wir einfach in die MRPE Konfiguration des check_mk Agents übernehmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*