Configurazione di un proxy Nagios per monitoraggio distribuito

Lo sviluppo del backbone della rete Ninux ha reso necessaria l'introduzione di uno strumento per il suo monitoraggio costante, in grado di (a) segnalare tempestivamente l'eventuale insorgere di fenomeni e problematiche con impatto potenzialmente negativo sulla stabilità della comunicazione dati e (b) essere d'aiuto nel processo di troubleshooting.
Lo strumento utilizzato allo scopo è la piattaforma Nagios, inizialmente configurata in modalità completamente centralizzata. L'esperienza tuttavia ha dimostrato che i check eseguiti per verificare la funzionalità degli apparati e dei link, basati su test indiretti implementati a livello rete, soffrono di imprecisioni dovute alle condizioni istantanee del canale di trasporto del test (che è effettuato in-banda), che possono generare tipicamente falsi allarmi o comunque aumentare il ritardo nella trasmissione.

Premessa: il monitoraggio distribuito

Per superare le difficoltà citate si può, oltre a progettare test il cui risultato sia per quanto possibile svincolato dalla condizione dei canali intermedi (processo oggetto di work in progress sperimentale), utilizzare la modalità che Nagios offre di monitoraggio distribuito. Questa modalità prevede l'esistenza di una istanza centrale Nagios, che riceve da istanze distribuite (proxy clusterizzati Nagios) le segnalazioni relative all'esito di check eseguiti da ciascun proxy sul proprio cluster di nodi. Se i proxy sono sufficientemente distribuiti nella topologia, è possibile minimizzare i tragitti intermedi (hop) percorsi sulla rete dai pacchetti di test, con un impatto molto positivo sul fenomeno delle imprecisioni indotte nelle misure, descritto inizialmente.
In questo wiki verrà spiegato come implementare un nuovo proxy Nagios, tecnicamente e organizzativamente, utilizzando una piattaforma openWRT (per cui è disponibile Nagios2). Nel caso di un ambiente linux generico ci sono alcune piccole differenze, in quanto la versione che può utilizzarsi è già la Nagios3.

Requisiti

Per implementare un proxy di monitoraggio Nagios è richiesto disporre di un hardware acceso per l'intera giornata (h24), possibilmente alimentato tramite UPS. Il sistema operativo può essere openWRT (backfire 10.03.1-rc4 o superiore) o anche una qualsiasi versione di linux per la quale sia disponibile il pacchetto Nagios, nella versione minima 2.0.
Le istruzioni riportate di seguito faranno riferimento al caso Nagios 2.0 su OpenWRT.

Principio di funzionamento

La spiegazione generale del meccanismo, riassunta di seguito, è spiegata dettagliatamente in [1].

• Sono presenti una istanza Nagios centrale + tante istanze proxy, distribuite quanto più possibile e con dominio di monitoraggio più granulare possibile;

• L'istanza centrale possiede la definizione di tutti gli oggetti di rete che saranno monitorati, sia da lei che dai proxy; in particolare normalmente si incarica di effettuare monitoraggi attivi solo sugli apparati a lei prossimi, mentre per gli apparati cui delega il monitoraggio ai proxy è specificato che gli active checks sono disabilitati;

• L'istanza proxy generica viene configurata priva di interfaccia web; inoltre si debbono disabilitare le notifiche ai contatti; i comandi e la definizione dei servizi da monitorare sono comuni per tutte le istanze proxy, mentre quello che varia sono i file degli host e dei servizi presenti nel bacino di monitoraggio individuale;

• Ogni istanza proxy utilizza un plug-in denominato NSCA client [2], mentre l'istanza centrale dispone di un corrispondente NSCA server: questa coppia di software abilita la comunicazione al centro dei passive service checks [3]

• La configurazione della istanza proxy deve prevedere anche (cfr. [4]) l'esecuzione di un comando ocsp e ochp da attivare SEMPRE A SEGUITO DI OGNI check eseguito; questo comando, banalmente, sarà la trasmissione del risultato del check stesso al Nagios centrale, utilizzando il modulo NCSA client;

