OMD, die Open Monitoring Distribution bündelt 17 nützliche Nagios-Addons und -Module in einem Paket. Die Distribution ist sorgfältig zusammen gestellt und sollte sich auf den meisten Linux-Varianten installieren lassen.

Nachdem ich die Installation unter SuSE SLES 11 bereits beschrieben habe, folgt hier ein kurzer Überblick über die Features von OMD.

Vorteile von OMD

Gegenüber einer handgestrickten Installation bietet OMD mehrere Vorteile

• Kein Compilieren der einzelnen Pakete nötig
• Die Addons passen zusammen
• Mehrere Nagios (OMD) Installationen parallel auf einem Server möglich.
  Jede Installation ist eine site.
  Sites können auch mit unterschiedlichen OMD-Versionen auf einem Server betrieben werden.
  Für jede Site gibt es einen eigenen Unix-Benutzer (z.B. mysite, prod, …).
  Dieser Unix-User benötigt keine root-Rechte.
• Wechsel zwischen Test (einer neueren Version) und produktivem System
• Upgrade-Mechanismus für zukünftige neue Versionen
• Zentrales Kommando omd zur Verwaltung der Site (omd start, omd stop, omd config, …)
• Kopieren, Umbenennen von Sites möglich (omd cp …, omd mv …)
• Gut durchdachte Verzeichnisstruktur
• RAMDISK (tmpfs) in /opt/omd/sites/mysite/tmp um den Zugriff auf temporäre Dateien zu beschleunigen.

Nachteile von OMD

Die Nachteile will ich auch nicht verschweigen

• Dokumentation
  Das größte Problem ist die fehlende Dokumentation. Es existiert zwar ein Wiki zu OMD, aber man ist immer noch gezwungen, sich die Informationen einzeln zusammen zu suchen. Da hat sich im Vergleich zu einer ‘normalen’ Nagios-Installation leider noch nicht so viel getan. Bei konkreten Problemen findet sich schnell eine Antwort im Forum des Monitoring-Portals.
  Meinen kleinen Beitrag zur Doku leiste ich übrigens hier.
• Versionsabhängigkeit
  Wer einmal auf den OMD-Zug aufgesprungen ist, muss/sollte auch dabei bleiben.  Dadurch ergibt sich eine gewisse Abhängigkeit. Ich wünsche mir, dass die Entwickler es schaffen, die Open Monitoring Distribution aktuell zu halten. Das betrifft sowohl die Unterstützung neuer Linux-Versionen als auch die Pflege der in OMD eingebauten Nagios-Module. Es kann durchaus sein, dass ein Fehler in z.B. check_mk bereits behoben ist oder dass ein neues Feature eingebaut wurde.
  Wenn man jetzt nicht alles auseinander brechen will, ist man darauf angewiesen, dass  die Fehlerbehebung auch in eine neue OMD-Version einfließt. In der Praxis kann das dann Warten, Hoffen, Bitten, Betteln bedeuten.
  Natürlich brauchen die OMD-Entwickler Zeit.

In OMD enthaltene Software

1. nagios-3.2.2

Nagios 3.2.2 ist der Kern von OMD.
Informationen zu Nagios auf der Homepage www.nagios.org.
Wer sich “omd config” mal genauer anschaut, wird feststellen, dass OMD bereits für andere cores vorbereitet ist.

2. nagvis

Nagvis gehört zu den Frontends von Nagios bzw. OMD. Es dient zur Visualisierung., daher der Name.
Die Homepage ist nagvis.org.
Nagvis stellt Grafiken, Maps, Karten  dar, in die der aktuelle Status von Servern und Services eingeblendet werden kann.

Erreichbar über: http://localhost/mysite/nagvis/.

3. pnp4nagios

PNP ist ein Addon für Nagios, das es ermöglicht, die von Nagios Plugins gelieferten Performancedaten zu analysieren und automatisch in RRD Datenbanken (Round Robin Database)  zu speichern.

Das GUI von pnp4nagios ist erreichbar über http://localhost/mysite/pnp4nagios/ (noch nicht in der OMD-Mainpage eingebunden).
Die Grafiken lassen sich auch als PDF exportieren.

4. rrdtool/rrdcached

rrdtool und rrdcached werden ebenfalls für die Speicherung und zur Anzeige von Performancedaten verwendet.
Unix-Freaks kennen rrd wahrscheinlich über MRTG. Es wird von vielen Tools eingesetzt, die nichts mit Nagios zu tun haben.

5. nagios-plugins

An die Nagios-Plugins delegiert Nagios seine Checks. Bei einer ‘normalen’ Nagios-Installation müssen die Plugins als Extra-Paket installiert werden. Bei OMD werden sie gleich mitgeliefert.

Ein kleiner Tip: Das Plugin-Verzeichnis sollte man vielleicht mit in die PATH-Variable aufnehmen, da man zum Testen die Plugins oft von der Kommandozeile aufrufen muss.

