Checks oder Services bei einer check_mk Inventur ignorieren

Update: Anleitung betrifft die Konfiguration in der main.mk Alles kann jedoch auch in der Weboberfläche konfiguriert werden.

Wollen wir mal nicht alles, was check_mk findet, auch in den Inventur haben, stehen wir nun vor der Wahl, ob wir checks oder services ignorieren wollen.

Der Unterschied zwischen check und service?

Ich möchte es am Beispiel des checks df einmal versuchen zu erklären. Wie schon gesagt, ist df ein check. Dieser listet uns alle Dateisysteme eines Systems und deren Belegung auf. Check_mk generiert uns hier nun automatisch für jedes Dateisystem einen Service.

Um es so zu sagen: Hinter jedem Service muss ein check steht. Ein check kann jedoch mehrere Services hervorbringen.

Damit wäre also schon der Unterschied geklärt. Jetzt zur Praxis.

Check Ignorieren

Einen (oder mehrere)check(s) kann ich in der Variable ignored_checks ausschließen.
Diese basiert wieder durch das bereits mehrfach erklärte Muster:

Drei Beispiele, check1 und check2 werden überall ignoriert, 3+4 nur bei rechner 1+2, die checks 5+6 bei allen Rechnern mit hosttag1 und hosttag2. Die Arbeit mit Host Tags habe ich übrigens hier beschrieben.

Wie komme ich nun aber auf den Namen des checks? Dazu verschiedene Möglichkeiten. Ein check_mk -L listet uns alle checks, die es so gibt. Bei der Inventur ist der Name des checks der, welcher links in grün in der Liste steht und natürlich auch in der autocheck Datei ist der Check in der Liste noch mal zu finden. Sollte dazu eine Frage kommen, werde ich das noch einmal genauer erklären.

Service Ignorieren

Will ich nur einen Service ignorieren, gehen wir über die Variable ignored_services und hinterlegen, bei welchen Hosts wir welchen Service nicht sehen wollen.  Der Name des Services entspricht jeweils dem Namen des Checks wie er in Nagios steht.  Ich muss ihn wie immer nicht ganz ausschreiben, sondern kann mit z.B. fs_ jeden Service abfangen, der mit fs_ beginnt.

Am Beispiel:

Anstelle ALL_HOSTS kann natürlich jede Kombination aus dem ersten Beispiel benutzt werden. In die Liste nach ALL_HOST schreibe ich einfach alle Services mit Komma getrennt.

Wichtig

Das alles wirkt natürlich erst nach eine Re-inventur (-II), bzw muss vor der ersten Inventur gemacht werden. Diese info gilt nur für Versionen vor 1.2.4. Ab 1.2.4 ist keine Reinventur mehr nötig

Inventur in check_mk nur bei bestimmen Host Tag durchführen durch Kommandoersetzung

Update: Dieser Tipp ist veraltet:

In aktuellen Check_MK Versionen reicht bereits ein:

 

Heute nur ein schneller Tipp:

In check_mk ist es, wie bekannt, in der Konfiguration möglich, Hosts einen Tag zuzuordnen, um auf sie eine bestimme Konfiguration anzuwenden. Jetzt wäre es natürlich toll, nur bei Hosts mit einem bestimmten Tag auch eine Inventur bzw. Reinventur durchführen zu können.

Das kann jetzt check_mk nicht von alleine, dafür hilft uns aber die Shell. Diese bietet eine Kommandoersetzung. Schreibe ich hinter einen Befehl einen zweiten Befehl in die Form $(), werden die Ausgaben des zweiten Befehles dem ersten als Parameter übergeben.

Wollen wir jetzt alle Hosts mit dem Tag Linux inventarisieren, hängen wir nur den Inventurbefehl check_mk -I mit dem Befehl zusammen, welcher uns eine Liste mit Hosts zu einem Host Tag liefert: check_mk –list-tag

Da die Kommandoersetzung eine Funktion der Shell ist, kann diese natürlich auch mit anderen Programmen und bei ganz anderen Problemen benutzt werden.

SNMP Geräte mit check_mk überwachen

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.

Das Überwachen eines SNMP-Gerätes ist eine der vielen Stärken von check_mk.

Für meinen heutigen Artikel setze ich voraus, dass du den Artikel Einstieg in die Benutzung von check_mk bereits gelesen hast. Er beschreibt die Grundlagen, auf die ich hier nicht noch einmal genauer eingehe.

