Repository 32bit  Forum
Repository 64bit  Wiki

System monitoring on Slackware: Lm-sensors & Gkrellmd: differenze tra le versioni

Da Slacky.eu.
m (Installazione e utilizzo)
 
(3 revisioni intermedie di un utente non mostrate)
Riga 1: Riga 1:
== Introduzione ==
+
[[Category:Multimediale]]
  +
= Introduzione =
Può capitare di dover monitorare alcuni parametri del nostro hardware, in modo da essere
Può capitare di dover monitorare alcuni parametri del nostro hardware, in modo da essere
avvisati in tempo prima di raggiungere gli stadi critici del nostro sistema.
avvisati in tempo prima di raggiungere gli stadi critici del nostro sistema.
Riga 16: Riga 16:
kernel:
kernel:
less /usr/src/linux­2.4.23/Documentation/i2c/summary
+
less /usr/src/linux-­2.4.23/Documentation/i2c/summary
che a tal proposito spiega:
che a tal proposito spiega:
Riga 33: Riga 33:
Because the SMBus is just a special case of the generalized I2C bus, we
Because the SMBus is just a special case of the generalized I2C bus, we
can simulate the SMBus protocol on plain I2C busses. The reverse is
can simulate the SMBus protocol on plain I2C busses. The reverse is
regretfully impossible.
+
regretfully impossible.
== Installazione e utilizzo ==
+
= Installazione e utilizzo =
Lo strumento utilizzato è il noto '''lm-sensors''' in grado di fornire informazioni sullo status della
Lo strumento utilizzato è il noto '''lm-sensors''' in grado di fornire informazioni sullo status della
Riga 86: Riga 86:
bogomips : 2398.61
bogomips : 2398.61
root@glock:/usr/src/lm_sensors­2.8.2/i2c­2.8.2# lspci ­-v
+
root@glock:/usr/src/lm_sensors-­2.8.2/i2c-­2.8.2# lspci ­-v
00:00.0 Host bridge: '''VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x]''' (rev c4)
00:00.0 Host bridge: '''VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x]''' (rev c4)
Subsystem: Giga­byte Technology: Unknown device 5000
+
Subsystem: Giga-­byte Technology: Unknown device 5000
Flags: bus master, medium devsel, latency 8
Flags: bus master, medium devsel, latency 8
Memory at e0000000 (32-­bit, prefetchable) [size=128M]
Memory at e0000000 (32-­bit, prefetchable) [size=128M]
Riga 134: Riga 134:
avremo il file lm_sensors da depositare in /etc/rc.d/init.d come un normale servizio.
avremo il file lm_sensors da depositare in /etc/rc.d/init.d come un normale servizio.
L'output deve es
+
L'output deve essere simile a questo:
== Gkrellm: monitoraggio completo del sistema ==
+
To make the sensors modules behave correctly, add these lines to
  +
/etc/modules.conf:
  +
#----­­­­cut here----­­­­
  +
# I2C module options
  +
alias char-­major-­89 i2c-­dev
  +
#----­­­­cut here----­­­­
  +
  +
To load everything that is needed, add this to some /etc/rc* file:
  +
  +
#----­­­­cut here----­­­­
  +
# I2C adapter drivers
  +
modprobe i2c­-isa
  +
# I2C chip drivers
  +
modprobe via686a
  +
# sleep 2 # optional
  +
/usr/local/bin/sensors -­s # recommended
  +
#----­­­­cut here----­­­­
  +
  +
Quello che è strettamente necessario sono proprio alcuni di questi moduli in grado di dialogare
  +
con le parti hardware del nostro sistema per rilevare informazioni.
  +
  +
Aggiungiamo i moduli necessari al file rc.modules e modules.conf:
  +
  +
# I2C adapter drivers
  +
modprobe i2c-­viapro
  +
modprobe i2c-­isa
  +
modprobe i2c-­dev
  +
# I2C chip drivers
  +
modprobe i2c-­piix4
  +
modprobe eeprom
  +
modprobe via686a
  +
#Altri moduli
  +
modprobe lm78
  +
modprobe lm75
  +
  +
Ora si possono caricare i moduli con il comando ''modprobe nome_modulo'' o eseguire un
  +
''depmod -a''.
  +
Per evitare di riavviare il sistema si può usare il comando:
  +
root@glock:/usr/src/lm_sensors-­2.8.2/i2c-­2.8.2# sensors ­s
  +
  +