OMD[mysite]:~$ ls  /opt/omd/versions/0.44/lib/nagios/plugins/
check_apt            check_flexlm         check_jmx4perl
check_breeze         check_ftp@           check_ldap
check_by_ssh         check_host@          check_ldaps@
check_clamd@         check_hpjd           check_load
check_cluster        check_http           check_log
check_dhcp           check_icmp           check_logfiles
check_dig            check_ide_smart      check_mailq
check_disk           check_ifoperstatus   check_mrtg
check_disk_smb       check_ifstatus       check_mrtgtraf
check_dns            check_imap@          check_mysql
check_dummy          check_ircd           check_mysql_health
check_file_age       check_jabber@        check_mysql_query   

check_nagios         check_ping           check_swap
check_nntp@          check_pop@           check_tcp
check_nntps@         check_procs          check_time
check_nrpe           check_real           check_udp@
check_nt             check_rpc            check_ups
check_ntp            check_sensors        check_users
check_ntp_peer       check_simap@         check_wave
check_ntp_time       check_smtp           check_webinject
check_nwstat         check_snmp           negate
check_oracle         check_spop@          urlize
check_oracle_health  check_ssh            utils.pm
check_overcr         check_ssmtp@         utils.sh

Weitere Nagios-Plugins gibt es auf exchange.nagios.org.
Die man-Pages zu den checks befinden sich auf nagiosplugin.org.

6. Check_MK

check_mk von Matthias Kettner geht einen anderen Weg als die (meist) aktiven Check-Plugins. Für check_mk gibt es eigene Agenten für Linux und Windows. Normalerweise werden Services durch Plugins aktiv gecheckt. Bei fünf Festplatten auf einem Server wird also 5x das Plugin check_disk aufgerufen (jeweils für eine Platte).
Die Plugins von check_mk arbeiten anders. Sie merken sich den Status (Festplatte, CPU, Load, Logfiles,…) und liefern sie mit einem Aufruf zurück.

1. Nagios ruft check_mk aktiv auf
2. check_mk holt sich dann alle Daten vom Host in einem Aufruf
3. check_mk speichert die Performancedaten direkt in einer RRD-Datenbank.
4. check_mk analysiert Daten für den Host, ermittelt warning/critical Schwellen und informiert (alarmiert) Nagios dann über passive Service checks.

Weitere zusätzliche Features von check_mk

• Automatische Inventarisierung
  check_mk -I tcp fragt den Agenten was er ‘anzubieten’ hat und erstellt bei Bedarf die passende Nagioskonfiguration (Service-Checks und commands) . Falls erwünscht werden auch die Hostdefinitionen, Hostgruppen, Servicegruppen von check_mk mit erstellt.
  Das Komando check_mk -O erstellt die Nagios-Konfiguration und startet nagios neu (reload).
• check_mk generiert automatisch Konfigurationsdateien für Nagios
  OMD[mysite]:~/etc/nagios/conf.d$ ls check_mk*
  check_mk_objects.cfg check_mk_templates.cfg
  Diese Dateien sollten manuell nicht verändert werden.
• Die Konfigurationsdateien für check_mk liegen in dem Verzeichnis etc/check_mk/conf.d. Hier ein Beispiel mit zwei von mir erstellten Dateien (*.mk).
  OMD[mysite]:~/etc/check_mk/conf.d$ ls
  buddy4.mk README  servicegroups.mk
• Die check_mk – Konfigurationsdateien haben eine eigene Syntax. Durch geschickte Konfiguration (mit Regular Expressions) lassen sich Regeln erstellen um z.B.  alle Service – Checks auf laufende Oracle-Dienste (Listener, Datenbank) automatisch zu einer Servicegruppe zusammen zu fassen.
  service_groups = [
  # All services beginning with "service_Oracle" on all hosts
  # go into the service group "Oracle-MK".
  ( "Oracle-MK",  ALL_HOSTS, ["service_Oracle"] ),
  ]
• teilweise erhebliche Performancegewinne durch den oben beschriebenen Mechanismus

7. MK Livestatus

MK Livestatus ist ebenfalls ein Nagios-Addon von Matthias Kettner. Es ermöglicht die schnelle Abfrage des Status von Hosts und Services. Es ist eine (gute) Alternative zu den NDO Utils.
Nagvis ist in OMD so konfiguriert, dass es mit MK Livestatus zusammenarbeitet.

8. Multisite

Multisite - ebenfalls von Matthias Kettner – ist eine sehr schöne und zweckmässige Weboberfläche (GUI) für Nagios.
Multisite verwendet MK Livestatus.
Die Original-Oberfläche von Nagios lässt sich über ein Snapin einbinden.

9. dokuwiki

Dokuwiki ist ein Wiki zur Dokumentation. In OMD 0.44 kann das DokuWiki auch zur User-Administration verwendet werden. Unter Ubuntu sind zuvor allerdings noch Probleme mit AppArmor zu lösen.
Die OMD-Dokumentation zu dokuwiki ist sehr spartanisch.
Das Wiki ist erreichbar unter http://localhost/mysite/wiki/.

