Christian Veith

Als kleine Fortsetzung zum Debian auf Alix Post.

Man kann das ganze als Lowcost Lowpower Monitoring Lösung sehen. Die Alix Boards von PC-Engines sind mit AMD Geode LX Prozessoren mit 433 oder 500 Mhz bestückt und verfügen über 256 MB Arbeitsspeicher. Nicht sehr leistungsstark aber für kleinere Aufgaben wie Router, Access Points oder Thin Clients gut zu gebrauchen. Jetzt also der Versuch mit Opsview/Nagios als Slave server. Master Server wäre zwar prinzipiell auch machbar, dann sollte man aber die Checkanzahl nicht zu hoch legen und auch den Mysql Server auf besser ausgestatteter Hardware betreiben.

Als gute Grundlage für die Installationsanleitung kann man das Howto von Opsera nehmen. Ich habe bei mir jedoch Änderungen vorgenommen.

Check_reqs bemängelte die beiden libs librrd und libexpat1 als fehlend. Die Dependecies konnten nur durch Installation von libexpat1-dev und librrd-dev aufgelöst werden

aptitude install libexpat1-dev librrd-dev

Die fstab hat gegenüber der puren Debian Installation auch noch ein paar veränderungen erhalten:

tmpfs /usr/local/nagios/var tmpfs defaults 0 0
tmpfs /var/spool/postfix tmpfs defaults 0 0

Der Folder /usr/local/nagios/var wir über die fstab als tmpfs gemountet. Dadurch werden Schreibzugriffe auf die CF-Karte verhindert. Allerdings hat das einen Haken, da Opsview einige Dateien und Verzeichnisse im /var erwartet. Dieses müssen vorher angelegt werden. Auch benötigt der Nagiospart die objects.cache und objects.precache files im var. Diese werden aber leider nicht automatisch beim Start des Opsview-Slave scriptes erzeugt. Also tun wir das durch manuelles anstarten des Nagios im Verify Config Modus.

mkdir -p /usr/local/nagios/var/archives && chown nagios:nagios -R /usr/local/nagios/var/archives
mkdir -p /usr/local/nagios/var/log && chown nagios:nagios -R /usr/local/nagios/var/log
mkdir -p /usr/local/nagios/var/mrtg && chown nagios:nagcmd -R /usr/local/nagios/var/mrtg
mkdir -p /usr/local/nagios/var/plugins && chown nagios:nagios -R /usr/local/nagios/var/plugins
mkdir -p /usr/local/nagios/var/rrd && chown nagios:nagios -R /usr/local/nagios/var/rrd
mkdir -p /usr/local/nagios/var/rw && chown nagios:nagcmd -R /usr/local/nagios/var/rw
mkdir -p /usr/local/nagios/var/spool && chown nagios:nagios -R /usr/local/nagios/var/spool
mkdir -p /usr/local/nagios/var/spool/checkresults && chown nagios:nagios -R /usr/local/nagios/var/spool/checkresults
touch /usr/local/nagios/var/status.dat && chown nagios:nagios -R /usr/local/nagios/var/status.dat

touch /usr/local/nagios/var/nodestatus.db && chown nagios:nagios -R /usr/local/nagios/var/nodestatus.db

touch /usr/local/nagios/var/nsca.status && chown nagios:nagios -R /usr/local/nagios/var/nsca.status
touch /usr/local/nagios/var/objects.cache && chown nagios:nagios -R /usr/local/nagios/var/objects.cache
touch /usr/local/nagios/var/objects.precache && chown nagios:nagios -R /usr/local/nagios/var/objects.precache
touch /usr/local/nagios/var/cache.log && chown nagios:nagios -R /usr/local/nagios/var/cache.log
touch /usr/local/nagios/var/cache_host.log && chown nagios:nagios -R /usr/local/nagios/var/cache_host.log
touch /usr/local/nagios/var/cache_service.log && chown nagios:nagios -R /usr/local/nagios/var/cache_service.log

/usr/local/nagios/bin/nagios -v -p /usr/local/nagios/etc/nagios.cfg

Das Script im /etc/init.d/ als neues script anlegen und in die Runlevel 2 und 3 Verzeichnisse linken (rcX.d). Als Namen des Links unbedingt die Zahl so wählen, dass das Script vor den Opsview Scripten läuft.

Bei Opsview und somit auch Nagios gibt es die Möglichkeit zwischen zentralen und dezentralen Benachrichtigungen zu wählen.

Zentrale Benachrichtigung:

• + Weniger „Fehlalarme“, da alle States bekannt sind (Dependencies)
• + Wartung der Settings ( MTA, SMS Infrastruktur ) an einem zentralen Ort
• – Bei Ausfall des Masters (Hardware, Software, Netzwerk, Gateways) keine Benachrichtigungen
• – Bei Ausfall der Mail Infrastruktur keine Benachrichtigungen

Dezentrale Benachrichtigung:

• + Benachrichtigung unabhängig vom Master Status
• – Möglicherweise Fehlalarme durch fehlende Dependency States
• – Höherer Wartungsaufwand ( MTA, Authentifizierungen usw.)

Alles in allem spricht für mich die dezentrale Lösung. Wir wollen doch in jedem Fall eine Benachrichtigung. Die zentrale Lösung ist für mich ein Single Point of Failure den es zu vermeiden gilt. Während es noch relativ einfach ist, auf jedem Monitoringserver einen MTA aufzubauen, wird es bei SMS Notifications schon schwerer. Hier ist entweder die dauerhafte Kommunikation mit einem Dienstleister im Internet sicher zu stellen oder eine eigenen SMS-Infrastruktur zu betreiben. Diese setzt sich im einfachsten Fall aus einem alten GSM-Handy mit Datenkabel oder einem UMTS – Stick zusammen. Dank smstools, sendsms usw. ist es recht einfach SMS-Nachrichten von der Kommandozeile zu versenden.

Der UMTS-Stick hat allerdings die Nase vorn. Mit ihm ist es auch gleich möglich redundante Übertragungswege aufzubauen. Bei Ausfall eines Gateways, kann so zum Beispiel ein Eventhandler eine WAN-Verbindung über UMTS und anschließend einen IPSec oder OpenVPN Tunnel zum Masterserver aufbauen.

Wenn der Slave server in einem RZ betrieben wird, in dem noch andere Kunden zugriff auf das Rack haben, sollten allerdings diebstahlsichernde Massnahmen für die SIM-Karte getroffen werden. Die PIN ist absolut notwendig, besser sollte aber der Stick zusätzlich über das Monitoring überwacht werden und bei abziehen oder Deaktivierung des Sticks ein Alarm ausgelöst werden.