= Gkrellm: monitoraggio completo del sistema =
Perdo un po' di tempo per segnalare a chi non lo conoscesse questo ottimo prodotto:
Perdo un po' di tempo per segnalare a chi non lo conoscesse questo ottimo prodotto:
Riga 230: Riga 230:
qualche host attraverso internet piuttosto che in rete locale.
qualche host attraverso internet piuttosto che in rete locale.
== Configurazione Gkrellmd over SSH ==
+
= Configurazione Gkrellmd over SSH =
=== Host monitorato ===
+
== Host monitorato ==
<ol>
<ol>
<li>Creare uno user con cui eseguire il server: </li>
<li>Creare uno user con cui eseguire il server: </li>
Riga 242: Riga 242:
</ol>
</ol>
=== Stazione di monitoraggio ===
+
== Stazione di monitoraggio ==
<ol>
<ol>
<li>Creare uno user con cui eseguire il server: </li>
<li>Creare uno user con cui eseguire il server: </li>
Riga 260: Riga 260:
http://web.wt.net/~billw/gkrellm/gkrellm.html
http://web.wt.net/~billw/gkrellm/gkrellm.html
== Note ==
+
= Note =
Non ho grandi competenze in materia, ho usato questi strumenti soprattutto per dei fini pratici
Non ho grandi competenze in materia, ho usato questi strumenti soprattutto per dei fini pratici
immediati. Il mio scopo era quello di ottenere i dati relativi al voltaggio ed alla temperatura del
immediati. Il mio scopo era quello di ottenere i dati relativi al voltaggio ed alla temperatura del
Riga 275: Riga 275:
caricato.
caricato.
== Risorse ==
+
= Risorse =
* http://secure.netroedge.com/~lm78/
* http://secure.netroedge.com/~lm78/
* http://secure.netroedge.com/~lm78/FAQ.txt
* http://secure.netroedge.com/~lm78/FAQ.txt
Riga 281: Riga 281:
Autore: [[utente:Pavan| Paolo Pavan]]
+
Autore: [[utente:Pavan| Paolo Pavan]]
  +
Data: Ottobre 2003
Data: Ottobre 2003

Versione attuale delle 17:11, 19 set 2006

Indice

[modifica] Introduzione

Può capitare di dover monitorare alcuni parametri del nostro hardware, in modo da essere avvisati in tempo prima di raggiungere gli stadi critici del nostro sistema. Come si sa da tempo per la Mother Board (MB) dei nostri sistemi (parliamo di sistemi Intel, almeno a questi si fa riferimento in questo breve documento) è diventato possibile controllare alcuni parametri vitali del sistema, come la temperatura, le tensioni di alimentazione e le velocità delle ventole di raffreddamento.

Questo sistema si è evoluto ed ora si può addirittura in alcuni casi controllare con precisione alcuni di questi parametri come gli RPM (Round per Minute) delle ventole e ottenere altri dati sul nostro sistema come le schede di memoria. Questo è reso possibile dall'SMBus (System Management Bus), un particolare tipo di bus che ci restituisce informazioni ottenute direttamente dalla MB del nostro sistema.

Informazioni più dettagliate sul protocollo I2C e SMBus si trovano sotto la documentazione del kernel:

less /usr/src/linux-­2.4.23/Documentation/i2c/summary 

che a tal proposito spiega:

I2C and SMBus 
============= 
I2C (pronounce: I squared C) is a protocol developed by Philips. It is a 
slow two­wire protocol (10­100 kHz), but it suffices for many types of 
devices. 

SMBus (System Management Bus) is a subset of the I2C protocol. Many 
modern mainboards have a System Management Bus. There are a lot of 
devices which can be connected to a SMBus; the most notable are modern 
memory chips with EEPROM memories and chips for hardware monitoring. 

Because the SMBus is just a special case of the generalized I2C bus, we 
can simulate the SMBus protocol on plain I2C busses. The reverse is 
regretfully impossible.

[modifica] Installazione e utilizzo

Lo strumento utilizzato è il noto lm-sensors in grado di fornire informazioni sullo status della nostra MB, ed è stato testato su vari sistemi con versioni di Slackware 8.0, 9.0 e 9.1 e versioni di kernel 2.4.2x.

Sono necessari due pacchetti:

  1. http://freshmeat.net/redir/lm_sensors/5940/url_tgz/lm_sensors-­2.8.2.tar.gz
    contiene i moduli necessari da caricare per effettuare il monitoraggio
  2. http://secure.netroedge.com/~lm78/archive/i2c-­2.8.2.tar.gz
    contiene i moduli necessari

