Netways EventDB in OMD installieren

Update: Diese Anleitung ist Obsolet. Mit MKeventd bringen aktuelle OMD Versionen bereits eine Eventkonsole mit, welcher Log, Mails und SNMP Trap Meldungen verarbeiten kann und ohne SQL auskommt.

Hier gehts  um die Installation der Netways EventDB innerhalb einer OMD Site. Den Download der aktuellen Version (zum Zeitpunkt des Artikels 2.0.1) und deren Entpacken an entsprechender Stelle setze ich voraus.

Apache vorbereiten

In der aktuellen Version von OMD (0.48) ist  ein kleiner Fehler vorhanden, so dass wir noch für PHP den Pfad zum MySQL Socket unserer Site setzen müssen (wichtig auch, wenn wir später von außen in die DB schreiben wollen). Ein Bug Report dazu habe ich aber bereits eröffnet. Solange muss die Datei ~/etc/apache/php-wrapper nach der Zeile exec /usr/bin/php-cgi \ um die Zeile

erweitert werden. Dann kann mit omd restart apache die Konfiguration übernommen werden.

MySQL Einstellungen

Jetzt müssen wir natürlich noch die Datenbank anlegen. Dazu als siteuser mysql eingeben und in der mysql Konsole folgendes durchführen:

Nun folgt das Einspielen der Tabellen. Dazu eingeben:

Die Datei createTables.sql befindet sich im Ordner db des EvenDB Downloads. Beachte, dass hier als User und Passwort eventdb gesetzt wird. Das kannst du ändern, dann müssen aber natürlich die folgenden Befehle angepasst werden. Auch müssen die neuen Zugangsdaten in der index.php der GUI hinterlegt werden.

GUI installieren

Nun der letzte Schritt: die GUI. Dazu  den Ordner eventdb unterhalb von ~/var/www/ anlegen. Dort hinein wird die index.php aus dem Ordner classicWeb des eventDB Paketes kopiert.

Weiterführendes

In diesem Beitrag ging es nur um die reine Installation der GUI sowie der Datenbank innerhalb einer OMD Sites. Zum Einbinden in andere GUIs und zum Empfangen von Events wie Traps folgen noch Artikel.

Parents mit check_mk Verwalten

In check_mk existieren zwei Möglichkeiten, Host Parents zu verwalten. Zum einen das manuelle Definieren (wobei man hier wieder mit Host Tags arbeiten kann), zum anderen das automatische Erkennen mittels einer Scan-Funktion.

Manuell Definieren

Nach dem typischen check_mk Muster wird in der Variable parents die Zuweisung vorgenommen.
Im Beispiel wird host1 sowie host2 dem switch1 zugewiesen, in der nächsten Zeile erfolgt dann wieder eine ähnliche Zuweisung, nur das hier gleich einer ganzen Gruppe in Form eines Hosttags zugewiesen wird.

Mehrere Parents zuweisen

Um nun einer Maschine mehrere Parents zuzuweisen, gibt es zwei Möglichkeiten: zum einen kann ich die Konfiguration einfach wiederholen:

oder gleich beide Parents mit einem Komma getrennt auf einmal schreiben:

Nach Hosts Scannen

Komfortabler ist der automatische Scan nach Parents.
Dieser setzt voraus, dass traceroute installiert ist und der Nagios Server in der main.mk als monitoring_host eingetragen ist.

Nun muss nur noch check_mk mit dem parameter –scan-parents aufrufen.
Automatisch wird nun die Datei parents.mk ins check_mk conf.d Verzeichnis abgelegt, welche die Parents Beziehungen enthält. Nach einem Neustart mit check_mk -R stehen die Parents dann zur Verfügung.

Scan-Funktion nur für bestimmte Hosts nutzen

Sollte es nicht gewünscht sein, dass alle Hosts generell nach Parents gescannt werden, besteht die Möglichkeit, explizit festzulegen, welche Hosts gescannt werden dürfen:

In diesem Beispiel werden jetzt nur noch die Hosts mit dem Tag lnx, sowie der host srv1 gescannt.

Der Weg über ein Ausschlussverfahren ist natürlich auch möglich. Hierzu dient das Schlüsselwort NEGATE.

Hier wird jetzt jede Host gescannt, solange er nicht den Tag lnx hat, bzw nicht srv1 ist.

