312014-05-13 14:51:44BornAgain302011-09-26 10:19:31NiccoloAvico292011-09-26 10:18:11NiccoloAvico282011-09-26 10:08:36NiccoloAvico272011-09-26 09:58:39NiccoloAvico262011-09-25 11:26:33NiccoloAvico252011-09-25 11:19:19NiccoloAvico242011-09-25 11:12:38NiccoloAvico232011-09-25 10:31:47NiccoloAvico222011-09-25 10:23:37NiccoloAvico212011-09-18 11:48:03NiccoloAvico202011-09-18 11:43:59NiccoloAvico192011-09-18 11:42:18NiccoloAvico182011-09-18 11:30:33NiccoloAvico172011-09-18 11:13:08NiccoloAvico162011-07-11 22:26:28NiccoloAvico152011-07-11 22:17:36NiccoloAvico142011-07-11 22:14:10NiccoloAvico132011-07-03 16:12:0193.182.155.31122011-07-03 16:09:5293.182.155.31112011-06-23 21:39:45NiccoloAvico102011-06-07 22:52:29NiccoloAvico92011-06-07 22:50:01NiccoloAvico82011-06-07 22:43:40NiccoloAvico72011-06-07 22:36:27NiccoloAvico62011-06-07 17:37:40NiccoloAvico52011-06-07 17:29:07NiccoloAvico42011-06-07 16:29:36NiccoloAvico32011-06-07 14:11:13NiccoloAvico22011-06-07 12:24:36NiccoloAvico12011-06-07 11:11:36NiccoloAvico

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.

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) oppure debian (in questo caso la versione è Nagios3).

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 Nagios3.

La spiegazione generale del meccanismo di monitoraggio tramite proxy, 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: istanza proxy check_test su un host del proprio bacino esecuzione dell'ocsp (o dell'ochp se era un test di un host) invio tramite client NCSA del risultato del test al NCSA server istanza centrale ricezione del check da parte del NCSA server NCSA server inserisce una PROCESS_SVC_CHECK_RESULT nella named pipe degli external commands del core 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

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. Oltre agli apparati in radiofrequenza, Nagios (e quindi il proxy) può monitorare qualsiasi altro oggetto in rete (NAS, printer server, host con servizi, ecc.). In particolare il proxy è oggetto di monitoraggio da parte di se stesso, e in questo caso i servizi monitorati possono essere anche di sistema. 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 (se esiste) 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.

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

A seguito della installazione dei pacchetti, vengono generate le directory: /etc/nagios - file di configurazione generali /etc/nagios/commands - file di configurazione dei comandi di check di nagios /etc/libexec/nagios - contiene gli eseguibili dei test Inoltre a cura dell'installazione viene generato lo script /etc/init.d/nagios. ATTENZIONE: gli eseguibili dei check vengono posti dall'installazione in /usr/libexec/nagios/ mentre la directory riferita nelle definizioni dei comandi è /usr/lib/nagios/plugins/ quindi occorre creare a mano un link simbolico plugins dentro /usr/lib/nagios/ che punti a /usr/libexec/nagios/, altrimenti i check nagios locali non potranno essere eseguiti.

Si deve scaricare il file nagios-openwrt.tar dal repository e, ponendosi come utente root nella directory /, ne deve essere estratto il contenuto (tar xvf nagios-openwrt.tar). Questa azione crea le directory necessarie per ninux e aggiunge o sovrascrive alcuni file originali dell'installazione.

Il file fondamentale per Nagios è /etc/nagios/nagios.cfg, riferito a startup in /etc/init.d/nagios Per informazione, 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.

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 la tabella degli indirizzi ci si deve pertanto assicurare che non esista già per l'apparato un altro Proxy e nel caso decidere quale dei due è il più vicino. Come detto, tutti i nodi devono essere posti nella directory /etc/nagios/ninux, utilizzando per convenzione 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 righe con 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. Inoltre si deve porre a "1" il parametro "active_checks_enabled".

I seguenti tre pacchetti devono essere scaricati e installati: nagios3, nagios-plugins, send-nsca.

A seguito della installazione dei pacchetti, vengono generate le directory: /etc/nagios3 - file di configurazione generali /etc/nagios-plugins/config - file di configurazione dei comandi di check di nagios /usr/lib/nagios/plugins - contiene gli eseguibili dei test /var/log/nagios - contiene nagios.log (file riferito in /etc/nagios/nagios.cfg) Inoltre a cura dell'installazione viene generato lo script /etc/init.d/nagios3.

Si deve scaricare il file nagios-debian.tar dal repository e, ponendosi come utente root nella directory /, ne deve essere estratto il contenuto (tar xvf nagios-debian.tar). Questa azione crea le directory necessarie per ninux e aggiunge o sovrascrive alcuni file originali dell'installazione. Dopo aver compiuto l'estrazione si deve modificare il proprietario dei file di configurazione: chown -R nagios:nagios /etc/nagios3/ninux

Il file fondamentale per Nagios è /etc/nagios3/nagios.cfg, riferito a startup in /etc/init.d/nagios3, che viene sovrascritto dal tar di ninux. Per informazione, 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. Altro file importante, che invece va personalizzato, è /etc/nagios/localhost.cfg che deve riportare il nome del proxy come host_name e il relativo IP. Queste informazioni, comuicate a uno degli amministratori della istanza centrale di Nagios, saranno utilizzate per creare un nuovo oggetto linux-servers che consentirà al proxy di essere a sua volta monitorato da Nagios.

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 la tabella degli indirizzi ci si deve pertanto assicurare che non esista già per l'apparato un altro Proxy e nel caso decidere quale dei due è il più vicino. Come detto, tutti i nodi devono essere posti nella directory /etc/nagios3/ninux, utilizzando per convenzione 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, la direttiva parents poiché questa informazione non viene utilizzata 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. Inoltre si deve porre a "1" il parametro "active_checks_enabled".

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 (nagios3 -v /etc/nagios3/nagios.cfg per ambiente linux), 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 (/var/log/nagios3/nagios.log per debian) (devono apparire tutti i comandi inviati tramite send_nsca).

Potrebbe anche interessarti : How to integrate autofwd with Nagios

[1] - [2] - [3] - [4] - [5] - [6] -