Monitoraggio sistemi con Icinga & C.¶

Installazione base¶

Icinga (http://www.icinga.org) è un fork di Nagios sviluppato in maniera aperta, che presenta numerosi miglioramenti e soprattutto una interfaccia utente nettamente più elaborata. Le presenti istruzioni fanno riferimento all'installazione su Debian, aggiornate a Jessie (ma dovrebbero essere usabili anche su Wheezy dove i backports per check-mk non dovrebbero servire). Per poter utilizzare le versione più recenti disponibili di check-mk (necessario per Jessie che non lo ha nei pacchetti ufficiali) occorre usare il repository di backports; pertanto il primo passo da fare sarà quello di abilitare questi ultimi, aggiungendo a /etc/apt/sources.list la riga:

deb http://httpredir.debian.org/debian jessie-backports main

Per installare Icinga è necessario disporre di un database cui appoggiarsi per lo stoccaggio dei dati, altrimenti la configurazione automatica con dbconfig-common fallirà; nel nostro caso si assumerà l'uso di MySQL su localhost, che dovrà essere già presente, per cui si abbia cura di installarlo preventivamente con:

apt-get install mysql-server

Il pacchetto di Icinga fornito da Debian è suddiviso in due parti, il "core" che reimplementa le funzionalità di Nagios, e la nuova interfaccia web, pertanto installeremo entrambe con (si esegua prima un apt-get update se non lo si è fatto dopo avere aggiunto le fonti di backports):

apt-get install icinga icinga-web icinga-idoutils 
# su Jessie anche
apt-get install icinga-web-config-icinga

Il sistema di debconf chiederà se abilitare o meno l'uso di comandi esterni con Icinga, questo consente, attraverso l'accesso in scrittura della pipe di controllo posta in /var/lib/icinga/rw/ di dare al web server la possibilità di utilizzare l'interfaccia dei comandi CGI, e servirà anche per l'accesso alla stessa da parte di altri programmi di ausilio, pertanto è opportuno attivarla rispetto alla scelta di default. Si verifichi che sia impostato in /etc/icinga/icinga.cfg (se non viene attivato, va fatto manualmente al seguente contenuto):

check_external_commands=1

Oltre a questo è però necessario che ci siano i permessi di accesso corretti per /var/lib/icinga/rw/, il cui default non consente l'accesso, per questo si raccomanda di verificare che siano corretti (su Jessie l'impostazione è ok, su Wheezy no) e nel caso modificarne i permessi di accesso in maniera permanente con:

dpkg-statoverride --update --add nagios www-data 2710 /var/lib/icinga/rw 
dpkg-statoverride --update --add nagios nagios 755

nel qual caso occorrerà riavviare il servizio con service icinga restart, verificando che sia raggiungibile il socket icinga.cmd nella directory citata.

L'interfaccia di debconf chiede anche (qualora si usino diverse alternative) per quale web server generare la configurazione (si lasci il default di apache2), di configurare l'accesso e la creazione di vari database per i quali occorre, usando dbconfig-common, la password di root del database. In particolare oltre al database di icinga stesso, richiesta la configurazione del database di appoggio per lo storico dei dati (icinga-idoutils).

Con debconf vengono anche impostate le password per gli utenti di amministrazione delle interfacce web, che sono icingaadmin per Icinga standard e root per la nuova interfaccia Web. La password di root di icinga-web viene salvata sul database, e può essere modificata con un dpkg-reconfigure del pacchetto; la password di icingaadmin della versione classica (riusata anche da PNP4Nagios) viene salvata sul file /etc/icinga/htpasswd.users e può essere modificata con il comando htpasswd.

Con alcune vecchie versioni di Debian la configurazione di icinga-web può fallire in fase di configurazione, ed allora occorrerà impostare a mano la password dell'utente root nel relativo database, per questo si dovranno eseguire i seguenti comandi (estratti dallo script di post-installazione):

