Munin: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
mNessun oggetto della modifica
Riga 1: Riga 1:
==Il superdemone inetd==
=Introduzione=
Munin è un sistema di monitoraggio di sistema avanzato, facilmente installabile e configurabile che offre una vasta gamma di monitor e supporta la raccolta di informazioni da più macchine.<br/>
(Ringrazio Keltik per avermelo involontariamente mostrato).


===Introduzione===
In questa guida vedremo come installarlo, configurandolo per monitorare due macchine: quella su cui è installato il server ed un desktop (in questo caso i dati verranno raccolti solo quando questa macchina sarà accesa).
Inetd ('''Internet Super-Server''') � un demone che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta. Esso controlla tramite dei wrappers i file '''/etc/hosts.allow''' e '''/etc/hosts.deny''' per verificare che la connessione sia consentita.


Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.
=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


Il vantaggio di usarlo � di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.
Per installare il Server (necessario solo sulla macchina che raccoglierà i dati):
<pre>
# apt-get install munin
</pre>


Sebbene possa essere usato per gestire quasi tutti i servizi � consigliabile farlo solo per quelli a basso e occasionale traffico.
Per installare il client (su tutte le macchine che vogliamo monitorare):
<pre>
# apt-get install munin-node
</pre>


===Installazione===
Durante l'installazione non è richiesto l'intervento dell'utente.
Se per qualche motivo il demone inetd non dovrebbe essere installato � sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:
<pre>$: apt-get install netkit-inetd tcpd</pre>


===Configurazine===
Per prima cosa necessario modificare i permessi al file '''/etc/inetd.conf''' in modo che solo root abbia accesso:
<pre>$: chmod 600 /etc/inetd.conf</pre>


Ogni riga di '''/etc/inetd.conf''' corrisponde ad un servizio che viene gestito da inetd. Se � commentata con un # il servizio non viene avviato e inetd non mette la relativa porta in listening. Esempio:
=Configurazione=
==Node==
La configurazione dei Client (o ''nodi'') è estemamente facile 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, ...).


<pre># These are standard services. 
Su ogni ''nodo'' provvediamo a lanciare il configuratore automatico, così da rilevare tutti i servizi/parametri di cui è possibile tenere traccia:
#
<pre>
#ftp    stream  tcp  nowait  root  /usr/sbin/tcpd  in.ftpd -l -a 
# munin-node-configure
#telnet stream  tcp  nowait  root  /usr/sbin/tcpd  in.telnetd
</pre>
#
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:
# Shell, login, exec, comsat and talk are BSD protocols. 
<pre>
# 
# munin-node-configure --debug
#shell  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rshd 
</pre>
#login  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rlogind 
#exec  stream  tcp    nowait  root    /usr/sbin/tcpd  in.rexecd 
#comsat dgram  udp    wait    root    /usr/sbin/tcpd  in.comsat 
#talk  dgram  udp    wait    root    /usr/sbin/tcpd  in.talkd 
#ntalk  dgram  udp    wait    root    /usr/sbin/tcpd  in.ntalkd 
#dtalk  stream  tcp    waut    nobody  /usr/sbin/tcpd  in.dtalkd</pre>


Il formato tipico di ogni riga � il seguente:
al termine della procedura di riconoscimento verrà mostrata una tabella riassuntiva, simile alla seguente:
<pre>
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  |
</pre>


<pre>service type protocol wait user server cmdline</pre>
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:
<pre>
allow ^192\.168\.0\.1$
</pre>
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'':
<pre>
# /etc/init.d/munin-node restart
</pre>


Un esempio pratico di una riga presente in '''/etc/inetd.conf''':
===Moduli===
<pre>ftp stream tcp nowait root /usr/sbin/in.ftpd �l
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.