Wie nehme ich das SNMP Gerät in check_mk auf?

Die Aufnahme eines SNMP-Gerätes in check_mk läuft genau gleich über die all_hosts Variable ab.  Als Unterschied MUSS ich den Host Tag SNMP setzen:

Setze ich übrigens noch den Host Tag tcp, erfolgt die Überwachung gleichzeitig noch über den normalen Agenten weg.

SNMP Community

Würden wir nun eine Inventur probieren, würde check_mk einen SNMP-Bulkwalk versuchen und dazu die Community public verwenden. Deswegen habe ich nun schon einmal die Tags muenchen und berlin gesetzt. Diese will ich nun dazu verwenden, andere SNMP-Communitys zuzuordnen.

Hast du meine anderen Artikel aufmerksam gelesen, solltest du schon verstehen was hier passiert. Allen Rechnern mit Host Tag muenchen wird die Community smpcom1 zugewiesen, snmpcom2 geht an alle Rechner mit Host Tag Berlin.

SNMP v3

Jetzt gibt es natürlich noch das sicherere SNMP v3. Um dieses zu benutzen muss dem Host noch zusätzlich der Tag v3 zugewiesen werden.

In den snmp_communities Variable setzt ich nun keinen String mit einem Communitynamen, sondern eine Tupel mit 4 Werten:

Inventur

Bei der Inventur ist nun nichts weiter zu beachten. Sie kann gleich einer normalen Inventur durchgeführt werden. Es sollte entsprechend deiner installierten checks alles gefunden werden, was du überwachen willst.

SNMP Plugin für check_mk entwickeln

Nachdem ich schon die Grundzüge erklärt habe, wie man ein Agent basierendes check_mk Plugin entwickelt (siehe hier) folgt nun ein kleines Update mit der Frage vorweg:  Wie entwickelt man einen SNMP basierenden check?

Nun, die gute Nachricht ist, dass ich nicht viel schreiben muss. Es funktioniert genau so wie in meiner ersten Anleitung, Teil 2 und Teil 3. Lediglich Teil 1 muss ich hier neu schreiben, denn die Daten kommen nun natürlich nicht von einem Agent, sondern vom einem SNMP Walk. Also spare ich mir sogar einige Arbeit und muss nur noch angeben was ich denn aus dem Tree haben möchte.
Und das funktioniert über snmp_info

Aber nun mal langsam was hier passiert: Die Basis OID, die ich angebe, ist der Hauptzweig unter dem alle meine OIDs zu finden sind, die ich brauche. Die unteren Zweige sind die Daten, bei denen ausgehend vom Hauptzweig ein SNMP Walk gemacht wird. Lassen wir mal die noch tiefere Ebene weg, würden folgende OIDs in unserem Beispiel gezogen:

Nehme ich nun noch die tiefere Ebene hinzu, wird jeweils gezogen:

Sprich, es wird verschachtelt.

Und nun gehts einfach weiter. In der info Variable, welche meine Inventur und meine Check-Funktion bekommt, bekomme ich nun eine Liste geliefert, in der alle Werte zu finden sind, welche unter den OIDs gefunden wurden. Geht also weiter wie in Teil 2 und Teil 3 beschrieben. Eben nur mit anderen Daten.

Viel Spass damit… aber nein, da war noch was.

Eine automatische Inventur wäre noch eine schöne Sache. Dazu benötige ich nur eine kleine Funktion, lässt sich meist als lambda Funktion regeln, die ich in snmp_scan_functions[“checkname”] registriere. Dieser wird einfach nur das Objekt oid übergeben und sie muss True oder False zurückliefern. Mit dem Objekt oid kann man nun nämlich eine OID abfragen (wer hätte es für möglich gehalten) und mit der Ausgabe alle möglichen Vergleiche anstellen. Ein Beispiel:

Steht nun in der OID ‘1.3.6.1.2606.1.2.3.4.5 das Wort Test , wird automatisch die Inventurfunktion aufgerufen.

Ohne die scan_function müsste ich bei der Inventur explizit den Checknamen mitgeben, damit der check erkannt wird. Dies geht übrigens mit check_mk –checks checkname -I rechnername .

Das soweit zu SNMP Checks. Jetzt aber wirklich viel Spass! :)

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