Server Monitoring

Aus revampedia


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.

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.

anderes

apybot