I moduli, che possono essere installati dall'apposito pacchetto oppure compilati nel kernel, si trovano sotto Character Devices/I2C Support:

<M> I2C support 
<M> I2C bit-­banging interfaces (NEW) 
<M> ELV adapter (NEW) 
<M> Velleman K9000 adapter (NEW) 
<M> NatSemi SCx200 I2C using GPIO pins (NEW) 
(12) GPIO pin used for SCL (NEW) 
(13) GPIO pin used for SDA (NEW) 
<M> NatSemi SCx200 ACCESS.bus (NEW) 
<M> I2C PCF 8584 interfaces (NEW) 
<M> Elektor ISA card (NEW) 
<M> I2C device interface (NEW) 
<M> I2C /proc interface (required for hardware sensors) (NEW) 
  • Per non sbagliare i moduli possono essere tutti compilati, anche se alcuni non sono necessari per il nostro tipo di hardware.

Siccome spesso il funzionamento e la relativa acquisizione di dati sono legati al nostro hardware, vediamo alcuni dati sul sistema utilizzato:

root@glock:/usr/src/lm_sensors­-2.8.2/i2c-­2.8.2# cat /proc/cpuinfo 
processor : 0 
vendor_id : GenuineIntel 
cpu family : 6 
model : 11 
model name : Intel(R) Celeron(TM) CPU 1200MHz 
stepping : 1 
cpu MHz : 1202.745 
cache size : 256 KB 
fdiv_bug : no 
hlt_bug : no 
f00f_bug : no 
coma_bug : no 
fpu : yes 
fpu_exception : yes 
cpuid level : 2 
wp : yes 
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse 
bogomips : 2398.61 
root@glock:/usr/src/lm_sensors-­2.8.2/i2c-­2.8.2# lspci ­-v 
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 
Subsystem: Giga-­byte Technology: Unknown device 5000 
Flags: bus master, medium devsel, latency 8 
Memory at e0000000 (32-­bit, prefetchable) [size=128M] 
Capabilities: [a0] AGP version 2.0 
Capabilities: [c0] Power Management version 2 

00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-­if 00 [Normal 
decode]) 
Flags: bus master, 66Mhz, medium devsel, latency 0 
Bus: primary=00, secondary=01, subordinate=01, sec­latency=0 
I/O behind bridge: 00009000-­00009fff 
Memory behind bridge: d7a00000-­d7afffff 
Prefetchable memory behind bridge: d7800000-­d78fffff 
Capabilities: [80] Power Management version 2 

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 
Subsystem: Giga-­byte Technology: Unknown device 5001 
Flags: bus master, stepping, medium devsel, latency 0 
Capabilities: [c0] Power Management version 2 

00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 
Subsystem: Giga-­byte Technology: Unknown device 5003 
Flags: medium devsel 
Capabilities: [68] Power Management version 2 

L'installazione è relativamente semplice, anche se potrebbe produrre qualche errore. Prima installiamo i2c (meglio la versione più aggiornata):

cd /usr/src/lm_sensors­2.8.2/i2c-­2.8.2 
make && make install 

E poi lm-­sensors:

cd /usr/src/lm_sensors-­2.8.2 
make && make install 

Infine creiamo i device per i2c:

/usr/src/lm_sensors-­2.8.2/prog# mkdev/mkdev.sh 

A questo punto possiamo usare il comando sensors-­detect per eseguire lo scan del sistema che ci porterà ad identificare automaticamente i moduli da caricare per il nostro tipo di hardware. Alla fine della rilevazione, che può impiegare severamente il nostro sistema aumentando notevolmente il carico di lavoro, otterremo i moduli da caricare al boot del sistema e le indicazioni per far partire lm-sensors. Il tipo di avvio è compatibile con RedHat, per cui avremo il file lm_sensors da depositare in /etc/rc.d/init.d come un normale servizio.

L'output deve essere simile a questo:

To make the sensors modules behave correctly, add these lines to 
/etc/modules.conf: 
#----­­­­cut here----­­­­ 
# I2C module options 
alias char-­major-­89 i2c-­dev 
#----­­­­cut here----­­­­ 

To load everything that is needed, add this to some /etc/rc* file: 

#----­­­­cut here----­­­­ 
# I2C adapter drivers 
modprobe i2c­-isa 
# I2C chip drivers 
modprobe via686a 
# sleep 2 # optional 
/usr/local/bin/sensors -­s # recommended 
#----­­­­cut here----­­­­ 