ftp: nome del servizio
Munin-node altro non è che uno script che si preoccupa di lanciare i vari plug-ins 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:
stream: indica il tipo
<pre>
tcp: indica il protocollo
# ls -l /etc/munin/plugins |more
nowait: indica se deve attendere
totale 0
user: indica l�utente che ha il privilegio di accesso
lrwxrwxrwx  1 root root 28 2005-07-01 01:06 cpu -> /usr/share/munin/plugins/cpu
server: indica dove si trova il programma
lrwxrwxrwx  1 root root 27 2005-07-01 01:06 df -> /usr/share/munin/plugins/df
cmdline:indica il nome dell�eseguibile e eventuali flag</pre>
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
[...]
</pre>
Quindi, per abilitare e/o disabilitare i moduli, è sufficiente creare/cancellare i links simbolici a /usr/share/munin/plugins presenti in /etc/munin/plugins.


Inoltre inetd si appoggia su un altro file di configurazione dei servizi:
Se ad esempio voglio abilitare i moduli relativi ad '''apt''', sarà sufficiente il comando:
<pre>
# ln -s /usr/share/munin/plugins/apt* /etc/munin/plugins
</pre>
e, dopo aver creato i links:
<pre>
/etc/init.d/munin-node restart
</pre>


<pre>/etc/services
Nel caso si voglia testare l'effettivo funzionamento dei un plugin, si può sfruttare il comando <tt>munin-run</tt> che lancia lo script coi permessi effettivi con cui verrà richiamato da munin.
File che assegna un nome di servizio alla relativa porta.
Per esempio, si può testare il corretto funzionamento del plugin <tt>postfix_mailstats</tt> con:
Viene usato anche da altri programmi come file di riferimento.</pre>
<pre>
# munin-run postfix_mailstats
</pre>
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 <tt>/etc/munin/plugin-conf.d/plugins.conf</tt> aggiungendo la seguente riga:
<pre>
[postfix_mailstats]
user root
</pre>
che indica, a munin, di eseguire lo script coi privilegi di root.


Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:
===Apache, un caso particolare===
<pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd �l</pre>
Parliamo un po' più dettagliatamente dei moduli relativi ad Apache: per abilitarli, infatti, non è sufficiente creare i links simbolici, ma abbiamo bisogno anche di metter mano alla configurazione di Apache.


Nelle distribuzioni Linux, solitamente inetd � gi� configurato per supportare i tcp wrappers.
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.


===TCP wrappers===
Ecco come dobbiamo impostare in httpd.conf la sezione di mod_status:
I tcp wrapper '''TCPD''', sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.
<pre>
<IfModule mod_status.c>
  ExtendedStatus On
  <Location /server-status>
      SetHandler server-status
  </Location>
</IfModule>
</pre>
In questo modo munin può interrogare Apache direttamente tramite il protocollo http.


In pratica da una configurazione:
Per verificare che mod_status sia effettivamente in funzione è sufficiente puntare il nostro browser all' indirizzo http://localhost/server-status.


<pre>client -----> inetd -----> servizio</pre>
{{box|Nota sulla sicurezza|E' 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 al' interno dei tags <location> e </location>, subito al di sotto di "SetHandler server-status" queste istruzioni:
<pre>
Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1
</pre>}}
Riavviamo apache:
<pre>
# apachectl graceful
</pre>
e munin-node:
<pre>
# /etc/init-d/munin-node restart
</pre>


Si passa ad una configurazione:
==Server==
La configurazione di defalut 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''.


<pre>client -----> inetd -----> TCPD -----> servizio</pre>
===Aggiunta di Client===
La configurazione del server è gestita tramite un file: '''/etc/munin/munin.conf'''.


Nella nuova configurazione i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalit� anti-spoofing e anti tcp seguence guessing. La configurazione dei tcp wrappers si fa essenzialmente in due file.
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:
<pre>
[nome_del_nodo]
    address <indirizzo_del_nodo>
    use_node_name <yes|no>
</pre>


Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP:
I parametri e le opzioni descritte hanno il seguente significato:
<pre>/etc/hosts.allow</pre>
; 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''.