• Nella istanza centrale deve essere attivato il meccanismo degli external commands [5], che consente di dirigere le attività (in questo caso inviare allarmi) a Nagios tramite una named pipe.

La catena di trasmissione degli eventi è pertanto:

1. istanza proxy
   1. check_test su un host del proprio bacino
   2. esecuzione dell'ocsp (o dell'ochp se era un test di un host)
   3. invio tramite client NCSA del risultato del test al NCSA server
2. istanza centrale
   1. ricezione del check da parte del NCSA server
   2. NCSA server inserisce una PROCESS_SVC_CHECK_RESULT nella named pipe degli external commands del core

   3. Nagios (con frequenza definita da [6]) controlla la presenza di check_result nella named pipe e acquisisce il risultato del test come se lo avesse eseguito dalla istanza centrale

Quali apparati monitorare?

Il monitoraggio di tutto l'insieme degli apparati della rete ninux è effettuato da un server Nagios centralizzato, il quale però è stato configurato per non eseguire check in prima persona, aspettandosi che un qualche Proxy li esegua per lui.
Siccome questa condizione non è ancora sempre vera, il server Nagios interviene (con periodicità più alta) con un check diretto, qualora non riceva notifiche da nessun Proxy per quell'apparato.
In ogni caso, un apparato può essere monitorato da non oltre un proxy, ovvero tutti gli apparati sono ripartiti su più zone-proxy Nagios, in maniera disgiunta. Più precisamente, ogni proxy monitora un certo numero di apparati a lui prossimi per topologia (cosiddetta zona-proxy); per ogni apparato oggetto di monitoraggio è bene indicare quale Proxy lo ha in carico, nella tabella degli indirizzi.
Da notare che la configurazione delle zone-proxy non è statica: nel tempo, qualsiasi nodo (in radiofrequenza) della rete ninux, che rispetti i requisiti esposti in precedenza, può installare presso di se un nuovo proxy Nagios, il quale monitorerà K apparati. Se uno o più di questi K apparati erano già sotto monitoraggio da parte di altri proxy, (cioé se erano già appartenenti ad altre zone-proxy), essi dovranno essere spostati sotto il monitoraggio del nuovo proxy N+1, cancellati dalla configurazione dei Proxy che li avevano in cura fino a quel momento e anche la tabella degli indirizzi andrà aggiornata di conseguenza.
Operativamente, una volta eseguita l'installazione del software Nagios sul proxy, sulla base della topologia della rete e dei proxy Nagios già predisposti viene decisa la porzione di rete da trasferire di monitoraggio: i relativi oggetti host vengono trasferiti dalla configurazione del/dei proxy cedente/i a quella del proxy N+1. Dal punto di vista dell'istanza centrale nulla cambia, in quanto le notifiche vengono trattate indipendentemente da chi le manda.

Componenti sw da installare

I seguenti tre pacchetti devono essere scaricati dal repository openWRT: nagios, nagios-plugins, send-nsca.

Aspetti di configurazione comune

Le directory previste

A seguito della installazione dei pacchetti, vengono generate le directory:

• /etc/nagios - file di configurazione generali
• /etc/libexec/nagios - contiene gli eseguibili dei test

Inoltre a cura dell'installazione viene generato lo script /etc/init.d/nagios. Sotto /etc/nagios devono essere manualmente create le directory ninux e commands: nella prima vengono messi tutti i file individuali contenenti le definizioni degli apparati oggetto del monitoraggio (v. oltre); nella seconda vengono invece messe le definizioni dei comandi. Queste due directory, per essere utilizzate, devono comparire in nagios.cfg (v. oltre).

I file di configurazione