Quello che è strettamente necessario sono proprio alcuni di questi moduli in grado di dialogare con le parti hardware del nostro sistema per rilevare informazioni.

Aggiungiamo i moduli necessari al file rc.modules e modules.conf:

# I2C adapter drivers 
modprobe i2c-­viapro 
modprobe i2c-­isa 
modprobe i2c-­dev 
# I2C chip drivers 
modprobe i2c-­piix4 
modprobe eeprom 
modprobe via686a 
#Altri moduli 
modprobe lm78 
modprobe lm75 

Ora si possono caricare i moduli con il comando modprobe nome_modulo o eseguire un depmod -a. Per evitare di riavviare il sistema si può usare il comando:

root@glock:/usr/src/lm_sensors-­2.8.2/i2c-­2.8.2# sensors ­s

[modifica] Gkrellm: monitoraggio completo del sistema

Perdo un po' di tempo per segnalare a chi non lo conoscesse questo ottimo prodotto: Gkrellm Gtk Monitor http://web.wt.net/~billw/gkrellm/gkrellm.html

Consente di monitorare praticamente tutte le risorse del sistema e si interfaccia ottimamente con lm­sensors per fornirci i dati ricavati. La sua interfaccia è di tipo grafico, facile da configurare e da adattare alle proprie esigenze. Consente inoltre di impostare livelli di allarme che ci avvisano nel caso di superamento della soglia. È davvero uno strumento molto potente per il monitoraggio del sistema e richiede davvero poco sforzo per poter funzionare. Può essere utilizzato anche su server, magari accedendo da remoto attraverso VNC al desktop grafico.

Per l'installazione:

wget http://freshmeat.net/redir/gkrellm/32404/url_bz2/gkrellm­2.1.24.tar.bz2 
bunzip2 gkrellm-­2.1.24.tar.bz2 
tar xvf gkrellm-­2.1.24.tar 
cd gkrellm-­2.1.24 
make && make install

Queste sono le sue features:

GKrellM Features 
================ 
* SMP CPU, Disk, Proc, and active net interface monitors with LEDs. 
* Internet monitor that displays current and charts historical port hits. 
* Memory and swap space usage meters and a system uptime monitor. 
* File system meters show capacity/free space and can mount/umount. 
* A mbox/maildir/MH/POP3/IMAP mail monitor which can launch a mail reader 
or remote mail fetch program. 
* Clock/calendar and hostname display. 
* Battery laptop battery monitor. 
* CPU/motherboard temperature/fan/voltages display with warnings and 
alarms. Linux requires lm_sensors modules and Windows requires MBM. 
* Multiple monitors managed by a single process to reduce system load. 
* A timer button that can execute PPP or ISDN logon/logoff scripts. 
* Charts are autoscaling with configurable grid line resolution, or 
can be set to a fixed scale mode. 
* Separate colors for "in" and "out" data. The in color is used for 
CPU user time, disk read, forks, and net receive data. The out color 
is used for CPU sys time, disk write, load, and net transmit data. 
* Commands can be configured to run when monitor labels are clicked. 
* GKrellM is plugin capable so special interest monitors can be created. 
* Data can be collected from a gkrellmd server running on a remote machine. 
* Many themes are available. 

Come si può notare consente il monitoraggio delle risorse del sistema (RAM, uptime, cpu, proc) e dei dispostivi hardware (dischi, interfacce) e, se installato lm-sensors, anche dei parametri della nostra Mother Board. Volendo ci consente anche il controllo di una mailbox e ci avvisa in caso di nuove email ricevute. La cosa più sorprendente è che rileva in modo automatico i dati che prima ottenevamo da riga di comando con il comando sensors. Il tutto viene visualizzato in modo più sintetico ma molto più intuitivo: potremo avere in un solo colpo d'occhio sotto controllo lo stato globale del nostro sistema.

Questo strumento consente di configurare semplicemente anche i limiti entro cui si viene avvisati dal sistema, attraverso un comando qualsiasi, ad esempio ci si può fare inviare una email piuttosto che fargli emettere un suono. È sufficiente cliccare sulla risorsa interessata e configurare i limiti di alert o di warning voluti. In questo modo gkrellm monitorerà il sistema per noi avvisandoci nel caso in cui i limiti vengano superati.

Accanto ad ogni risorsa comparirà un pallino rosso con una lettera A ad indicarci lo stato di monitoraggio attivo. Visivamente sul pannello vedremo il valore "pulsare" in rosso se ha superato il limite massimo di alert (ad esempio la temperatura o il voltaggio della CPU) oppure in giallo se ha superato i limiti di warning. Nel dettaglio la finestra di "Set Alert" sarà del tipo:

