Installationshandbuch:Sensors

Aus Delixs
Version vom 9. März 2012, 10:02 Uhr von Schoffer (Diskussion | Beiträge) (kat)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen


Baustelle 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).


KDE-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".


Menü Datei
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.


Verbindungseinstellungen
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.


Performance-Monitor
Abbildung: CPU-Performance-Monitor


Welche Sensoren Sie auf ihr Arbeitsblatt ziehen wollen, müssen Sie selbst anhand der Hardware entscheiden.



zurück | Hauptseite