Analizzare il carico dei processi con Munin
|
|
|
Alcuni plugin permettono di creare un grafico specifico per un determinato processo ma nessuno lo fa in maniera aggregata per tutti i processi contemporaneamente.
Così, vista la semplicità con cui è possibile scrivere un plugin munin, ho deciso di crearne uno che facesse al caso mio.
Questo è il risultato che ho ottenuto con poco sforzo:
Uso della CPU per processo.
Oltre al carico di CPU ho deciso di monitorare anche i minor-faults e i major-faults. I minor faults avvengono ogni qual volta un processo cerca di scrivere in una pagina di memoria protetta da scrittura, mentre i major faults avvengono quando questa operazione richiede anche una o più operazioni di I/O (e.g: swap).
L’analisi dei minor/major faults può essere utile durante l’indagine di un problema di performance di un sistema.
Questo, ad esempio, è il grafico dei minor-faults corrispondente al precendete grafico di carico CPU per la stessa macchina:
Errori di pagina "minori" per processor
I plugin, da copiare nella cartella /etc/munin/plugins sono questi:
- processes_cpu
- processes_minorfaults
processes_majorfaults
Dopo aver copiato i plugin, è necessario riavviare il munin-node:
sh# service munin-node restart
Possibili migliorie
Purtroppo i colori devo necessariamente lasciarli gestire a munin automaticamente.
Non ho idea di come si potrebbe fare a mettere in legenda solo quei processi che hanno usato almeno un 1% della CPU o funzionalità del genere.
Se lo stesso plugin viene installato in più macchine i processi vengono colorati diversamente per ogni macchina, rendendo di fatto poco intuitivo il confronto. Forse decidere il colore in base ad un hash calcolato dal nome del processo permettere stabilità ma potrebbe capitare che i processi più importanti abbiano poi un colore identico e siano indistinguibili.
Installazione.
Il programma è composto da:
munin-node
il Client, che gestisce la raccolta di informazioni su una determinata macchina;
munin
il Server, che si occupa di elaborare i dati, catalogarli, creare i grafici e le pagine HTML.
Per installare il Server (necessario solo sulla macchina che raccoglierà i dati):
# apt-get install munin
Per installare il client (su tutte le macchine che vogliamo monitorare):
# apt-get install munin-node
Durante l'installazione non è richiesto l'intervento dell'utente.
Configurazione.
Node
La configurazione dei Client (o nodi) è estremamente semplice ed automatizzata: è presente un comando che controlla la macchina alla ricerca di servizi monitorabili attraverso delle regole predefinite. È d'obbligo evidenziare il numero di monitor presenti, che spaziano dalla statistiche di sistema base (CPU, Memoria, Swap) fino a quelle dei servizi (MySql, Postfix, NFS, Apache, ecc).
Su ogni nodo provvediamo a lanciare lo strumento di configurazione automatico, così da rilevare tutti i servizi/parametri di cui è possibile tenere traccia:
# munin-node-configure
il processo può impiegare un bel po' di tempo (soprattutto se la macchina è lenta); per controllare l'avanzamento del processo, consiglio di abilitare il debug:
# munin-node-configure --debug
al termine della procedura di riconoscimento verrà mostrata una tabella riassuntiva, simile alla seguente:
Plugin | Used | Extra information
------ | ---- | -----------------
acpi | no |
apache_accesses | no |
apache_processes | no |
apache_volume | no |
apt | no |
apt_all | no |
courier_mta_mailqueue | no |
courier_mta_mailstats | no |
courier_mta_mailvolume | no |
cps_ | no |
cpu | yes |
cupsys_pages | yes |
df | yes |
df_abs | no |
df_inode | yes |
entropy | yes |
exim_mailqueue | no |
exim_mailstats | no |
forks | yes |
fw_conntrack | no |
fw_forwarded_local | no |
fw_packets | no |
hddtemp_smartctl | yes |
if_ | yes | eth0
if_err_ | yes | eth0
interrupts | yes |
iostat | yes |
ip_ | no |
ircu | no |
irqstats | yes |
load | yes |
loggrep | no |
memory | yes |
multips | no |
munin_graph | no |
munin_update | no |
mysql_bytes | yes |
mysql_isam_space_ | no |
mysql_queries | yes |
mysql_slowqueries | yes |
mysql_threads | yes |
netstat | yes |
nfs_client | yes |
nfsd | yes |
ntp_ | yes | mathfox_xs4all_nl
ntp_states | no |
open_files | yes |
open_inodes | yes |
ping_ | no |
port_ | no |
postfix_mailqueue | yes |
postfix_mailstats | no |
postfix_mailvolume | no |
processes | yes |
ps_ | no |
psu_ | no |
sendmail_mailqueue | no |
sendmail_mailstats | no |
sendmail_mailtraffic | no |
sensors_ | no |
smart_ | yes | hda
squid_cache | no |
squid_icp | no |
squid_requests | no |
squid_traffic | no |
swap | yes |
sybase_space | no |
uptime | no |
vlan_ | no |
vlan_inetuse_ | no |
vlan_linkuse_ | no |
vmstat | yes |
Per le macchine diverse da quella che ospita il server, bisogna modificare le impostazioni di accesso per consentire le connessioni da parte di quest'ultimo. Per fare questo apriamo con un editor il file /etc/munin/munin-node.conf, ed aggiungiamo la seguente riga alla fine del file:
allow ^192.168.0.1$
Il commento poco sopra il punto in cui abbiamo inserito questa stringa ci ricorda che si tratta di espressioni regolari, di conseguenza è necessario anteporre un backslash prima dei punti.
Per applicare le modifica apportate, riavviamo munin-node:
# /etc/init.d/munin-node restart
Moduli.
Munin sfrutta un'architettura a plug-in per monitorare le varie componenti di sistema. Come abbiamo visto nel paragrafo precedente (vedi l'output di munin-node-configure) ce ne sono a disposizione moltissimi.
Munin-node altro non è che uno script che si preoccupa di lanciare i vari plug-in presenti all'interno della cartella /etc/munin/plugins. Notiamo subito che all'interno di questa directory non troviamo i veri e propri moduli, ma del link simbolici ad essi:
# ls -l /etc/munin/plugins |more
totale 0
lrwxrwxrwx 1 root root 28 2005-07-01 01:06 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx 1 root root 27 2005-07-01 01:06 df -> /usr/share/munin/plugins/df
lrwxrwxrwx 1 root root 33 2005-07-01 01:06 df_inode -> /usr/share/munin/plugins/df_inode
lrwxrwxrwx 1 root root 32 2005-07-01 01:06 entropy -> /usr/share/munin/plugins/entropy
[...]
Quindi, per abilitare e/o disabilitare i moduli, è sufficiente creare/cancellare i link simbolici a /usr/share/munin/plugins presenti in /etc/munin/plugins.
Se ad esempio voglio abilitare i moduli relativi ad apt, sarà sufficiente il comando:
# ln -s /usr/share/munin/plugins/apt* /etc/munin/plugins
e, dopo aver creato i link:
/etc/init.d/munin-node restart
Nel caso si voglia testare l'effettivo funzionamento dei un plugin, si può sfruttare il comando munin-run che lancia lo script coi permessi effettivi con cui verrà richiamato da munin. Per esempio, si può testare il corretto funzionamento del plugin postfix_mailstats con:
# munin-run postfix_mailstats
Il comando, in questo caso, potrebbe dare errore (o restituire un valore pari a U) per via dei permessi insufficienti: è necessario essere root per poter accedere allo spool di posta e 'contare' i messaggi presenti. Per ovviare a questo problema è sufficiente modificare il file /etc/munin/plugin-conf.d/plugins.conf aggiungendo la seguente riga:
[postfix_mailstats]
user root
che indica, a munin, di eseguire lo script coi privilegi di root.
Apache, un caso particolare.
Parliamo un po' più dettagliatamente dei moduli relativi ad Apache: per abilitarli, infatti, non è sufficiente creare i link simbolici, ma abbiamo bisogno anche di metter mano alla configurazione di Apache.
Per monitorare Apache, Munin ha bisogno che mod_status venga caricato da httpd con la direttiva ExtendedStatus On. In Debian mod_status per Apache viene caricato di default, per cui dobbiamo solo preoccuparci di fare un piccolo aggiustamento alla sezione che lo riguarda.
Ecco come dobbiamo impostare in httpd.conf la sezione di mod_status:
<IfModule mod_status.c>
ExtendedStatus On
<Location /server-status>
SetHandler server-status
</Location>
</IfModule>
In questo modo munin può interrogare Apache direttamente tramite il protocollo HTTP.
Per verificare che mod_status sia effettivamente in funzione è sufficiente puntare il nostro browser all'indirizzo http://localhost/server-status.
Nota sulla sicurezza
È bene aggiungere alcune istruzioni relative alla sicurezza nella nostra configurazione di mod_status, in modo da renderlo accessibile unicamente attraverso il nostro indirizzo IP locale (127.0.0.1). per fare questo possiamo inserire all'interno dei tag <location> e </location>, subito al di sotto di SetHandler server-status queste istruzioni:
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Riavviamo Apache:
# apachectl graceful
e munin-node:
# /etc/init-d/munin-node restart
Server.
La configurazione di default del server è più che sufficiente per un utilizzo normale di questo. Utilizza la directory /var/www/munin/, in cui inserisce tutte le pagine relative ai computer da monitorare. Questa directory, quindi, dovrà essere accessibile in scrittura dall'utente munin, ed in lettura dall'utente www-data (supponendo l'utilizzo di apache come webserver per visualizzare le statistiche). In particolare controlliamo che la directory /var/www abbia i permessi di esecuzione per l'utente nobody.
Aggiunta di Client.
La configurazione del server è gestita tramite un file: /etc/munin/munin.conf.
La sezione che a noi interessa è l'ultima, dove vengono raccolti i dati dei nodi da monitorare. Ogni blocco rappresentate un nodo, nel file di configurazione, ha la seguente struttura:
[nome_del_nodo]
address <indirizzo_del_nodo>
use_node_name <yes|no>
I parametri e le opzioni descritte hanno il seguente significato:
nome_del_modulo
indica il nome con cui verrà rappresentato il nodo (solo se use_node_name è yes). Munin raccoglie i nodi per domini di secondo livello, in una struttura ad albero.
address <indirizzo_del_nodo>
indica l'indirizzo (IP o URL) tramite il quale raggiungere il nodo.
Riporto un esempio di configurazione per il monitoraggio di due macchine:
[spirit.knio.it]
address 127.0.0.1
use_node_name yes
[maxer.knio.it]
address 192.168.0.2
use_node_name yes
I dati contenuti in /var/www/munin sono aggiornati tramite il cron /etc/cron.d/munin, esattamente ogni 5 minuti.
I plugin, da copiare nella cartella /etc/munin/plugins sono questi:
- processes_cpu
- processes_minorfaults
processes_majorfaults
Dopo aver copiato i plugin, è necessario riavviare il munin-node:
sh# service munin-node restart
Possibili migliorie
Purtroppo i colori devo necessariamente lasciarli gestire a munin automaticamente.
Non ho idea di come si potrebbe fare a mettere in legenda solo quei processi che hanno usato almeno un 1% della CPU o funzionalità del genere.
Se lo stesso plugin viene installato in più macchine i processi vengono colorati diversamente per ogni macchina, rendendo di fatto poco intuitivo il confronto. Forse decidere il colore in base ad un hash calcolato dal nome del processo permettere stabilità ma potrebbe capitare che i processi più importanti abbiano poi un colore identico e siano indistinguibili.
Installazione.
Il programma è composto da:
munin-node
il Client, che gestisce la raccolta di informazioni su una determinata macchina;
munin
il Server, che si occupa di elaborare i dati, catalogarli, creare i grafici e le pagine HTML.
Per installare il Server (necessario solo sulla macchina che raccoglierà i dati):
# apt-get install munin
Per installare il client (su tutte le macchine che vogliamo monitorare):
# apt-get install munin-node
Durante l'installazione non è richiesto l'intervento dell'utente.
Configurazione.
Node
La configurazione dei Client (o nodi) è estremamente semplice ed automatizzata: è presente un comando che controlla la macchina alla ricerca di servizi monitorabili attraverso delle regole predefinite. È d'obbligo evidenziare il numero di monitor presenti, che spaziano dalla statistiche di sistema base (CPU, Memoria, Swap) fino a quelle dei servizi (MySql, Postfix, NFS, Apache, ecc).
Su ogni nodo provvediamo a lanciare lo strumento di configurazione automatico, così da rilevare tutti i servizi/parametri di cui è possibile tenere traccia:
# munin-node-configure
il processo può impiegare un bel po' di tempo (soprattutto se la macchina è lenta); per controllare l'avanzamento del processo, consiglio di abilitare il debug:
# munin-node-configure --debug
al termine della procedura di riconoscimento verrà mostrata una tabella riassuntiva, simile alla seguente:
Plugin | Used | Extra information
------ | ---- | -----------------
acpi | no |
apache_accesses | no |
apache_processes | no |
apache_volume | no |
apt | no |
apt_all | no |
courier_mta_mailqueue | no |
courier_mta_mailstats | no |
courier_mta_mailvolume | no |
cps_ | no |
cpu | yes |
cupsys_pages | yes |
df | yes |
df_abs | no |
df_inode | yes |
entropy | yes |
exim_mailqueue | no |
exim_mailstats | no |
forks | yes |
fw_conntrack | no |
fw_forwarded_local | no |
fw_packets | no |
hddtemp_smartctl | yes |
if_ | yes | eth0
if_err_ | yes | eth0
interrupts | yes |
iostat | yes |
ip_ | no |
ircu | no |
irqstats | yes |
load | yes |
loggrep | no |
memory | yes |
multips | no |
munin_graph | no |
munin_update | no |
mysql_bytes | yes |
mysql_isam_space_ | no |
mysql_queries | yes |
mysql_slowqueries | yes |
mysql_threads | yes |
netstat | yes |
nfs_client | yes |
nfsd | yes |
ntp_ | yes | mathfox_xs4all_nl
ntp_states | no |
open_files | yes |
open_inodes | yes |
ping_ | no |
port_ | no |
postfix_mailqueue | yes |
postfix_mailstats | no |
postfix_mailvolume | no |
processes | yes |
ps_ | no |
psu_ | no |
sendmail_mailqueue | no |
sendmail_mailstats | no |
sendmail_mailtraffic | no |
sensors_ | no |
smart_ | yes | hda
squid_cache | no |
squid_icp | no |
squid_requests | no |
squid_traffic | no |
swap | yes |
sybase_space | no |
uptime | no |
vlan_ | no |
vlan_inetuse_ | no |
vlan_linkuse_ | no |
vmstat | yes |
Per le macchine diverse da quella che ospita il server, bisogna modificare le impostazioni di accesso per consentire le connessioni da parte di quest'ultimo. Per fare questo apriamo con un editor il file /etc/munin/munin-node.conf, ed aggiungiamo la seguente riga alla fine del file:
allow ^192.168.0.1$
Il commento poco sopra il punto in cui abbiamo inserito questa stringa ci ricorda che si tratta di espressioni regolari, di conseguenza è necessario anteporre un backslash prima dei punti.
Per applicare le modifica apportate, riavviamo munin-node:
# /etc/init.d/munin-node restart
Moduli.
Munin sfrutta un'architettura a plug-in per monitorare le varie componenti di sistema. Come abbiamo visto nel paragrafo precedente (vedi l'output di munin-node-configure) ce ne sono a disposizione moltissimi.
Munin-node altro non è che uno script che si preoccupa di lanciare i vari plug-in presenti all'interno della cartella /etc/munin/plugins. Notiamo subito che all'interno di questa directory non troviamo i veri e propri moduli, ma del link simbolici ad essi:
# ls -l /etc/munin/plugins |more
totale 0
lrwxrwxrwx 1 root root 28 2005-07-01 01:06 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx 1 root root 27 2005-07-01 01:06 df -> /usr/share/munin/plugins/df
lrwxrwxrwx 1 root root 33 2005-07-01 01:06 df_inode -> /usr/share/munin/plugins/df_inode
lrwxrwxrwx 1 root root 32 2005-07-01 01:06 entropy -> /usr/share/munin/plugins/entropy
[...]
Quindi, per abilitare e/o disabilitare i moduli, è sufficiente creare/cancellare i link simbolici a /usr/share/munin/plugins presenti in /etc/munin/plugins.
Se ad esempio voglio abilitare i moduli relativi ad apt, sarà sufficiente il comando:
# ln -s /usr/share/munin/plugins/apt* /etc/munin/plugins
e, dopo aver creato i link:
/etc/init.d/munin-node restart
Nel caso si voglia testare l'effettivo funzionamento dei un plugin, si può sfruttare il comando munin-run che lancia lo script coi permessi effettivi con cui verrà richiamato da munin. Per esempio, si può testare il corretto funzionamento del plugin postfix_mailstats con:
# munin-run postfix_mailstats
Il comando, in questo caso, potrebbe dare errore (o restituire un valore pari a U) per via dei permessi insufficienti: è necessario essere root per poter accedere allo spool di posta e 'contare' i messaggi presenti. Per ovviare a questo problema è sufficiente modificare il file /etc/munin/plugin-conf.d/plugins.conf aggiungendo la seguente riga:
[postfix_mailstats]
user root
che indica, a munin, di eseguire lo script coi privilegi di root.
Apache, un caso particolare.
Parliamo un po' più dettagliatamente dei moduli relativi ad Apache: per abilitarli, infatti, non è sufficiente creare i link simbolici, ma abbiamo bisogno anche di metter mano alla configurazione di Apache.
Per monitorare Apache, Munin ha bisogno che mod_status venga caricato da httpd con la direttiva ExtendedStatus On. In Debian mod_status per Apache viene caricato di default, per cui dobbiamo solo preoccuparci di fare un piccolo aggiustamento alla sezione che lo riguarda.
Ecco come dobbiamo impostare in httpd.conf la sezione di mod_status:
<IfModule mod_status.c>
ExtendedStatus On
<Location /server-status>
SetHandler server-status
</Location>
</IfModule>
In questo modo munin può interrogare Apache direttamente tramite il protocollo HTTP.
Per verificare che mod_status sia effettivamente in funzione è sufficiente puntare il nostro browser all'indirizzo http://localhost/server-status.
Nota sulla sicurezza
È bene aggiungere alcune istruzioni relative alla sicurezza nella nostra configurazione di mod_status, in modo da renderlo accessibile unicamente attraverso il nostro indirizzo IP locale (127.0.0.1). per fare questo possiamo inserire all'interno dei tag <location> e </location>, subito al di sotto di SetHandler server-status queste istruzioni:
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Riavviamo Apache:
# apachectl graceful
e munin-node:
# /etc/init-d/munin-node restart
Server.
La configurazione di default del server è più che sufficiente per un utilizzo normale di questo. Utilizza la directory /var/www/munin/, in cui inserisce tutte le pagine relative ai computer da monitorare. Questa directory, quindi, dovrà essere accessibile in scrittura dall'utente munin, ed in lettura dall'utente www-data (supponendo l'utilizzo di apache come webserver per visualizzare le statistiche). In particolare controlliamo che la directory /var/www abbia i permessi di esecuzione per l'utente nobody.
Aggiunta di Client.
La configurazione del server è gestita tramite un file: /etc/munin/munin.conf.
La sezione che a noi interessa è l'ultima, dove vengono raccolti i dati dei nodi da monitorare. Ogni blocco rappresentate un nodo, nel file di configurazione, ha la seguente struttura:
[nome_del_nodo]
address <indirizzo_del_nodo>
use_node_name <yes|no>
I parametri e le opzioni descritte hanno il seguente significato:
nome_del_modulo
indica il nome con cui verrà rappresentato il nodo (solo se use_node_name è yes). Munin raccoglie i nodi per domini di secondo livello, in una struttura ad albero.
address <indirizzo_del_nodo>
indica l'indirizzo (IP o URL) tramite il quale raggiungere il nodo.
Riporto un esempio di configurazione per il monitoraggio di due macchine:
[spirit.knio.it]
address 127.0.0.1
use_node_name yes
[maxer.knio.it]
address 192.168.0.2
use_node_name yes
I dati contenuti in /var/www/munin sono aggiornati tramite il cron /etc/cron.d/munin, esattamente ogni 5 minuti.