Questo file permette di specificare come limitare l'accesso a specifici servizi:
Riporto un esempio di configurazione per il monitoraggio di due macchine:
<pre>/etc/hosts.deny</pre>
<pre>
[spirit.knio.it]
    address 127.0.0.1
    use_node_name yes


===Comandi utili===
[maxer.knio.it]
Per avviare, riavviare, fermare il servizio inetd:
    address 192.168.0.2
<pre>$: /etc/rc.d/init.d/inetd start/stop/restart</pre>
    use_node_name yes
</pre>


===Configurazioni utili===
I dati contenuti in '''/var/www/munin''' sono aggionati tramite il cron '''/etc/cron.d/munin''', esattamente ogni 5 minuti.
Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>File da applicare: /etc/hosts.deny
ALL:ALL@ALL,PARANOID</pre>


Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>File da applicare: /etc/hosts.allow
ALL: LOCAL 192.168.1.0/255.255.255.0</pre>


Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1
==Conclusioni==
<pre>File da applicare: /etc/hosts.allow
Munin, come visto, è uno strumento veramente utile, sia per la sua facilità di installazione, sia per il vasto numero di dati che è capace di monitorare. Le sue funzionalità, inoltre, sono ampliabili tramite plugin, così da poter adattare al meglio il servizio alle proprie esigenze.
sshd: 10.0.0.1 prova.it</pre>


