Questo è un mio articolo pubblicato originariamente su Openlogic/Wazi
Nagios , è la principale applicazione open source di monitoraggio per infrastrutture, è possibile monitorare l’intera struttura aziendale utilizzando uno schema di monitoraggio distribuito in cui le istanze locali di Nagios (chiamate slave) eseguono le attività di monitoraggio e riferiscono i risultati ad una istanza centrale (chiamata master).Tutta la gestione della configurazione, le notifiche ed i report sono effettuati dal master, mentre gli slave fanno tutto il lavoro.
Questo progetto sfrutta la capacità di utilizzare in Nagios i controlli passivi – ovvero applicazioni esterne o processi che inviano i risultati a Nagios. In una configurazione distribuita, queste applicazioni esterne sono altre istanze di Nagios.
Perché utilizzare una configurazione distribuita? Una soluzione distribuita potrebbe essere necessaria se si dispone di host e/o servizi su una LAN separata che non è raggiungibile con l’istanza principale di Nagios. Un’implementazione distribuita offre anche una maggiore privacy, in cui gli utenti possono essere definiti per accedere solo a determinati servizi e host. È possibile avere la configurazione e le notifiche centralizzate, avendo così una visione unica e consolidata dello stato di tutti i dispositivi e le sottoreti.
Una soluzione distribuita è spesso chiamata una soluzione master/slave. Sul master si dispone di una copia di ogni servizio che si vuole controllare sulle macchine slave, ma la copia del master ha la caratteristica di avere il controllo attivo disabilitato e la notifica abilitata, mentre gli slave hanno i controlli attivi e passivi abilitati e le notifiche disabilitate.
Diamo uno sguardo al file di configurazione per uno slave ed il master, che in questo caso, verifica una pagina web, questo ci consente di illustrare la differenza. Di solito queste configurazioni si possono trovare nella directory di configurazione di Nagios, spesso situata in /etc/nagios3/conf.d/services.cfg:
Configurazione Slave:
# Generic service definition template
define service{
name generic-service ;
active_checks_enabled 1 ;
passive_checks_enabled 1 ;
parallelize_check 1 ;
obsess_over_service 1 ;
check_freshness 0 ;
notifications_enabled 0 ;
event_handler_enabled 1 ;
flap_detection_enabled 1 ;
process_perf_data 1 ;
register 0 ;
}
# Service definition for http
define service{
use generic-service ;
host_name www.mysite.com ;
service_description HTTP ;
is_volatile 0 ;
check_period 24x7 ;
max_check_attempts 3 ;
normal_check_interval 1 ;
retry_check_interval 5 ;
contact_groups admins,webmaster ;
notification_options w,u,c,r ;
notification_interval 960 ;
notification_period never ;
check_command check_http ;
}
Configurazione Master :
# Generic service definition template
define service{
name generic-service ;
active_checks_enabled 0 ;
passive_checks_enabled 1 ;
parallelize_check 1 ;
obsess_over_service 1 ;
check_freshness 0 ;
notifications_enabled 1 ;
event_handler_enabled 1 ;
flap_detection_enabled 1 ;
process_perf_data 1 ;
register 0 ;
}
# Service definition for http
define service{
use generic-service ;
host_name www.mysite.com ;
service_description HTTP ;
is_volatile 0 ;
check_period 24x7 ;
max_check_attempts 3 ;
normal_check_interval 1 ;
retry_check_interval 5 ;
contact_groups admins,webmaster ;
notification_options w,u,c,r ;
notification_interval 960 ;
notification_period 24x7 ;
check_command check_http ;
}
Un buon candidato per diventare uno slave Nagios è un server vicino (nel senso di rete) ai servizi che si desidera monitorare. Un buon master deve essere raggiungibile da tutti i suoi slave. Le risorse hardware necessarie sia per gli schiavi che per il master dipendono dal numero e tipo di controlli che fate. Di solito Nagios non è particolarmente avido di risorse, quindi si dovrebbe essere in grado di monitorare fino a 5.000 servizi da qualsiasi schiavo e raccogliere dai 20.000 a 30.000 servizi su un master.
Una volta che avete scelto le macchine del caso, seguite la normale procedura di installazione di Nagios su entrambi le tipologie di server che ospitano il servizio Nagios, modificando il file di configurazione come sopra.
Unire i pezzi
Il concetto alla base del collegamento di tutti i pezzi è il concetto di “servizio passivo”, realizzato con Nagios Service Check Acceptor (NSCA). Questo software viene eseguito come demone sul master, ed attende le informazioni sui servizi. Gli slave utilizzano il software nsca_client per inviare informazioni sui loro servizi al master. Per farlo, è necessario specificare nel file di configurazione principale di Nagios quello che si chiama unobsessive compulsive service processor (OCSP), questo comando viene eseguito dopo ogni controllo. Nella sua forma più elementare, la parte rilevante del file di configurazione di uno slave Nagios potrebbe essere simile a questa:
# /etc/nagios/nagios.cfg . . . obsess_over_services=1 ocsp_command=submit_service_check ocsp_timeout=5 obsess_over_hosts=1 ochp_command=submit_host_check ochp_timeout=5
Dovete quindi definire il ocsp_command submit_service_check nel file /etc/nagios/conf.d/commands.cfg:
define command
{
command_name submit_service_check
command_line /usr/lib/nagios/plugins/submit_service_check.sh
$HOSTNAME$ '$SERVICEDESC$' $SERVICESTATEID$ '$SERVICEOUTPUT$'
Ed infien, bisogna definire lo shell script definito come command_line. Quello che segue potrebbe essere il vostro /usr/lib/nagios/plugins/submit_service_check.sh:
#!/bin/bash /usr/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$3" "$4" | /usr/lib/nagios/plugins/send_nsca -H -c /usr/lib/nagios/send_nsca.cfg |
Anche se semplice, questa soluzione è inefficiente e usa un sacco di risorse, perché per ogni check effettuato per ogni servizio lo slave deve iniziare un nuovo processo shell, ed eseguire un comando nsca_client . A meno che non si abbiano meno di 100 servizi sullo slave, non utilizzate questa soluzione. Provate invece una di queste alternative più efficienti:
- OCSP Sweeperè un programma che viene eseguito sullo slave e crea una coda FIFO a cui vengono inviati gli eventi OCSP. Legge il contenuto della coda ogni N secondi e invia i dati, accorpati, al server NSCA sul master.
- With OCP_Daemon, Nagios scrive le informazioni sui check di host e servizi in una named pipe invece che eseguire un comando ogni volta per inviare le informazioni al master. Un demone sonda regolarmente la pipe e si occupa di inviare i dati al server master Nagios.
Se si utilizza una di queste alternative bisogna modificare sul master, il file /etc/nsca/nsca.conf e impostare l’opzione aggregate_writes per il demone NSCA a 1. Con questa configurazione, NSCA elaborerà i risultati in una sola volta, e vi darà un piccolo incremento di prestazioni sul master.
Popular Posts:
- None Found
