Installationshandbuch:Sensors
|
Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung. |
Überwachung der Serverhardware
| Hinweis: Die Überwachung geht nur mit Rechnern, die eine Überwachung der Hardware-Sensoren per IIC-Bus erlauben. |
Damit gemeint sind Sensoren, die in den Chipsätzen integriert sind und die zum Beispiel die Spannungen sowie Temperaturen von Prozessor und Chipsatz überwachen. Diese sind in der Regel über den SMbus (I²C-Bus) auf dem Mainboard angeschlossen.
Außerdem stellen die meisten Festplatten mit der integrierten Elektronik eine weitere Überwachungsmöglichkeit dar. Hier sind Lesefehler der Hardware ablesbar. Zudem kann auch ein physischer Test der Festplatte angeschoben werden. Bedingung dabei ist, dass die Festplatte S.M.A.R.T. unterstützt und diese Unterstützung im BIOS aktiviert ist. Oft kann man auch die Temperatur der Festplatte auslesen.
Einrichtung der Sensoren
Melden Sie sich als root an.
Geben Sie den Befehl:
sensors-detect
Damit startet ein Programm, dass nahezu alle Kernel-Module für Sensoren testet und die wahrscheinlichsten auswählt. Sie erhalten eine Reihe von (englischen) Fragen, die meist nur mit ENTER zu bestätigen sind. Schlimmstenfalls reagiert der Rechner nicht mehr. Dann sollten Sie neu starten und beim nächsten Versuch mit diesem Befehl diese Frage mit [n] beantworten.
Am Ende schreibt dieses Programm die wahrscheinlichsten Module in eine Datei /etc/sysconfig/lm_sensors, die Sie noch bearbeiten können.
Ist dieser Test erfolgreich, testen Sie mit dem Befehl
/etc/init.d/boot.sensors start
die Funktionsfähigkeit dieser Einrichtung. Gibt es keine Fehlermeldung, machen Sie mit dem Befehl
insserv boot.sensors
diese Änderung dauerhaft. Dann werden bei jedem zukünftigen Rechnerstart diese Überwachungsmodule geladen.
Einrichtung der Festplattenüberwachung
Damit diese Festplattenüberwachung arbeiten kann, muss die Festplatte das sogenannte SMART-Management unterstützen. Das ist bei Festplatten seit etwa 2001 meist der Fall. Ältere Festplatten können diese Option haben, aber nicht immer. Verschiedentlich muss dieses S.M.A.R.T. erst im BIOS aktiviert werden. Unter Linux ist es bei den meisten Boards aber möglich, auf SMART auch dann zurückzugreifen, wenn es im BIOS nicht eingeschaltet ist.
Starten Sie als root zunächst testweise den Daemon mit dem Befehl:
/etc/init.d/smartd start
Lesen Sie die Meldungen in der Datei /var/log/messages. Hier finden Sie meist viele Hinweise, dass zum Beispiel /dev/sda nicht existiert. Das ist unkritisch. Nur wenn echte Meldungen auftreten, die auf einen Absturz des Daemons hinweisen, sollten Sie auf weitere Experimente verzichten.
Haben Sie keine Fehlermeldungen erhalten, können Sie diese Daemonen fest in den Systemstart einbinden. Dazu nutzen Sie die Befehle:
insserv smartd
insserv boot.sensors
Danach starten Sie den Server neu. Die Einrichtung der Hardwareüberwachung ist damit abgeschlossen.
Nutzung
Hardware direkt am Server überwachen
Als root stehen Ihnen nun ein paar Befehle zur Verfügung, um die Einrichtung zu überprüfen.
Befehl sensors
zeigt nun Informationen über die Hardware an:
it87-isa-0290 Adapter: ISA adapter VCore 1: +1.74 V (min = +1.42 V, max = +1.57 V) ALARM VCore 2: +1.23 V (min = +2.40 V, max = +2.61 V) ALARM +3.3V: +6.60 V (min = +3.14 V, max = +3.46 V) ALARM +5V: +4.92 V (min = +4.74 V, max = +5.24 V) +12V: +12.24 V (min = +11.40 V, max = +12.60 V) -12V: -7.95 V (min = -12.63 V, max = -11.41 V) ALARM -5V: -3.72 V (min = -5.24 V, max = -4.76 V) ALARM Stdby: +5.06 V (min = +4.74 V, max = +5.24 V) VBat: +0.00 V fan1: 4115 RPM (min = 0 RPM, div = 8) fan2: 0 RPM (min = 3013 RPM, div = 8) ALARM fan3: 0 RPM (min = 3000 RPM, div = 2) ALARM M/B Temp: +45°C (low = +15°C, high = +40°C) sensor = thermistor CPU Temp: -55°C (low = +15°C, high = +45°C) sensor = thermistor Temp3: +81°C (low = +15°C, high = +45°C) sensor = diode eeprom-i2c-0-51 Adapter: SMBus Via Pro adapter at 0400 Memory type: DDR SDRAM DIMM Memory size (MB): 256
Hier zum Beispiel ein Athlon-Rechner mit VIA-KT333-Chipsatz (Gigabyte-Board). Einige Werte haben keinen Sinn. So überwacht dieses Board z.B. -5V und -12V nicht. Analog sind die Lüfter fan2 und fan3 nicht eingebaut. Wer sich daran stößt, kann die Datei /etc/sensors.conf entsprechend bearbeiten. Achten Sie dabei auf den Abschnitt mit dem richtigen Chipsatz. Hier müsste man z.B. im Abschnitt chip "it87-*" eintragen
ignore fan2 ignore fan3
Analog lassen sich Spannungswerte usw. anpassen, damit die Überwachung funktioniert. Leider ist man in diesem Bereich sehr auf die Informationen der Board-Hersteller angewiesen.
Wenn das Modul eeprom geladen ist, wie in diesem Beispiel, können auch die Informationen aus dem SPD-EEPROM auf dem RAM-Modul gelesen werden. Verwenden Sie dazu den Befehl
decode-dimms.pl
Um die Festplattenüberwachung zu prüfen, nutzen Sie den Befehl
smartctl -a /dev/hda
Die Ausgabe ist relativ lang, hier für eine 10GB-Seagate-Festplatte (gekürzt):
smartctl version 5.26 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: ST310212A
Serial Number: 7EG3EHVQ
Firmware Version: 3.02
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 5
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sun Oct 16 17:07:49 2005 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity was
completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
[.. einiges entfernt]
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x0008 087 075 000 Old_age Offline - 2372785
3 Spin_Up_Time 0x0006 098 098 000 Old_age Always - 0
4 Start_Stop_Count 0x0013 100 100 020 Pre-fail Always - 318
5 Reallocated_Sector_Ct 0x0013 100 100 036 Pre-fail Always - 22
7 Seek_Error_Rate 0x0009 064 060 030 Pre-fail Offline - 30088533367
9 Power_On_Hours 0x0012 094 094 000 Old_age Always - 5976
10 Spin_Retry_Count 0x0013 100 100 090 Pre-fail Always - 0
12 Power_Cycle_Count 0x0013 100 100 000 Pre-fail Always - 484
197 Current_Pending_Sector 0x0030 100 100 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 5278 -
# 2 Extended offline Completed without error 00% 4761 -
Interessant vor allem die letzten Zeilen: Es ist grundsätzlich möglich, über diese SMART-Elektronik einen physischen Festplattentest durchführen zu lassen. Das sollte aber möglichst in Zeiten erfolgen, in denen kaum Festplattenzugriffe erfolgen, also z.B. nachts. Einen ausführlichen Test erzwingen Sie mit dem Befehl
smartctl -t long /dev/hda
Der Test startet und gibt eine ungefähre Angabe, wie lange die Elektronik brauchen sollte. Für diese 10GB-Platte sind es etwa 15 Minuten, eine 60GB-Platte benötigt etwa eine Stunde. Das Ergebnis ist nach dieser Zeit in der Ausgabe von smartctl -a /dev/hda zu sehen.
Sollte dieser Test mit einer Fehlermeldung enden, sollte man dringend die Festplatte wechseln. Anfangs kann das SMART-Management noch einzelne Reserve-Sektoren benutzen, um die Ausfälle zu kompensieren. Ein Totalausfall ist aber zu befürchten - also sollte man bald reagieren!
Hardware vom Client aus überwachen
Arktur ist für die Überwachung von Linux aus bereits fertig eingerichtet. Dazu wird bei jedem Systemstart ein Daemon gestartet, der alle nötigen Informationen auslesen kann und im Netzwerk zur Verfügung stellt: ksysguardd.
Hat man einen Linux-Client mit KDE findet sich das Gegenstück als "ksysguard", meist unter System -> Überwachung -> Performance-Monitor(Systemüberwachung).
- Abbildung: KDE-Systemüberwachung
Beim ersten Start wird nur der lokale Rechner überwacht (localhost). Um nun auch Arktur zu überwachen, müssen Sie sich mit dem Server verbinden. Dazu wählen Sie unter Datei den Eintrag "mit Rechner verbinden".
- Abbildung: Menü Datei
Es öffnet sich ein Fenster, in dem Sie die Verbindungsparameter einstellen müssen. Hier geben Sie entweder den Rechnernamen oder die IP-Adresse ein und wählen "Daemon" mit dem Standard-Port 3112.
- Abbildung: Verbinden mit Rechner
Nun dürfte im Überwachungsbaum der Rechner auftauchen. Sie können nun ein neues Blatt erzeugen und die benötigten Informationen auf dieses Blatt ziehen. Lesen Sie am besten im Handbuch von ksysguard nach, wie Sie diese Blätter einrichten können.
Nach dieser Einrichtung können Sie problemlos die Auslastung des Systems sowie die Hardwaresensoren überwachen, wie im folgenden Bild die Prozessorauslastung und den Speicher.
- Abbildung: CPU-Performance-Monitor
Welche Sensoren Sie auf ihr Arbeitsblatt ziehen wollen, müssen Sie selbst anhand der Hardware entscheiden.