12.4. Monitoraggio

Monitoraggio è un termine generico, e le diverse attività implicate hanno diversi scopi: da una parte, seguire l'uso delle risorse fornite da una macchina permette di prevedere la saturazione e i conseguenti aggiornamenti richiesti; dall'altra, avvisare l'amministratore appena un servizio è indisponibile o non funziona correttamente significa che il problema può essere risolto più celermente.

Munin copre la prima area, visualizzando diagrammi grafici per i valori storici di un certo numero di parametri (RAM usata, spazio disco occupato, carico del processore, traffico di rete, carico di Apache/MySQL e così via). Nagios copre la seconda area, controllando regolarmente che i servizi siano funzionanti e disponibili e inviando avvisi tramite i canali appropriati (email, messaggi di testo e così via). Entrambi hanno una struttura modulare, il che rende facile creare nuovi plugin per monitorare specifici parametri o servizi.

ALTERNATIVA Zabbix, uno strumento integrato di monitoraggio

Sebbene Munin e Nagios siano comunemente molto usati, non sono gli unici attori nel campo del monitoraggio, e ciascuno di loro gestisce solo metà del compito (creare grafici da un lato, avvisare dall'altro). Zabbix, d'altra parte, integra entrambe le parti del monitoraggio; ha anche un'interfaccia web per configurare gli aspetti più comuni. Negli ultimi anni ha fatto grandi passi in avanti e si può ora considerare un concorrente all'altezza. Sul server di monitoraggio, si dovrebbe installarezabbix-server-pgsql (o zabbix-server-mysql), eventualmente insieme ad zabbix-frontend-php per avere un'interfaccia web. Sugli host da controllare si dovrebbe installare zabbix-agent per inviare i dati al server.

→ https://zabbix.com/

12.4.1. Impostazione di Munin

Lo scopo di Munin è di monitorare molte macchine; è quindi assai naturale che usi un'architettura client/server. L'host centrale, il graficatore, raccoglie dati da tutti gli host monitorari e genera grafici storici.

12.4.1.1. Configurare gli host da monitorare

Il primo passo è installare il pacchetto munin-node. Il demone installato da questo pacchetto ascolta sulla porta 4949 e rimanda i dati raccolti da tutti i plugin attivi. Ciascun plugin è un semplice programma che restituisce una descrizione dei dati raccolti insieme all'ultimo valore misurato. I plugin sono memorizzati in /usr/share/munin/plugins/, ma solo quelli con un collegamento simbolico in /etc/munin/plugins/ vengono effettivamente usati.

Quando il pacchetto è installato, un insieme di plugin attivi è determinato in base al software disponibile e alla configurazione attuale dell'host. Tuttavia, questa autoconfigurazione dipende da una funzionalità che ogni plugin deve fornire ed è normalmente una buona idea rivedere e adattare i risultati manualmente. Sfogliare la galleria dei plugin può essere interessante anche se non tutti i plugin sono correlati con documentazione completa.

→ https://gallery.munin-monitoring.org

Tuttavia, tutti i plugin sono script e la maggior parte di essi sono piuttosto semplici e ben commentati. Sfogliare /etc/munin/plugins/ è perciò un buon modo per avere un'idea di cosa si occupa ciascun plugin e determinare quali debbano essere rimossi. Allo stesso modo, abilitare un plugin interessante trovato in /usr/share/munin/plugins/ si riduce a impostare un collegamento simbolico con ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Notare che quando il nome di un plugin termina con una sottolineatura "_", il plugin richiede un parametro che deve essere memorizzato nel nome del collegamento simbolico; per esempio, il plugin "if_" deve essere abilitato con un collegamento simbolico if_eth0, e monitorerà il traffico di rete sull'interfaccia eth0.

Una volta impostati correttamente tutti i plugin, si deve aggiornare la configurazione del demone per descrivere il controllo dell'accesso ai dati raccolti. Questo richiede delle direttive allow nel file /etc/munin/munin-node.conf. La configurazione predefinita è allow ^127\.0\.0\.1$ e permette accesso solo all'host locale. Un amministratore di solito aggiungerà una riga simile contenente l'indirizzo IP dell'host graficatore, quindi riavvierà il demone con systemctl restart munin-node.

APPROFONDIMENTO Creare plugin locali

Munin include una dettagliata documentazione su come i plugin dovrebbero comportarsi, e come sviluppare nuovi plugin.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Un plugin si collauda meglio quando viene avviato nelle stesse condizioni in cui si troverebbe se fosse attivato da munin-node; ciò si può simulare lanciando munin-run plugin da root. Un potenziale secondo parametro (come config) viene passato al plugin come parametro.

Quando un plugin è invocato con il parametro config, deve descriversi restituendo un insieme di campi:

# munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

I diversi campi disponibili sono descritti dal “Plugin reference” disponibile come parte della “guida Munin”.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Quando viene invocato senza un parametro, il plugin restituisce semplicemente gli ultimi valori misurati; per esempio, l'esecuzione di sudo munin-run load può restituire load.value 0.12.

Infine, quando un plugin viene invocato con il parametro autoconf, deve restituire "yes" (e uno stato di uscita 0) o "no" (con uno stato di uscita 1) a seconda se il plugin deve essere abilitato o meno sull'host.

12.4.1.2. Configurare il graficatore

Il "grapher" è semplicemente il computer che aggrega i dati e genera i grafici corrispondenti. Il software richiesto si trova nel pacchetto munin. La configurazione standard esegue munin-cron (una volta ogni 5 minuti), che raccoglie i dati da tutti gli host elencati in /etc/munin/munin.conf (solo l'host locale è elencato in modo predefinito), salva i dati storici in file RRD (Round Robin Database, un formato di file progettato per memorizzare dati variabili nel tempo) memorizzati sotto /var/lib/munin/ e genera una pagina HTML con i grafici in /var/cache/munin/www/.

Tutte le macchine monitorate devono quindi essere elencate nel file di configurazione /etc/munin/munin.conf. Ciascuna macchina è elencata come una sezione completa con un nome che corrisponde alla macchina e almeno una voce address che dà il corrispondente indirizzo IP.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Le sezioni possono essere più complesse e descrivere ulteriori grafici che possono essere creati combinando dati provenienti da diverse macchine. Gli esempi forniti nel file di configurazione sono dei buoni punti di partenza per la personalizzazione.

L'ultimo passo è pubblicare le pagine generate; questo richiede di configurare un server web in modo che i contenuti di /var/cache/munin/www/ siano resi disponibili su un sito web. L'accesso a questo sito web sarà spesso ristretto, usando un meccanismo di autenticazione o un controllo di accesso basato sull'IP. Vedere Sezione 11.2, «Server web (HTTP)» per i dettagli relativi.

12.4.2. Impostazione di Nagios

Contrariamente a Munin, Nagios non richiede necessariamente di installare alcunché sugli host monitorati; la maggior parte delle volte, Nagios viene usato per controllare la disponibilità dei servizi di rete. Per esempio, Nagios può connettersi a un sito web e controllare che una data pagina web possa essere ottenuta entro un certo tempo.

12.4.2.1. Installazione

Il primo passo per configurare Nagios è di installare i pacchetti nagios4 e monitoring-plugins. Installando i pacchetti, configurando l'interfaccia web e il server Apache. I moduli Apache authz_groupfile e auth_digest devono essere abilitati, per fare questo eseguire:

# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
  systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
  systemctl restart apache2
# systemctl restart apache2

Per aggiungere nuovi utenti è sufficiente inserirli nel file /etc/nagios4/hdigest.users.

Visitando http://server/nagios4/ con un navigatore viene visualizzata l'interfaccia web; in particolare, notare che Nagios monitora già alcuni parametri della macchina su cui gira. Tuttavia, alcune funzionalità interattive come l'aggiunta di commenti per un host non funzionano. Queste funzionalità sono disabilitate nella configurazione predefinita di Nagios, che è molto restrittiva, per ragioni di sicurezza.

L'abilitazione di alcune funzionalità richiede la modifica di /etc/nagios3/nagios.cfg. Bisogna anche impostare i permessi in scrittura per la directory usata da Nagios, con comandi come i seguenti:

# systemctl stop nagios4
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

12.4.2.2. Configurazione

L'interfaccia web di Nagios è abbastanza carina, ma non permette la configurazione né può essere usata per aggiungere host e servizi da monitorare. L'intera configurazione viene gestita tramite file indicati nel file di configurazione centrale, /etc/nagios4/nagios.cfg.

Questi file non dovrebbero essere studiati senza una qualche comprensione dei concetti alla base di Nagios. La configurazione elenca oggetti dei seguenti tipi:

un host è una macchina da monitorare;
un hostgroup è un insieme di host che dovrebbero essere raggruppati insieme per la visualizzazione o per sfruttare elementi comuni di configurazione;
un service è un elemento controllabile relativo a un host o a un gruppo di host. Molto spesso sarà un controllo di un servizio di rete, ma può anche richiedere di controllare che certi parametri siano all'interno di un intervallo accettabile (per esempio, lo spazio libero sul disco o il carico del processore);
un servicegroup è un insieme di servizi che dovrebbero essere raggruppati insieme per la visualizzazione;
un contact è una persona che può ricevere avvisi;
un contactgroup è un insieme di tali contatti;
un timeperiod è un intervallo di tempo durante il quale alcuni servizi devono essere controllati;
un command è la riga di comando invocata per controllare un dato servizio.

Secondo il suo tipo, ciascun oggetto ha un certo numero di proprietà che possono essere personalizzate. Una lista completa sarebbe troppo lunga da includere, ma le proprietà più importanti sono le relazioni fra gli oggetti.

Un service usa un command per controllare lo stato di una funzionalità su un host (o un hostgroup) entro un timeperiod. In caso di problema, Nagios manda un avviso a tutti i membri del contactgroup collegato al servizio. Ciascun membro riceve l'avviso a seconda del canale descritto nell'oggetto contact corrispondente.

Un sistema di ereditarietà permette di condividere facilmente un insieme di proprietà fra molti oggetti senza duplicare informazioni. Inoltre, la configurazione iniziale include un certo numero di oggetti standard; in molti casi, definire nuovi host, servizi e contatti è una semplice derivazione dagli oggetti generici forniti. I file in /etc/nagios4/conf.d/ sono una buona fonte di informazione sul loro funzionamento.

Gli amministratori della Falcot Corp usano la seguente configurazione:

Esempio 12.5. file /etc/nagios4/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.12
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}

Questo file di configurazione descrive due host monitorati. Il primo è il server web, ed i controlli sono fatti sulle porte HTTP (80) e HTTP sicuro (443). Nagios controlla inoltre che sulla porta 25 giri un server SMTP. Il secondo host è un server FTP, e il controllo include di accertarsi che arrivi una risposta entro 20 secondi. Oltre questo ritardo, viene emesso un warning; oltre i 30 secondi, l'avviso è considerato critico. L'interfaccia web di Nagios mostra anche che il servizio SSH è monitorato: ciò è determinato dagli host che appartengono all'hostgroup ssh-servers. Il servizio standard corrispondente è definito in /etc/nagios4/conf.d/services_nagios2.cfg.

Notare l'uso dell'ereditarietà: un oggetto eredita da un altro oggetto tramite "use nome-genitore". L'oggetto genitore deve essere identificabile, ovvero richiede una proprietà "name identificatore". Se l'oggetto genitore non deve essere un oggetto reale, ma deve solo servire da genitore, una proprietà "register 0" dice a Nagios di non considerarlo e quindi di ignorare l'assenza di alcuni parametri che altrimenti sarebbero richiesti.

APPROFONDIMENTO Test a distanza con NRPE

Molti plugin di Nagios permettono di controllare alcuni parametri locali di un host; se molte macchine hanno bisogno di questi controlli con un'installazione centrale che li riunisca, bisogna installare il plugin NRPE (Nagios Remote Plugin Executor). Bisogna installare il pacchetto nagios-nrpe-plugin sul server Nagios e nagios-nrpe-server sugli host in cui bisogna eseguire i controlli locali. Quest'ultimo riceve la sua configurazione da /etc/nagios/nrpe.cfg. Questo file deve elencare i controlli che possono essere avviati da remoto e gli indirizzi IP delle macchine autorizzate ad attivarli. Dalla parte di Nagios, abilitare questi controlli remoti si riduce semplicemente ad aggiungere i servizi corrispondenti usando il nuovo comando check_nrpe.