salt=$(php5 -r 'echo hash("sha256", uniqid("root_", mt_rand()));')
export SALT="$salt" 
export PW="passwordlungaecomplicata" 
pwhash=$(php5 -r 'echo hash_hmac("sha256", getenv("PW"), getenv("SALT"));')
salt_e=${salt/\'/\\\'}
pwhash_e=${pwhash/\'/\\\'}
query="UPDATE nsm_user SET user_password='""$pwhash_e""', user_salt = '""$salt_e""', user_modified = NOW() WHERE user_name = 'root';" 
echo $query | mysql -u icinga_web -p icinga_web

fornendo dopo l'ultimo comando la password impostata per il database di icinga-web.

Come accennato delle caratteristiche di icinga è la possibilità di utilizzare un database per lo stoccaggio dei dati, le estensioni per l'utilizzo di questa modalità di gestione dei dati sono fornite dal pacchetto icinga-idoutils (necessario nel caso si voglia utilizzare la nuova interfaccia di icinga-web, che lo richiede come dipendenza e fa configurare il relativo accesso al database). Per poterlo utilizzare deve essere esplicitamente abilitato l'avvio del demone ido2db modificando la seguente riga in /etc/default/icinga:

# start ido2db daemon (no/yes)
IDO2DB=yes

inoltre deve essere attivato il modulo di gestione da parte di Icinga, questo deve essere fatto attraverso l'uso del file di configurazione distribuito con icinga-idoutils, pertanto occorrerà copiare:

cp /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample /etc/icinga/modules/idoutils.cfg

una volta fatto questo si riavviino i relativi servizi con:

service ido2db restart
service icinga restart

e si potrà verificare il funzionamento anche della nuova interfaccia web (dando per scontato di aver creato un opportuno Virtual Host sotto SSL), andando sull'indirizzo https://icinga.miosito.it/icinga-web/.

Con Wheezy un aggiornamento di PHP ha introdotto una regression che causa errori nel funzionamento dell'interfaccia web, questa può essere curata modificando il file /usr/share/icinga-web/app/modules/Cronks/views/System/ViewProc/MetaInformationSuccessView.class.php modificando la riga:

$template = new CronkGridTemplateXmlParser($file);

in:

$template = new CronkGridTemplateXmlParser($file->getRealPath());

Qualora i dati di monitoraggio siano presenti, ma risulti marcata come "_DOWN_" l'instanza di icinga nel quadro riassuntivo, si verifichi che la timezone di sistema in /etc/timezone, quella di PHP nella variabile date.timezone in /etc/php5/apache2/php.ini siano coerenti, nel caso si provveda anche al riavvio di MySQL per fargli vedere i valori corretti.

Grafici delle risorse con PNP4Nagios¶

Uno degli aspetti più rilevanti di un sistema di monitoraggio è quello che consente di mantenere uno storico del consumo delle risorse che consente di tenerne sotto controllo l'evoluzione. A questo scopo è disponibile PHP4Nagios, che supporta anche una opportuna integrazione con icinga; per installarlo fino a Wheezy occorre eseguire il comando:

apt-get install icinga-web-pnp

che installa tutto il necessario nelle dipendenze, con Jessie la cosa non funziona a meno di non aver abilitato in precedenza i repository di backports in quanto alcuni pacchetti sono assenti dalla release ufficiale, pertanto per essere sicuri di installare tutti, si abilitino i suddetti repository e si installi tutto con:

apt-get install pnp4nagios pnp4nagios-bin pnp4nagios-web pnp4nagios-web-config-icinga

Una volta fatto questo con Wheezy vanno fatte alcune correzioni ad alcune configurazioni che sono predisposte per Nagios, occorre modificare /etc/apache2/conf.d/pnp4nagios.conf correggendo le modalità di autenticazione con:

AuthName "Icinga Access" 
AuthUserFile /etc/icinga/htpasswd.users

in modo che corrispondano a quanto presente anche in /etc/apache2/conf.d/icinga.conf, e ci si ricordi di eseguire un reload di Apache.

Con Jessie ueste correzioni non necessarie viene creata una configurazione corretta per Apache nella nuova directory /etc/apache2/conf-available.

Occorre comunque correggere /etc/pnp4nagios/config.php di nuovo per fagli usare i valori opportuni relativi ad Icinga, in particolare si dovranno modificare le seguenti linee:

...
$conf['nagios_base'] = "/icinga/cgi-bin";  # solo per Wheezy, Jessie include un file con il valore corretto
...
$conf['livestatus_socket'] = "unix:/var/lib/icinga/rw/live"; # con Jessie questa è l'unica da cambiare
...
$conf['template_dirs'][] = '/usr/share/check_mk/pnp-templates'; # non più necessario con Jessie
...

Per la generazione dei grafici occorre che Icinga generi i relativi dati, PHP4Nagios prevede diverse modalità per l'accesso agli stessi, la più efficiente è quella dell'uso di un apposito demone, npcd che si appoggia ad un modulo di Icinga. In realtà il demone può essere anche usato da solo, facendo generare i dati ad Icinga nelle opportune directory.

Anzitutto occorre attivare il demone npcd in /etc/default/npcd inserendo la riga:

# Should NPCD be started? ("yes" to enable)
RUN="yes" 

Il secondo passo è configurare Icinga, cosa che varia a seconda delle modalità scelte per generare i dati. Se si sceglie di usare quella consigliata attraverso il modulo npcdmod.o occorrono due passaggi; il primo è quello di indicare ad Icinga di generare i dati, inserendo in /etc/icinga/icinga.cfg la riga:

process_performance_data=1

occorrerà poi abilitare il modulo inserendo in un file di configurazione (nel nostro caso npcdmod.cfg) nella directory /etc/icinga/modules/ con contenuto:

define module{
        module_name    npcdmod
        path           /usr/lib/pnp4nagios/npcdmod.o 
        module_type    neb
        args           config_file=/etc/pnp4nagios/npcd.cfg
        }

ed occorrerà riavviare icinga e npcd con:

service npcd restart
service icinga restart

Attenzione: su Jessie systemd può causare problemi, infatti il restart può non essere eseguito se il primo lancio è avvenuto prima delle modifiche, trovandosi in una situazione in cui systemctl status npcd riporta il servizio attivo ma il programma non gira (la cosa si verifica anche per ido2db). Pertanto si verifichi con ps che i processi siano partiti, e si provveda nel caso a rendere esplicito il restart a quel testone di systemd eseguendo in sequenza:

systemctl stop npcd
systemctl start npcd

verificando che effettivamente alla fine il programma giri.

Controllo con Check_MK¶

Check_MK è programma che consente di gestire il monitoraggio centralizzato di diversi parametri da parte di Icinga con una singola connessione ad un opportuno agent da installare sulle singole macchine da porre sotto controllo. Il programma inoltre fornisce anche una serie di funzionalità di controllo ed autodiscovery dei servizi ed una interfaccia di controllo alternativa. Per l'integrazione con Icinga il primo passo è installare tutto il necessario sul server:

apt-get install check-mk-server check-mk-config-icinga check-mk-livestatus

dove in particolare il secondo pacchetto installa tutti i file necessari ad integrare Check_MK con Icinga.

La configurazione di base prevede che si inserisca la lista delle macchine da sottoporre a controllo nel file /etc/check_mk/main.mk, inizialmente ad esempio con qualcosa del tipo (la configurazione è l'assegnazione di una lista in python):

# Put your host names here
# all_hosts = [ 'localhost' ]
all_hosts = [  'localhost', 'www.fountainpen.it', ... ]

Si tenga presente che la semplice installazione Check_MK di default non comporta nessun controllo, il programma infatti si collega agli agent sulle macchine indicate nel precedente file di configurazione, e raccoglie gli eventuali dati disponibili, ma questi sono normalmente utilizzati soltanto all'interno del programma stesso, se si vogliono poter inserire i controlli dentro Icinga occorre richiedere al programma la generazione degli opportuni file di configurazione, il grande vantaggio di Check_MK è che consente di semplificare ed automatizzare (centralizzando le configurazioni) la generazione di questi file per tutte le macchine che si gestiscono tramite di lui.

La forma precedente /etc/check_mk/main.mk, in cui si inserisce un semplice elenco, è quella più elementare, infatti la variabile all_hosts non solo consente di mantenere un elenco di macchine da controllare, ma anche di classificarle assegnando a ciascuna un numero arbitrario di "TAG" che poi possono essere riutilizzati in altre configurazioni per raggruppare le macchine. L'assegnazione dei tag è molto semplice, basta indicarli dopo il nome della macchina separati con il carattere "|". Pertanto una configurazione di più sofisticata della precedente, potrebbe essere:

# Put your host names here
# all_hosts = [ 'localhost' ]
all_hosts = [  
   'localhost|linux|cnt', 
   'www.fountainpen.it|phy|linux',
    ...
]

dove si sono aggiunti alle macchine il tag "linux" per indicare il sistema operativo, ed i tag "phy" o "cnt" per indicare se la macchina è una macchina fisica o un container. Questo consente ad esempio di applicare configurazioni ad hoc, ad esempio si possono stabilire controlli da ignorare per intere classi di macchine utilizzando la variabile ignored_checks, con qualcosa del tipo:

ignored_checks = [
        ( [ "mem.vmalloc" ], [ "cnt" ], ALL_HOSTS)
]

in cui si esclude per tutti le macchine con il tag "cnt" il controllo sulla dimensione della memoria virtuale occupata (che non ha senso sui container fatti con OpenVZ). La sintassi richiede che si assegni la variabile ad un vettore di tuple. Il primo elemento indica il controllo da escludere (si può ottenere la lista completa si quelli supportati con check_mk -L), segue, opzionale, un tag (o una lista di tag) da utilizzare come filtro, inine la lista degli host da controllare (la variabile ALL_HOSTS indica tutti quelli definiti in all_hosts).

Un'altra delle caratteristiche interessanti di Check_MK è che non solo è possibile utilizzare il controllo eseguito direttamente tramite il suo agent, ma si può configurare direttamente da /etc/check_mk/main.mk l'uso dei programmi di controllo ordinari di Icinga/_Nagios_. In questo caso si deve usare la variabile legacy_checks ed inserire qualcosa del tipo:

legacy_checks = [
  # On all hosts with the tag 'cnt' give a simple check
  ( ( "check_https", "Homepage", True), [ "web" ], ALL_HOSTS ),
  ( ( "check_ssh", "SSH", True), [ "linux" ], ALL_HOSTS ), 
]

in cui si richiede il controllo di SSH su tutte le macchine linux, e quello della risposta del web server su tutti i container. Il formato è identico a quello di ignored_checks per tutti gli argomenti successivi al primo, che in questo caso invece un'altra tupla il cui primo elemento è il nome del comando (come definito dalla direttiva command_name nelle configurazioni dei define command di Icinga/_Nagios_) da usare per il controllo seguito eventualmente anche dai parametri (separati con il carattere !), il secondo la stringa identificativa che verrà associata al servizio, ed il terzo un valore logico che indica se devono essere generati i meno i dati delle performance di risposta (ad uso della generazione dei grafici degli stessi).

Le operazioni di controllo di Check_MK vengono eseguite tramite il comando check_mk che consente di gestire le configurazioni di tutte le macchine controllate con Check_MK, In particolare il comando consente di creare un opportuno file di configurazione per Icinga (sotto /etc/icinga/objects/check_mk/check_mk_objects.cfg nel caso dei pacchetti Debian).

Come accennato si può visualizzare l'elenco dei controlli effettuabili con check_mk -L, ma ovviamente solo alcuni di essi saranno disponibili sulle macchine su cui si è installato l'agent. Per identificare quali sono i controlli disponibili occorre generare il relativo inventario, questo si fa con il comando check_mk -I, eventualmente seguito dall'indirizzo della macchina che si intende controllare. Il comando invocato in questo nuovo però mostra solo quelli nuovi e li aggiunge a quelli già presenti, se si vuole ripartire da zero occorrerà invece usare check_mk -II con cui vengono cancellati quelli vecchi e ricreati solo quelli presenti al momento dell'invocazione.

Un secondo comando di gestione molto utile è check_mk ---scan-parents che fa eseguire un al programma un traceroute delle macchine messe sotto controllo, dal quale viene generata automaticamente la mappa delle dipendenze dell'una dall'altra (riusata poi per generare la gerarchia dei parent anche per Icinga e la relativa status map), che viene salvata automaticamente in /etc/check_mk/conf.d/parents.mk.

Una volta che si sia effettuato il riconoscimento dei servizi per poter utilizzare i dati forniti dall'_agent_ dentro Icinga è necessario lanciare check_mk -R con cui si esegue la rigenerazione dei file di configurazione (nel caso di Icinga i pacchetti Debian indicati lo fanno in /etc/icinga/objects/check_mk/check_mk_objects.cfg), e per una maggior sicurezza si può anche riavviare il servizio (cosa comunque effettuata dal comando). In sostanza tutte le volte che si sono modificate le configurazioni di Check_MK e si vogliono riflettere i cambiamenti su Icinga, si devono eseguire i comandi:

check_mk -I                 # aggiorna l'inventario
check_mk -R                 # rigenera le configurazioni e riavvia
service icinga restart      # repetita juvant...

Si tenga presente però che in dato che Check_MK utilizza il plugin check_icmp di Nagios per controllare lo stato di tutti gli host configurati, se non si fa altro questi risulteranno disattivi (anche se controlli disponibili grazie all'_agent_ risulteranno a posto) in quanto detto plugin deve essere eseguito da root. Esso allora deve essere reso suid in modo da poter funzionare correttamente anche quando invocato da Icinga, di nuovo questo si può fare con il comando:

dpkg-statoverride --update --add root root 4755 /usr/lib/nagios/plugins/check_icmp

che rende la modifica permanente anche nell'aggiornamento dei pacchetti.

L'uso dell'interfaccia web di Check_MK si basa sull'utilizzo di ''livestatus'', una modalità di presentazione dei dati che consente una lettura più veloce ed efficente, cui abbiamo già accennato in precedenta. Questa comporta l'installazione del pacchetto relativo con:

apt-get install -t squeeze-backports check-mk-livestatus

ed una ulteriore configurazione di Icinga; questa può essere fatta usando la nuova funzionalità dei moduli (evitando quindi la direttiva broker_module) inserendo in un file (nel nostro caso livestatus.cfg) nella directory /etc/icinga/modules/ con contenuto:

define module{
        module_name    mklivestatus
        path           /usr/lib/check_mk/livestatus.o
        module_type    neb
        args           /var/lib/icinga/rw/live
        }

dove /var/lib/icinga/rw/live che è il default usato da Check_MK.

Installazione dell'agent di Check_MK¶

Per poter utilizzare a pieno le fuzionalità di Check_MK è necessario installare sulle macchine da mettere sotto controllo (compresa in genere quella su cui si è installato il server), lo script che esegue il compito di agent. Si tratta di un semplice script di shell che deve essere eseguito con xinetd, quest'ultimo però non viene installato automaticamente e deve essere esplicitamente installato, pertanto si esegua:

apt-get install -t squeeze-backports check-mk-agent xinetd

inoltre dato che l'agent installa un file di configurazione per xinetd in cui il servizio è disabilitato, è necessario modificare /etc/xinetd.d/check_mk impostando:

disable        = no

ed eventualmente aggiungere ulteriori direttive di controllo per bloccare gli accessi solo ai server autorizzati; nel caso di installazione locale sul server stesso si potrà mettere il programma in ascolto solo su localhost con:

bind           = 127.0.0.1

mentre in caso di connessione da parte di un server remoto, oltre a proteggerle adeguatamente con un firewall, sarà opportuno indicare una restrizione di accesso con:

only_from      = IP.DEL.SERVER.REMOTO

qualora si voglia usare un nome a dominio al posto di un indirizzo numerico si tenga presente che questo è possibile solo alla condizione che questo corrisponda anche alla risoluzione inversa del relativo IP.

Ci si ricordi sempre di riavviare il servizio con:

service xinetd restart

Si tenga presente che se si installa l'agent sulla macchina stessa su cui gira Icinga, la configurazione di default di quest'ultimo già prevede un controllo eseguito su localhost definito nel file /etc/icinga/objects/localhost_icinga.cfg, che andrà a confliggere con la configurazione creata da check_mk -R, pertanto si abbia cura di rimuovere detto file o di usare con Check_MK un nome diverso per indicare il localhost (ad esempio "127.0.0.1").

Uso di Check_MK come console di controllo¶

Oltre alle funzionalità di controllo centralizzato tramite il server, Check_MK fornisce anche una console di gestione che si può installare con il pacchetto check-mk-multisite, il programma usa mod_python per cui oltre alla installazione sarà necessario anche riavviare apache:

apt-get install check-mk-multisite
service apache2 restart

Inoltre siccome il programma deve creare la directory /var/lib/check_mk/web/icingaadmin/ ed assegnarne il gruppo a nagios, occorre che l'utente www-data faccia parte di detto gruppo, per questo sarà necessario eseguire il comando:

adduser www-data nagios

ed a questo punto si potrà accedere all'interfaccia Web di Check_MK all'indirizzo http://icinga.mioindirizzo.it/check_mk/.

Uso di SNMP con check_mk¶

Per poter utilizzare SNMP con check_mk occorre installare alcuni pacchetti di supporto, in quanto le interrogazioni vengono fatte usando i programmi snmpwalk o snmpbulkwalk, inoltre per poter usare i nomi degli OID occorre anche installare i relativi file di definizione, in sostanza si esegua:

apt-get install snmp snmp-mibs-downloader

inoltre per poter usare i nomi si deve anche modificare /etc/snmp/snmp.conf commentando la riga:

#mibs :

Per poter utilizzare i dati occorre anzitutto inserire nella definizione degli all_host un riferimento con il tag snmp, ad esempio:

all_hosts = [
    ...,
    'switchL3|snmp',
    ...,

ed a questo punto si potrà usare check_mk -I per ottenere un inventario.