Server Monitoring
Festplatten
RAID (mdadm/mdmon)
mdadm verschickt Emails an root, sobald im RAID-Array etwas schief läuft. In /etc/mdadm/mdadm.conf ist es möglich, die Email-Addresse zu ändern, aber es wird am besten in /etc/aliases eine Weiterleitung der Emails eingerichtet, z.B. "root: admin@example.com". Es muss natürlich im vornhinein sichergestellt werden, dass der Server selbst Emails verschicken kann.
Falls ein neues Array hinzugefügt wird und mdmon dieses nicht automatisch in /etc/mdadm/mdadm.conf einträgt, muss man die Konfigurationsdatei selbst bearbeiten. Mit dem Kommando mdadm --detail /dev/md/PFAD-ZUM-ARRAY findet man die UUID (dies ist NICHT die gleiche UUID, die von blkid ausgegeben wird!) und den Namen des Arrays. Anschliessend muss der mdmonitor Dienst neu gestartet werden.
Beispiel pingu:
# definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=4e3062c6:85a4cd41:4816cc95:8e687b5a name=pingu:0 ARRAY /dev/md/pingu\:1 metadata=1.2 UUID=a99c66f0:f7ce60a7:b237fd92:67cf6924 name=pingu:1
smartd/smartmontools
smartd überwacht den Zustand der Festplatten auf der dom0. smartd wird im Debian-Paket smartmontools mitgeliefert.
Zuerst müssen wir herausfinden, wie man die SMART-Daten der Festplatten abruft. Bei normalen Computern ist dies meist einfach:
# smartctl -a /dev/sdX
/dev/sdX ist durch die zu prüfende Festplatte zu ersetzen, z.B. /dev/sda, /dev/sdb, etc.
Etwas komplizierter kann es werden bei Rackservern mit Hardware-RAID Controllern. Beim Dell Poweredge (pingu) zum Beispiel, sieht es so aus:
# smartctl -a -d megaraid,0 /dev/sda # smartctl -a -d megaraid,1 /dev/sdb
Und so weiter bis megaraid,5 /dev/sdf
Bei Servern mit Adaptec AAC-RAID Controllern ist dies der richtige Befehl:
# smartctl -a -d scsi /dev/sg6 # smartctl -a -d scsi /dev/sg7
Bis /dev/sg11. /dev/sg[0-5] ensprechen nicht den Festplatten, dies sind die Devicenames für die jeweiligen SAS-Controller.
Jetzt, wo wir den Befehl kennen, können wir die korrekten Einträge in /etc/smartd.conf einfügen.
Beispiel AACRAID-Controller:
/dev/sg6 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sg7 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sg8 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sg9 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sg10 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sg11 -d scsi -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
Megaraid-Controller:
/dev/sda -d megaraid,0 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sdb -d megaraid,1 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sdc -d megaraid,2 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sdd -d megaraid,3 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sde -d megaraid,4 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner /dev/sdf -d megaraid,5 -a -o on -S on -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
Erklärung zu den Parametern:
- -a: überprüft alle SMART-Parameter
- -d: gibt den Gerätetyp an, wie oben beschrieben
- -m root: schickt Emails an root, falls Fehler gefunden werden
- -n standby: überspringt die Überprüfung, falls die Festplatte im standby-Modus ist
- -o on: aktiviert die automatische SMART-Prüfung (ca. alle vier Stunden, je nach Hersteller unterschiedlich)
- -M exec ...: gibt einen Pfad zu einem Script, das ausgeführt wird, falls es etwas per Email zu melden gibt
zabbix
Zabbix ist ein Open-Source System, welches verschiedenste Daten (Temperaturen, Traffic, Dienste, Anzahl laufender Prozesse, und ganz ganz vieles mehr) an Computer, Server und Netzwerkgeräten überwacht und auf einem Webinterface darstellt.
Server
Auf der Maschine, die als Zabbix-Server dient, müssen die Pakete zabbix-frontend-php und zabbix-server-mysql (oder -pgsql) installiert werden, vorzugsweise direkt aus dem [Zabbix repository http://repo.zabbix.com/zabbix/2.4/debian/][1]. Die Konfiguration sollte zum grössten Teil durch dpkg eingestellt werden. Falls noch Anpassungen erwünscht sind, ist die Konfigurationsdatei in /etc/zabbix/zabbix_server.conf zu finden.
Agent
Bei den Clients, die per zabbix-agent überwacht werden sollen, muss das Paket zabbix-agent installiert und eingerichtet werden. Die zabbix-agents können sich selbstständig beim Server anmelden, was die mühsame Arbeit des Einrichtens jedes einzelnen Clients auf dem Webinterface erspart.
/etc/zabbix/zabbix-agentd.conf
... ##### Passive checks related ### Option: Server Server=[Zabbix-Server Hostname] ... ##### Active checks related ### Option: ServerActive ServerActive=[Zabbix-Server Hostname] ... ### Option: HostnameItem HostnameItem=system.hostname
Als Alternative zum HostnameItem kann auch ein paar Zeilen vorher der Hostname angegeben werden.
Webinterface
Der grösste Teil der Konfiguration wird im Webinterface vorgenommen.
Es kann eine Weile dauern, bis Daten überhaupt vom Server geholt werden, also falls nach der Registration des Agents nichts angezeigt wird, keine Panik: Teepause machen, dann mal wieder schauen ob was gekommen ist. Falls nach einer halben Stunde noch gar nichts kommt, Einstellungen prüfen und ggf. Agent und/oder Server im debug-Modus starten. (/etc/zabbix/zabbix_server.conf respektive /etc/zabbix/zabbix_agent.conf DebugLevel=4)
Automatische Registrierung von Agents
Wird erklärt im Zabbix Handbuch. Spezielles zur Registration von LTSP-Clients:
Der zabbix-agent muss zuerst im Client chroot installiert werden. Da unser Zabbix-Server auf der gleichen physischen Maschine läuft wie der LTSP-Server, kann man der virtuellen Maschine des Zabbix-Servers die Netzwerkschnittstelle des LTSP-Netzwerks zuweisen. Der zabbix-agent im chroot muss auf die IP-Adresse im LTSP-Netz eingestellt werden (Eintrag ServerActive). Weiter setzen wir einen Eintrag für HostnameItem und HostMetadata (in unserem Fall "Client"), damit LTSP-Clients vom Zabbix-Server eindeutig identifiziert werden können.
/opt/ltsp/i386/etc/zabbix/zabbix-agentd.conf
... ServerActive=192.168.100.253 ... HostnameItem=system.hostname ... HostMetadata=Client ...
Unter Configuration/Actions im Webinterface sagen wir jetzt dem Server, was er mit den Daten der neuen zabbix-agents tun soll. Als Event Source wählen wir Auto Registration aus und erstellen wir mit Create Action eine neue Aktion. Reiter Action:
Name: Autoregister LTSP Client
Default Subject: Auto registration: {HOST.HOST}
Default Message: Host name: {HOST.HOST}
Host IP: {HOST.IP}
Agent port: {HOST.PORT}
Reiter Conditions, New Condition:
Host metadata: like: Client
Reiter Operations:
Action operations: Add Host
Add to Host Group: Clients
Link to template: LTSP Thin Clients
Die Host Group und das Template müssen natürlich dafür schon existieren. Siehe Zabbix Dokumentation. Nun sollten die Clients sich beim aufstarten automatisch registrieren.
SNMP
Das Simple Network Management Protocol ermöglicht die Überwachung von diversen Netzwerkgeräten, wie z.B. Router, Switches, Server und Drucker etcetera. Nur ist das leider alles andere als simpel.
$ snmpwalk -v2c -c public dlink32 | wc -l 8056
Also, da spuckt unser D-Link Switch schon mal über 8000 Zeilen aus wenn man ihn fragt, wie es ihm nun so geht. Ganz, ganz geschwätzig! Zudem sehen die Ausgaben in etwa so aus:
iso.3.6.1.2.1.2.2.1.3.1 = INTEGER: 117
Hä? Wie soll mir das jetzt helfen? Wir können das mal so interpretieren: der Eintrag iso.3.6.1.2.1.2.2.1.3.1 hat den Wert INTEGER: 117. Das ist schon mal schön, aber wir wissen weder, was der Eintrag iso.3.6.1.2.1.2.2.1.3.1 bedeutet, noch was der Wert INTEGER: 117 in diesem Kontext meint. Dafür gibt es [MIBs], welche die SNMP-Daten (OIDs) in eine durch Menschen interpretierbare Sprache übersetzt. In debian ist dafür das Paket snmp-mibs-downloader im non-free Repository verfügbar. Das obige Beispiel, zum Beispiel, heisst übersetzt:
IF-MIB::ifType.1 = INTEGER: gigabitEthernet(117)
Ja das ist ja schon hilfreicher. Interface 1 auf dem managed Switch ist ein gigabittiges Interface! Schön zu wissen! Am besten nimmt man sich einen Tag oder zwei, die ganze Ausgabe von snmpwalk durchzulesen. Damit zabbix diese Werte auch versteht automagisch aufnimmt, muss ein Template erstellt werden, das die Daten aufbereitet. Glücklicherweise stellt die [zabbix Webseite] uns viele Templates zur Verfügung, die importiert werden können.
Benachrichtigung über verfügbare Updates
Wenn man sich in einer Situation findet, in der man für mehrere Server zuständig ist, ist es hilfreich, wenn apt-get update automatisch ausgeführt wird. Eine von vielen möglichen Lösungen ist das debian-Paket apt-show-versions. Dieses Paket hinterlegt ein Script in /etc/cron.daily, das täglich mal schaut, ob etwas verfügbar ist. Wir setzen für den zabbix-agent einen UserParameter, der uns erzählt, ob es da was gibt. [2]
/etc/zabbix/zabbix_agentd.conf
... ### Option: UserParameter UserParameter=updates.available,apt-show-versions | grep upgradeable | wc -l ...
Im Webinterface muss nur noch ein Item für apt-show-versions gesetzt werden, z.B.:
Name: Updates Available Type: Zabbix agent Key: updates.available Update interval (in sec): 9999 Applications: OS
Und noch ein Trigger:
Name: pingu-ltsp: Available Updates
Expression: {pingu-ltsp:updates.available.diff()}>0
Severity: Information
Zusätzlich können noch Email-Benachrichtigungen eingeschaltet werden, falls erwünscht.