10. nsca

Die Konfigurationsdateien von nsca liegen unter etc/nsca. nsca ermöglicht passive checks in Nagios.

11. Thruk (neu in 0.44)

Mit Thruk von Sven Nierlein (Fa. Consol) ist das dritte GUI für Nagios (neben Nagios ‘classic’ und Multisite).
Es arbeitet ebenfalls mit MK Livestatus und kann mehrere Nagios-Sites anzeigen.

Hinweis:

Auf Ubuntu (10.10, 32Bit) lief Thruk aufgrund eines Fehlers bei den Perl-Libraries nicht.
Fehlermeldung in ~/var/log/apache/error_log:

Can’t locate Moose.pm in @INC (@INC contains: /opt/omd/versions/0.44/share/thruk/script/../local-lib/lib/perl5 /omd/sites/mysite/lib/perl5/lib/perl5/i686-linux-gnu-thread-multi …)

Dies hat dann bei mir geholfen:

sudo cd /omd/sites/mysite/lib/perl5/lib/perl5                    # mysite ersetzen durch deine site!
sudo ln -s i486-linux-gnu-thread-multi        i686-linux-gnu-thread-multi

Der Link muss nur 1x angelegt werden, da mysite/lib (im Endeffekt) ein Link auf omd/versions/0.44/lib ist.
Update: OMD 0.44 ist nicht für Ubuntu 10.10 freigegeben, siehe Kommentare unten.

Bei der Installation unter SLES11 (64Bit) existierte das Problem nicht.

12. check_nrpe

check_nrpe fragt den Linux/Unix-Agenten von Nagios ab. Wie die Plugins muss check_nrpe nicht einzeln installiert werden.
(nrpe gibt es auch für Windows, aber dort wird meistens NsClient++ verwendet).

13. check_logfiles (neu in 0.44)

check_logfiles aus den Labs der Fa. Consol dient zur Überprüfung und Analyse von Logdateien (Überprüfung auf bestimmte Muster).
I.d.R. wird check_logfiles über check_nrpe auf den zu monitorenden Host aufgerufen.
Die Doku ist sehr gut, aber die Kommandozeilenparameter, Variablen und Konfigurationsdateien für check_logfiles erfordern  einiges an Einarbeitungszeit.

14. check_oracle_health (neu in 0.44)

check_oracle_health aus den Labs der Fa. Consol überprüft Oracle Datenbanken. Auf die Benutzung werde in ein einem anderen Artikel noch weiter eingehen. check_oracle_health ist ein Perl-Script. Die Datenbanken werden (meistens) remote von Nagiosserver aus abgefragt. Dazu benötigt dieser entweder einen Oracle (Voll-) Client oder den Oracle Instantclient.
Die Installation des Oracle Instant Clients unter Ubuntu habe ich in einem früheren Artikel beschrieben.
Dort findet sich auch Aufrufbeispiel mit dem Oracle Easy Connectstring. Die Connectstrings sollten direkt im Kommando mit angegeben werden. Eine Verwendung der tnsnames.ora ist zu fehleranfällig (wird schnell vergessen). Ich persönlich ziehe die EZCONNECT-Strings vor (wenn sie erlaubt sind), da sie wesentlich einfacher sind als  “(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP…..”- connectstrings.

15. check_mysql_health (neu in 0.44)

Das Plugin check_mysql_health aus den Labs der Fa. Consol überprüft Mysql Datenbanken.

16. jmx4perl (neu in 0.44)

jmx4perl und check_jmx4perl aus den Labs der Fa. Consol überprüfen J2EE-Server (z.B. jBoss/Tomcat) über das JMX-Protokoll.
Das Addon benötigt keine Java Installation, aber anscheinend etwas Konfiguration. Bei mir läuft es noch nicht.

Weitere Links:

• Weitere Doku zu jmx4perl auf search.cpan.org.
• Tomcat Management jmx4perl makes it easier.

Das Spannende an der Überwachung von J2EE-Servern ist die Auswahl geeigneter Parameter, die sich irgendwo in den Tiefen des J2E-Servers verstecken.

17. check_webinject (neu in 0.44)

check_webinject aus den Labs der Fa. Consol basiert auf dem Webinject Perl Modul (gibt’s bei CPAN), welches nun Teil des Webinject-Projekts ist.
Es erlaubt das automatische Testen von Web-Applikationen und unterstützt diverse HTTP-Interfaces (JSP, ASP, CGI, PHP, AJAX, Servlets, HTML Forms, XML/SOAP Web Services, REST, usw.).

Fazit

OMD ist schnell installiert. Danach fängt die Arbeit erst an. Viele Module. Viel zu lesen. Die Dokumentation ist leider (noch) überall im Internet verstreut.

Update (20.02.2011)

Mittlerweile ist die neue stabile Version OMD 0.46 erschienen.