Das Thema Monitoring habe ich hier ja schon in einigen Postings erläutert. Ich möchte nun eine sehr interessante Variante eines Monitoringsystems vorstellen, die ich mir am Wochenende angeschaut habe.
Warum überhaupt eine neue Lösung?
Ich wollte meine Nagiosspielwiese schon seit Monaten auf OracleLinux6 neu bauen, hatte aber noch immer nicht die ultimative Lösung, wie ich das mit möglichst wenig Aufwand machen kann. Das Ziel sollte sein, eine Umgebung mit möglichst wenig Anpassungen zu bauen, die darüber hinaus auch einfach zu aktualisieren ist.
Altsystem:
Meine derzeitige Umgebung ist komplett selbst gebaut und kompiliert, da es vor 1,5 Jahren noch nicht die benötigen RPMs gab bzw. die Versionen zu alt waren. Ich habe folgende Komponenten gebaut:
– Nagios Core
– PNP4Nagios
– NagiosQL
– Thruk
– Livestatus
– check_nrpe
Das ist eine nicht zu unterschätzende Liste, wobei einige Komponenten sehr einfach zu bauen sind, da lediglich ein tar.gz entpackt und ein paar Dateien konfiguriert werden müssen. Technisch interessant vom Pflegeaufwand aber nicht so toll.
Geht es besser?
Ja, es geht mittlerweile sehr einfach und genau das habe ich mal probiert:
Man nehme OMD (Open Monitoring Distribution) und installiere diese auf OracleLinux6 als RPM.
wget -O – http://labs.consol.de/OMD/rh6/stable/omd.repo > /etc/yum.repos.d/omd.repo
yum search omd-
Nun das aktuelle Package von OMD installieren und warten bis fertig. Die notwendigen Abhängigkeiten werden aufgelöst, so das Du am Ende ein lauffähiges OMD hast. Der Apache muß noch aktiviert werden, da sonst nach nem Reboot die Weboberfläche nicht funktioniert.
Dann bekommt man fertig konfiguriert folgende Komponenten:
nagios
nagios-plugins
nsca
check_nrpe
Icinga
Shinken
nagvis
pnp4nagios
rrdtool/rrdcached
Check_MK
MK Livestatus
Multisite
dokuwiki
Thruk
Mod-Gearman
check_logfiles
check_oracle_health
check_mysql_health
jmx4perl
check_webinject
check_multi
Die Liste ist schon krank aber wirklich genial an dem System ist, das man nur das OS installieren muß, das RPM drauf packt und alle Komponenten sind zusammen installiert und miteinander konfiguriert. Den letzten Punkt konnte ich erst nicht glauben und habe es daher mal ausprobiert und kann bestätigen das es funktioniert. Ich habe nicht alles probiert, da ich mich vorerst mit Komponenten beschäftigen möchte, die mir bekannt sind.
Ich habe mir bisher folgendes angeschaut, die ‘out of the box’ funktionierten:
– Nagios Core
– pnp4nagios
– Check_MK
– Multisite
– Thruk
– MK Livestatus
=> Das ist alles was man so braucht. 🙂
Das hat mich sehr beeindruckt, da ein RPM + 2 Befehle für OMD zu einer lauffähigen Umgebung geführt haben.
check_mk rundet das ganze richtig toll ab, weil check_mk ein Agent auf dem zu überwachenden System mit bringt, der die zu konfigurierenden Services in Nagios automatisch generiert. (Das hatte mich früher abgeschreckt, weil ich hier starke Einschränkungen in der Flexibilität befürchtet habe, die sich jedoch nicht bestätigt haben.)
Man kann mit dieser Konfiguration innerhalb von Minuten zahlreiche Systeme in ein Nagios-Monitoring bringen, weil der Agent lediglich xinetd + Python auf dem zu überwachenden System benötigt. Der Agent ist so gebaut, das er problemlos mit Shell-Skript o.ä. erweitert werden kann.
check_mk und NRPE
Das ist schon eingebaut. Man kann bestehende Nagios-Plugins die für NRPE gebaut wurden in den Agenten von check_mk integrieren – also beliebig erweitern. Auch das war im Test sehr einfach. Analog zur nrpe.cfg muss man eine /etc/check_mk/mrpe.cfg erzeugen, die Einträge im passenden Format für check_mk eintragen und speichern.
Nun auf dem OMD den Client neu inventarisieren, die Konfig in Nagios übernehmen und der Check ist als Passivecheck eingebunden. (Erneute Verwunderung wie einfach das sein kann…)
Das hat aber einen Nachteil. check_mk inventarisiert die Checks automatisch aber sie müssen auf dem Agenthost konfiguriert werden, was beim alten NRPE aber ebenfalls notwendig war.
Wichtig ist. Es können alle bekannten Plugins von Nagios in check_mk eingebunden werden und das bei genauer Betrachtung mit weniger Aufwand als beim klassischen NRPE.
Ist OMD ernst zu nehmen?
Definitiv ja, da zahlreiche bekannte Personen hinter dem Projekt stehen. Mathias Kettner bietet eine kommerzielle Lösung von OMD an, die sich von der frei verfügbaren Lösung im Funktionsumfang kaum unterscheidet. Man bekommt dort auf Wunsch einen kommerziellen Support für OMD.
Es gibt eine wirklich große verteilte Installation die zeigt, was OMD kann:
http://mathias-kettner.de/check_mk_success_edeka.html
Fazit:
Nagios kann man so innerhalb von Minuten in lauffähiger Form bekommen. Einfach zu konfigurieren, Updates von OMD sind im Konzept von Grund auf eingeplant und man kann mehrere Nagioskonfigurationen parallel betreiben.
Den letzten Punkt finde ich besonderst lustig. Einfach mal eine neue Nagioskonfiguration auf dem bestehenden System aufsetzen, testen und bei Bedarf wieder weg werfen. Man kann auch eine bestehende Konfiguration kopieren, ändern oder auf einen neue Version von OMD bringen und bei Bedarf dann wieder entsorgen.
Hier braucht man zum Spielen keine 2 getrennten Systeme mehr, da man alles mit 1 System machen kannst und der Updatemodus ist halt von Haus aus vorgesehen, worauf die Entwickler gezielt geachtet haben.
check_mk ist so gewaltig, das ich die Möglichkeiten noch nicht alle verstanden habe. Das was ich bisher gesehen habe hat mich aber sehr überzeugt – ich werde definiiv auf OMD umsteigen und bin gerade dabei meinen heimischen Nagioshost von Grund auf neu zu bauen.
Der Verzicht auf NagiosQL als Administrationsfrontend ist mittlerweile zu verschmerzen, da es mit den neuen Versionen von Thruk oder der GUI von check_mk möglich ist, diesen Punkt zu ersetzen. Das war zum damaligen Bauzeitpunkt der Altumgebung noch nicht der Fall.
Gruß
Thorsten