Wieder alles rückgängig machen

Sollten mir die Ergebnisse des Scans nicht passen, reicht einfach die Löschung der parents.mk und der Neustart mittels check_mk -R.

Die Arbeit mit Host Tags in check_mk

Update: Dieser Artikel beschreibt das vorgehen in der main.mk und gilt nicht für Wato.

Host Tags in check_mk sind eine einfache Möglichkeit, Konfigurationsparameter einem oder eine ganze Gruppe von Hosts zuzuordnen.

Ein Host Tag entsteht automatisch durch seine erste Zuordnung zu einem Host. Dabei bei wird dieser einfach durch eine Pipe getrennt und hinter den Hostnamen geschrieben:

Dabei können beliebig viele Host Tags verwenden werden.

In ziemlich jedem check_mk Parameter können diese Host Tags nun verwendet werden. So werden diese einfach anstelle der Angabe eines Hostnames in Kombination mit dem Schlüsselwort ALL_HOSTS benutzt. Am einfachsten sieht man das aber an einem Beispiel:

Während im Beispiel der Hostgruppe test1 noch statisch die Hosts srv1 und srv2 zugeordnet werden, werden der Hostgruppe test2 hingegen dynamisch alle Hosts mit beiden Tags tag1 und tag2 zugeordnet. Den Unterschied macht ALL_HOSTS nach der Liste. Durch ALL_HOSTS wird die Liste erst als Liste von Host Tags interpretiert.  Dynamisch ist die Host Tag-Lösung aus dem einfachen Grund, dass ich mich nun um nichts weiter kümmern muss als den Hosts das passente Tag zuzuordnen.

Es besteht jetzt aber auch noch die Möglichkeit Tags zu negieren. Das passiert durch ein einfaches Ausrufezeichen:

In der Hostgruppe test1 landen nun alle Hosts, die nicht mit tag1 markiert sind. In test2 landen alle Hosts, die mit tag2 aber nicht mit tag3 markiert sind.

Host mit einem Host Tag auflisten

Über den check_mk Parameter –list-tag TAGNAME lässt sich übrigens eine entsprechende Liste mit Hosts generieren. Es können mehrere Tags, welche durch Leerzeichen getrennt sind, angegeben werden und Negieren mit Ausrufezeichen ist hier auch möglich. Was man damit z.B. anfangen kann, habe ich bereits in einem anderen Beitrag beschrieben.

 

 

Tracking von Programmausführungen als check_mk Plugin.

Der check last_run liest eine zuvor konfigurierte Liste von Dateien aus, welche einen UNIX Timestamp enthalten.

Die Idee hinter dem Check ist, Programme überwachen zu können, welche nur sporadisch oder regelmäßig innerhalb eines bestimmten Zeitrahmen laufen müssen. Diese Programme müssen dazu jeweils nur eine Art Heartbeat in eine Datei  schreiben. Dieser Heartbeat ist ein Unix Timestamp mit der aktuellen Zeit.

In der Agent Konfigurationsfile, die i.d.R nach /etc/check_mk abgelegt werden muss, müssen nur die Pfade zu diesen Dateien sowie ein eindeutiger Servicename angegeben werden. Siehe hierzu das Beispiel in der Datei selbst.

Die Inventur erkennt sämtliche in der Config angegebenen Service-Namen als neuen Service. Automatisch werden nun informativ die vergange Zeit zwischen jetzt und dem Timestamp angezeigt. Verglichen wird automatisch mit der Serverzeit des entfernten Clients, damit Zeitunterschiede zwischen Nagios Server und Client keinen Einfluss nehmen.

Schwellwerte können über check_parmeters gesetzt werden. Zum Einsatz kommt ein Tuple mit 3 Werten. Wert 1 ist h oder m, für Stunden oder Minuten. Die beiden folgenden Werte sind warn und crit.

Performancedaten werden keine geliefert.

Allgemeine Tipps:

PHP und Perl haben eine time() funktion, welche den Timestamp erzeugt. Auf der Shell kann es mit data +%s erzeugt werden. In Cronjobs muss man % mit \ escapen. Aber eine wirkliche Kontrolle erhält man damit natürlich nicht. Dass der Cronjob lief, sagt nichts drüber aus, ob das Programm seinen Job gemacht hat.

Download auf check_mk exchange