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 accesso H24, possibilmente alimentato tramite UPS. Il sistema operativo può essere openWRT (backfire 10.03.1-rc4) o anche una qualsiasi versione di linux per la quale sia disponibile il pacchetto Nagios, nella versione minima 2.0. di seguito le istruzioni faranno riferiumento al caso 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 ha le notifiche disabilitate; 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 assive 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 nodi monitorare?

Qualsiasi nodo che rispetti i requisiti esposti in precedenza può installare un nuovo proxy Nagios. Questa decisione si traduce nel fatto che alcuni apparati, già monitorati da uno o più proxy tra gli N esistenti al momento, dovranno essere spostati sotto il monitoraggio del nuovo proxy N+1.
Pertanto, 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 repositiry openWRT: nagios, nagios-plugins, send-nsca.

Aspetti di configurazione comune

mmm

La configurazione dei nodi

mmm

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