In questo caso sono stati forzati dei valori per i limiti che in realtà non sono tali, solo per verificarne l'efficacia. Ogni 100 secondi il nostro sistema invierà una mail a root avvisandolo del superamento dei limiti di temperatura, oppure con un più semplice comando del tipo cat alarm.au >/dev/audio, il nostro server emetterà un suono di allarme. Ma le funzionalità di questo programma davvero utile non finiscono qua. Infatti lanciando il demone gkrellmd potremmo effettuare interrogazioni remote verso server che erogheranno questo servizio. Basta installare il programma sui server che ci interessa monitorare ed eseguire da console il comando gkrellmd. A questo punto da un altro sistema nell'ambiente grafico potremmo eseguire il comando:

gkrellm -f -s nome_host/IP 

per vederci apparire la schermata relativa all'host remoto che vogliamo monitorare. Il suo pannello di controllo potrà essere configurato allo stesso identico modo di quello dell'host locale.

Per chi volesse usare questo strumento per effettuare il monitoraggio di sistemi remoti, magari sfruttando le potenzialità di tunneling offerte da ssh potete consultare questo bel documento http://www.stearns.org/doc/network­monitoring.v0.1.1.html che vi spiega nel dettaglio come raccogliere informazioni da un sistema remoto e visualizzarle in un pannello grafico da un client GNU/Linux, protette dalla crittografia grazie a SSH. Io l'ho sperimentato e vi lascio i miei passaggi, semplici ma efficaci. L'uso di SSH aiuta a nascondere dati che è meglio non far passare in chiaro, specie se si effettua il monitoraggio di qualche host attraverso internet piuttosto che in rete locale.

[modifica] Configurazione Gkrellmd over SSH

[modifica] Host monitorato

  1. Creare uno user con cui eseguire il server:
  2. adduser gkrellmd 
    
  3. Eseguire gkrellmd:
  4. nohup gkrellmd ­-u 3 ­-P 10000 ­-m 2 ­-a 127.0.0.1 ­-a 10.1.1.226 & 
    
  5. Impostare tunnel SSH da stazione monitorata a stazione di monitoraggio:
  6. ssh ­-L 10001:10.1.1.226:10000 -l gkrellmd 10.1.1.9
    

[modifica] Stazione di monitoraggio

  1. Creare uno user con cui eseguire il server:
  2. adduser gkrellmd 
    
  3. Abilitare tunnel SSH verso la stazione da monitorare:
  4. ssh ­-L 10001:10.1.1.226:10000 -l gkrellmd 10.1.1.226 
    
  5. Impostare connessione sicura finale verso l'host da monitorare:
  6. gkrellm ­-f ­-s 127.0.0.1 ­-P 10001 & 
    

Credo che siano possibili altre procedure di tunneling con programmi tipo stunnel, ma non le ho mai provate. Consiglio anche di tenere sempre d'occhio i bugfix, visto che questo programma ha sofferto in passato di Buffer Overflow ed è bene tenerlo sempre aggiornato.

Per saperne di più consiglio di visitare comunque il sito ufficiale sicuramente ben documentato e con tutte le informazioni necessarie per la sua ottimizzazione: http://web.wt.net/~billw/gkrellm/gkrellm.html

[modifica] Note

Non ho grandi competenze in materia, ho usato questi strumenti soprattutto per dei fini pratici immediati. Il mio scopo era quello di ottenere i dati relativi al voltaggio ed alla temperatura del sistema per alcuni sistemi critici, posti in condizioni di temperatura spesso eccessiva. Ho voluto cercare di valutare in modo più preciso il loro grado di sofferenza e con lm-sensors è stato relativamente semplice. Mi interessavano i dati acquisibili dalla MB in tempo reale. Se questo fosse anche il vostro obiettivo, allora spero che queste informazioni possano esservi utili. Se conoscete l'argomento o avete approfondito l'uso di questo strumento, segnalatemelo in modo da poter migliorare il documento. Con i vecchi kernel della versione 2.2 e anche con quelli non recenti della 2.4 si sono manifestati alcuni malfunzionamenti del sistema. Conviene quindi essere consapevoli delle operazioni che si effettuano, prima di trovarsi con sistemi bloccati a causa di un nuovo modulo caricato.

[modifica] Risorse


Autore: Paolo Pavan

Data: Ottobre 2003

Strumenti personali
Namespace

Varianti