Dimensione: 11007
Commento:
|
Dimensione: 12619
Commento:
|
Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
Linea 11: | Linea 11: |
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 anche una qualsiasi versione di linux per la quale sia disponibile il pacchetto Nagios, nella versione minima 2.0. di seguito le istruzioni faranno riferimento al caso openWRT. | 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. <<BR>> Le istruzioni riportate di seguito faranno riferimento al caso Nagios 2.0 su OpenWRT. |
Linea 34: | Linea 36: |
Il monitoraggio di tutto l'insieme degli apparati della rete ninux è ripartito su più ''zone-proxy'' Nagios, in maniera semi-disgiunta. Più precisamente, ogni proxy monitora un certo numero di apparati a lui prossimi per topologia (cosiddetta ''zona-proxy''); gli apparati di confine tra una ''zona-proxy'' e una adiacente vengono monitorati da due proxy (a livello di interfaccia radio). |
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.<<BR>> 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.<<BR>> 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 [[http://wiki.ninux.org/GestioneIndirizzi|tabella degli indirizzi]]. |
Linea 37: | Linea 41: |
Qualsiasi nodo (in radiofrequenza) della rete ninux, che rispetti i requisiti esposti in precedenza, può installare presso di se un nuovo proxy Nagios. Questa decisione si traduce nel fatto che alcuni apparati, appartenenti ad altre ''zone-proxy'', dovranno essere '''spostati''' sotto il monitoraggio del nuovo proxy N+1. | 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. |
Linea 41: | Linea 45: |
I seguenti tre pacchetti devono essere scaricati dal repositiry openWRT: '''nagios''', '''nagios-plugins''', '''send-nsca'''. | I seguenti tre pacchetti devono essere scaricati dal repository openWRT: '''nagios''', '''nagios-plugins''', '''send-nsca'''. |
Linea 48: | Linea 52: |
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). | 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). |
Linea 51: | Linea 55: |
In questo file le direttive sono comuni a tutti i proxy, quindi deve 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. |
|
Linea 55: | Linea 56: |
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. <<BR>><<BR>> |
|
Linea 56: | Linea 61: |
<<BR>> | |
Linea 58: | Linea 64: |
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. | 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. |
Linea 60: | Linea 67: |
=== Caso di un apparato esistente === Come detto, tutti i nodi vengono inseriti nella directory /etc/nagios/ninux ognuno nel proprio file .cfg Ci si deve accertare che in nessuna definizione compaia la direttiva ''contacts'' ne la direttiva ''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. Infine è bene cancellare il file dal proxy ''cedente''. === Caso di un apparato nuovo === Per ogni nuovo apparato occorre predisporre un file che conterrà la descrizione delle sue caratteristiche. Può essere copiato e riadattato un file relativo a un apparato della stessa classe (m5, openwrt, linux, ecc.) facendo attenzione a specificare il nome host, le classi di servizio cui appartiene, l'indirizzo IP. Una versione analoga ma più ricca dello stesso file deve essere registrato anche presso l'istanza Nagios centrale: in questo caso si devono aggiungere i riferimenti ai contatti e la collocazione del nuovo apparato nella topologia della rete, con riferimento all'apparato immediatamente precedente lungo il percorso dal nuovo apparato verso l'istanza Nagios centrale. |
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 [[http://wiki.ninux.org/GestioneIndirizzi|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. <<BR>> 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 <<BR>> 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. <<BR>> |
Linea 69: | Linea 77: |
<<BR>> 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). |
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:
- 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
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