Manda una mail all'indirizzo specificato admin_mail ogni qualvolta qualcuno si connette attraverso il servizio telnet, indicando l'indirizzo del client (%a) e l'utente (%u), la lista di questi parametri � contenuta nella man page hosts_access.
==Bookmark==
<pre>File da applicare: /etc/hosts.allow
[http://www.linpro.no/projects/munin/ Home Page del progetto]
in.telnetd : ALL@ALL : spawn ( /bin/mail -s "Connessione telnet da: %a %u" admin_mail ) & </pre>
[[Categoria:Server]][[Categoria:Networking]][[Categoria:Sicurezza]]
 
==Da inetd a Xinetd==
===Differenze===
A differenza del precedessore, xinetd (e'''x'''tended inetd):
 
:*Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
:*Offre un sistema di logging indipendente da syslog;
:*Permette di limitare l'accesso ai servizi in determinate ore della giornata;
:*Supporta il protocollo Ipv6;
:*Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.
 
===File di configurazione===
La configurazione del demone e dei servizi pu� essere suddivisa in pi� file non compatibili con i vecchi file di configurazione del demone inetd. Le directory contenenti i file di configurazione sono leggermente cambiate:
<pre>/etc/xinetd.conf
File di configurazione del demone
 
/etc/xinetd.d/*
Directory che contiene i singoli file dei servizi offerti da xinetd</pre>
 
Il file di configurazione di xinetd � un file di testo che indica i servizi gestiti da xinetd. Contiene delle sezioni, ognuna delle quali identifica un servizio, con la seguente sintassi:
<pre>service service_name
{
    attribute assign_op [value] [value] [...]
    [...]
}</pre>
 
Dove i seguenti attributi indicano:
:* '''service_name'''  � l�indicazione di un servizio gestito da xinetd;
:* '''attribute'''  indica un attributo relativo al servizio service_name;
:* '''assign_op'''  � un operatore di assegnamento, e pu� essere = (specifica l�unico valore dell�attributo), += (aggiunge un valore all�attributo) o -= (rimuove un valore dall�attributo).
 
===Esempi di configurazione di Xinetd===
Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione '''/etc/xinetd.conf''':
<pre>service shell
          {
                socket_type        = stream
                wait                = no
                user                = root
                instances          = UNLIMITED
                server              = /usr/etc/in.rshd
                log_on_success      += HOST RECORD
          }
 
service ftp                                                             
          {
                socket_type        = stream
                wait                = no
                nice                = 10
                user                = root
                server              = /usr/etc/in.ftpd
                server_args        = -l
                instances          = 4
                log_on_success      += DURATION HOST USERID
                access_times        = 2:00-9:00 12:00-24:00
          }</pre>
 
Per una guida dettagliata di ogni singolo parametro � possibile consultare il '''man''' una volta installato xinetd. Xinetd � un demone molto flessibile e tramite il suo file di configurazione � possibile specificare decine e decine di opzioni.
 
===Opzioni di Xinetd===
Le opzioni che possono essere utilizzate per la modalit� di funzionamento di xinetd sono le seguenti:
:* '''-d''' abilita la modalit� di debug;
:* '''-syslog syslog_facility''' imposta la facility relativa al system log44 secondo quanto specificato da syslog_facility;
:* '''-filelog logfile'''' indica di redirigere il log degli eventi di xinetd nel file logfile;
:* '''-f config_file''' indica il file di configurazione da considerare secondo quanto specificato da config_file (default /etc/xinetd.conf);
:* '''-pidfile pid_file''' indica di scrivere nel file pid_file il PID del processo lanciato;
:* '''-stayalive''' indica di rimanere in esecuzione anche se nel file di configurazione non � stato specificato nessun servizio;
:* '''-limit proc_limit''' imposta il numero massimo di processi che xinetd pu� lanciare secondo quanto specificato da proc_limit;
:* '''-logprocs limit''' imposta il numero massimo di daemon che possono essere lanciati in esecuzione per ogni utente, secondo quanto specificato da limit;
:* '''-version''' visualizza la versione di xinetd;
:* '''-inetd_compat''' indica di considerare anche il file di configurazione '''/etc/inetd.conf''' subito dopo '''/etc/xinetd.conf''';
:* '''-cc interval''' indica di controllare un controllo periodico del proprio stato ogni interval secondi;
 
Il processo xinetd effettua le operazioni elencate in corrsipondenza dei seguenti segnali:
 
:*'''SIGHUP''' rilegge il file di configurazione e termina l�esecuzione dei daemon relativi a servizi non pi� attivi (secondo quanto specificato nel file di configurazione);
:* '''SIGQUIT''' termina la sua esecuzione;
:* '''SIGTERM''' termina l�esecuzione di tutti i daemon prima di terminare anche la sua esecuzione;
:* '''SIGUSR1''' scrive il suo stato interno (dump) nel file '''/var/run/xinetd.dump''';
:* '''SIGIOT''' controlla la consistenza delle sue strutture dati, visualizzando quindi un messaggio relativo.
 
Autore: [[Utente:Net deity|Net deity]]
[[Categoria:Server]][[Categoria:Networking]]

Versione delle 09:29, 3 giu 2009

Introduzione

Munin è un sistema di monitoraggio di sistema avanzato, facilmente installabile e configurabile che offre una vasta gamma di monitor e supporta la raccolta di informazioni da più macchine.
(Ringrazio Keltik per avermelo involontariamente mostrato).

In questa guida vedremo come installarlo, configurandolo per monitorare due macchine: quella su cui è installato il server ed un desktop (in questo caso i dati verranno raccolti solo quando questa macchina sarà accesa).

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) è estemamente facile 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, ...).

Su ogni nodo provvediamo a lanciare il configuratore 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-ins 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 links 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 links: 

/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 links 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.

Info.png Nota sulla sicurezza
E' 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 al' interno dei tags <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 defalut 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 aggionati tramite il cron /etc/cron.d/munin, esattamente ogni 5 minuti.


Conclusioni

Munin, come visto, è uno strumento veramente utile, sia per la sua facilità di installazione, sia per il vasto numero di dati che è capace di monitorare. Le sue funzionalità, inoltre, sono ampliabili tramite plugin, così da poter adattare al meglio il servizio alle proprie esigenze.

Bookmark

Home Page del progetto

Estratto da "https://guide.debianizzati.org/index.php?title=Munin&oldid=16486"