Server Monitoring: Unterschied zwischen den Versionen
(→zabbix) |
(→zabbix) |
||
Zeile 90: | Zeile 90: | ||
Als Alternative zum ''HostnameItem'' kann auch ein paar Zeilen vorher der ''Hostname'' angegeben werden. | Als Alternative zum ''HostnameItem'' kann auch ein paar Zeilen vorher der ''Hostname'' angegeben werden. | ||
=== Webinterface === | === Webinterface === | ||
+ | Der grösste Teil der Konfiguration wird im Webinterface vorgenommen. | ||
+ | ==== Automatische Registrierung von Agents ==== | ||
+ | Wird erklärt im [https://www.zabbix.com/documentation/2.4/manual/discovery/auto_registration 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''' | ||
+ | <pre> | ||
+ | ... | ||
+ | ServerActive=192.168.100.253 | ||
+ | ... | ||
+ | HostnameItem=system.hostname | ||
+ | ... | ||
+ | HostMetadata=Client | ||
+ | ... | ||
+ | </pre> | ||
+ | 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'': | ||
+ | <pre> | ||
+ | Name: Autoregister LTSP Client | ||
+ | Default Subject: Auto registration: {HOST.HOST} | ||
+ | Default Message: Host name: {HOST.HOST} | ||
+ | Host IP: {HOST.IP} | ||
+ | Agent port: {HOST.PORT} | ||
+ | </pre> | ||
+ | Reiter ''Conditions'', New Condition: | ||
+ | <pre> | ||
+ | Host metadata: like: Client | ||
+ | </pre> | ||
+ | Reiter ''Operations'': | ||
+ | <pre> | ||
+ | Action operations: Add Host | ||
+ | Add to Host Group: Clients | ||
+ | Link to template: LTSP Thin Clients | ||
+ | </pre> | ||
+ | Die Host Group und das Template müssen natürlich dafür schon existieren. Siehe [https://www.zabbix.com/documentation/2.4/manual/config/hosts/host Zabbix Dokumentation]. Nun sollten die Clients sich beim aufstarten automatisch registrieren. | ||
== anderes == | == anderes == |
Version vom 22. Dezember 2015, 16:36 Uhr
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.