Il file fondamentale per Nagios è /etc/nagios/nagios.cfg, riferito a startup in /etc/init.d/nagios
Siccome le direttive contenute in questo file sono comuni a tutti i proxy, il nagios.cfg può essere copiato da una qualsiasi altra istanza proxy. Le parti fondamentali del file riguardano l'esecuzione degli active_checks (deve essere abilitata) e dei passive checks (deve essere disabilitata). Le notifiche devono essere disabilitate. La parte chiave per i proxy Nagios riguarda invece le direttive obsess: obsess_over_services deve essere =1 e deve essere specificato il comando da eseguire obsess. Questo comando deve essere contenuto nel file commands.cfg; il date_format è bene che sia iso8601 ovunque. Per il resto si lasciano i default dell'installazione.

Altro file importante è commands.cfg che deve specificare l'implementazione del comand obsess.
Tutti i file sopra descritti possono essere clonati da un proxy qualsiasi già operativo. Invece localhost.cfg deve essere modificato per riportare le esatte caratteristiche della macchina ospite del proxy, a partire da un nome host diverso da ogni altro. Questa definizione di host andrà poi riportata tra gli host registrati presso l'istanza Nagios centrale, che altrimenti non sarà in grado di riconoscere gli allarmi di questo apparato; da notare che SOLO presso l'istanza centrale saranno nuovamente definiti anche contacts e parents.
Il contenuto delle directory /etc/nagios/commands e quello di /usr/libexec/nagios può di nuovo essere clonato da quelle analoghe di un qualsiasi altro proxy openWRT operativo; per quest'ultima occorre accertarsi (a) che esista la directory indicata nei file della directory /etc/nagios/commands (nel caso basta creare un link simbolico); (b) dei corretti permessi di esecuzione e (c) che il file submit_check_result indirizzi correttamente il server Nagios centrale. Terminata la verifica locale è bene predisporre una verifica sulla istanza del server centrale, andando a seguire il relativo logfile e controllando che i comandi emessi dal nuovo proxy siano arrivati.

La configurazione degli apparati

Come già detto è bene che ogni apparato sia monitorato da (al più) un Proxy, e in particolare dal più prossimo nella topologia di rete. Tramite tabella degli indirizzi ci si deve assicurare quindi che non esista un altro Proxy e nel caso decidere quale è il più vicino all'apparato che si sta configurando.
Come detto, tutti i nodi vengono inseriti nella directory /etc/nagios/ninux utilizzando per convenzione (per Nagios non è obbligatorio) una alberatura sulla base del tipo di apparato. Ogni apparato è descritto in un proprio file .cfg
Siccome ogni apparato è sicuramente già stato definito presso l'istanza centrale di Nagios, sarà sufficiente copiare il relativo file .cfg dalla sua posizione nel server centrale, ponendolo in una posizione analoga dell'alberatura del proxy. IMPORTANTE: ci si deve accertare di eliminare, dalla versione locale al Proxy, le direttive contacts e parents poiché queste informazioni non vengono utilizzate nella esecuzione dei check da parte del proxy, bensì solo nella notifica degli eventi e nel disegno della mappa, entrambe operazioni localizzate nella istanza Nagios centrale.

Test pre-flight

Quando si è terminata la fase preparatoria della nuova installazione, predisponendo come illustrato tutti i file di configurazione, è opportuno eseguire un test diagnostico del lavoro fatto: a tal fine è sufficiente invocare il comando nagios -v /etc/nagios/nagios.cfg, il cui output descriverà tutti i problemi e incongruenze eventualmente presenti nelle definizioni. solo quando questo test pre-flight avrà dato esito positivo, sarà possibile attivare il processo proxy (nagios start).
Appena avviato il proxy se ne deve verificare il corretto funzionamento: localmente si può consultare il file /tmp/nagios.log (devono apparire tutti i comandi inviati tramite send_nsca).

Riferimenti sul web

[1] - http://nagios.sourceforge.net/docs/3_0/distributed.html
[2] - http://nagios.sourceforge.net/docs/3_0/addons.html#nsca
[3] - http://nagios.sourceforge.net/docs/3_0/passivechecks.html
[4] - http://nagios.sourceforge.net/docs/3_0/configmain.html#ocsp_command
[5] - http://nagios.sourceforge.net/docs/3_0/extcommands.html
[6] - http://nagios.sourceforge.net/docs/3_0/configmain.html#command_check_interval