|
|
<- Grazie Claudio! - Indice Generale - Copertina - Piccoli server web -> |
|
Sistemi Liberi
L'articolo...Inizia con questo articolo una serie dedicata al monitoraggio dei sistemi in rete. Si inizia con Nagios! |
Chiunque abbia avuto l'opportunità di amministrare una rete con un certo
numero di PC, o comunque una rete in cui sono attivi dei servizi critici, ha
certamente avuto la necessità di monitorare gli elementi di
criticità della stessa. Esistono infatti situazioni ove l'interruzione di un
servizio può portare un grosso danno economico, commerciale o d'immagine. In
altri casi, ancora più critici, un server bloccato o un servizio mancante può
mettere a rischio l'incolumità delle persone.
Quasi tutti i grossi nomi dell'informatica hanno a catalogo almeno una soluzione
per tale necessità. Sono solitamente soluzioni che, a causa dei loro costi,
trovano giustificazione di impiego solo dove la rete da amministrare sia
veramente complessa o dove la criticità dei servizi sia molto elevata: sono inoltre
quasi sempre macchinose da avviare e da utilizzare e per mitigare (apparentemente) tale situazione
a volte portano con se una serie di servizi aggiuntivi per aiutare gli amministratori di rete nel proprio lavoro.
Non potevano mancare ovviamente anche delle soluzioni "Open Source" al problema: dopo averne provate alcune la mia scelta è caduta su Nagios.
Questo programma è stato scritto da Ethan Galstad sulla base di un suo programma precedente, Netsaint, il quale aveva, a suo parere, dei difetti di architettura tali da richiedere la riscrittura del codice. Non contiene funzioni per la gestione della rete ma solo per il monitoraggio di apparecchiature e servizi. Ho volutamente scritto apparecchiature, e non computer, in quanto il programma è in grado di monitorare anche switch, router, stampanti e altro, oltre che servizi più o meno standard come HTTP, FTP, POP3 e similari.
Nagios è fortemente personalizzabile, in quanto i controlli avvengono tramite programmi esterni (plugin) e la disponibilità del codice sorgente facilita la scrittura di nuovi test, qualora non esistessero già. La scelta di non includere i test all'interno del cuore del programma è, a mio parere, molto valida in quanto lo rende facilmente espandibile a nuove funzionalità e nello stesso tempo permette a Galstad ed ai suoi collaboratori di concentrarsi solo sul motore del programma stesso.
Una volta rilevato un problema in un dispositivo sotto monitoraggio, il programma è in grado di segnalare i malfunzionamenti attraverso la sua interfaccia (Web), spedendo una e-mail ad un gruppo di persone definito in precedenza o addirittura di avvisandole attraverso l'invio di un SMS. Tale fase, detta notifica, è anch'essa fortemente personalizzabile e può essere gestita con un qualsiasi programma esterno al motore di Nagios.
Di seguito vedremo come installare il programma ed alcuni esempi di funzionamento.Nella sezione download del sito di Nagios sono disponibili sia i pacchetti precompilati per Red Hat e Fedora GNU/Linux sia i sorgenti da compilare. Sarebbe opportuno utilizzare i sorgenti per avere a disposizione il codice per eventuali modifiche.
I plugin per Nagios sono, come detto, sviluppati separatamente dal corpo principale del programma. E` consigliabile quindi scaricare subito anche i plugin dal sito http://sourceforge.net/projects/nagiosplug/. Dal sito NagiosExchange potete scaricare il demone NSCA utile per l'inoltro dei test passivi ed il modulo NRPE per l'esecuzione di test remoti. Lo stesso sito è una fonte inesauribile di plugin e suggerimenti. Non sono indispensabili, ma si possono ottenere anche delle icone per abbellire l'interfaccia web. Sono facilmente rintracciabili nel sito NagiosEchange.
Fra i prerequisiti del programma vi sono:
setlocale (LC_ALL, "") in setlocale (LC_ALL, "C") |
L'installazione è semplice, anche se non banale, e ben documentata nel manuale
in linea. Chi ne ha la possibilità tenga a disposizione il manuale in linea
per tutta la durata dell'installazione per copiare direttamente i comandi dallo stesso ad un
terminale. Chi non volesse rimanere connesso sappia che dopo la
aver scompattato i sorgenti il manuale è disponibile localmente in
nagios-2.0b4/html/docs/
E' bene precisare che le operazioni di installazione vanno eseguite come utente
root. Tale pratica è solitamente sconsigliata ma, in questo caso, non può essere
evitata. Si presuppone quindi che se dovete monitorare dei sistemi e installare un
programma di monitoraggio sappiate muovervi con la dovuta cautela fra i file
di sistema.
Scompattiamo i sorgenti i una cartella a nostra scelta:
#tar -zxvf nagios-2.0b4.tar.gz |
Creiamo l'utente ed il gruppo per Nagios e aggiungiamo al gruppo l'utente apache, che deve avere accesso all'interfaccia web del programma. Quest'ultimo utilizzerà i permessi dell'utente/gruppo apache durante l'esecuzione, aumentando il grado di sicurezza del sistema. Non sarebbe sicuro infatti se Nagios venisse fatto girare con i permessi di root in quanto in caso di un exploit secondario ad un suo (sempre possibile) bug si riuscirebbe a guadagnare il controllo del sistema. Creando un utente ad-hoc il problema viene notevolmente ridotto.
# adduser nagios # /usr/sbin/groupadd nagcmd # /usr/sbin/usermod -G nagcmd apache # /usr/sbin/usermod -G nagcmd nagios |
Creiamo la directory che ospiterà il programma e settiamo i corretti permessi per l'utente appena creato.
# mkdir /usr/local/nagios # chown nagios.nagios /usr/local/nagios |
Benché sia possibile compilare il programma con varie opzioni relative ai percorsi di utilizzo, a meno che non vi siano rischi di sicurezza, si consiglia di non modificare le impostazioni standard in modo che le istruzioni seguenti siano coerenti. Quindi usiamo l'istruzione configure senza parametri
# cd nagios-2.0b4
# ./configure
------
[---si omette l'output, per brevità, riportando solo l'ultima parte---]
------
*** Configuration summary for nagios 2.0b4 08-02-2005 ***:
General Options:
-------------------------
Nagios executable: nagios
Nagios user/group: nagios,nagios
Command user/group: nagios,nagios
Embedded Perl: no
Event Broker: yes
Install ${prefix}: /usr/local/nagios
Lock file: ${prefix}/var/nagios.lock
Init directory: /etc/rc.d/init.d
Host OS: linux-gnu
Web Interface Options:
------------------------
HTML URL: http://localhost/nagios/
CGI URL: http://localhost/nagios/cgi-bin/
Traceroute (used by WAP): /bin/traceroute
Review the options above for accuracy. If they look okay,
type 'make all' to compile the main program and CGIs.
|
Il risultato dell'operazione di configurazione dovrebbe riportare tutti i percorsi configurati. Può essere utile prendere nota di tali dati e poi passare a compilare ed installare:
# make all # make install # make install-init # make install-commandmode # make install-config |
L’ultima istruzione installa i file di esempio di configurazione che ci serviranno poi per avere una base da cui partire senza riscriverli da zero. A questo punto è possibile passare all’installazione dei plugin che vanno scaricati e compilati separatamente e alla configurazione dell’interfaccia web. Le operazioni sono le seguenti:
# tar -zxvf nagios-plugins-1.4.2.tar.gz # cd nagios-plugins-1.4.2 # ./configure # make # make install |
La configurazione dell'interfaccia web si basa sull'ipotesi che utilizziate il
server Apache e sia installato nella stessa macchina in cui è installato Nagios.
La corretta configurazione di Apache è, chiaramente, un prerequisito e le note
che seguono servono per la sola configurazione di Nagios.
Nel nostro esempio le modifiche vanno applicate al file di configurazione di
Apache ovvero:
# vi /etc/httpd/conf/httpd.conf |
alla fine del file, come da manuale di Nagios, aggiungiamo quanto segue:
ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin
<Directory "/usr/local/nagios/sbin">
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
Alias /nagios /usr/local/nagios/share
<Directory "/usr/local/nagios/share">
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>
<Directory /usr/local/nagios/sbin>
AllowOverride AuthConfig
order allow,deny
allow from all
Options ExecCGI
</Directory>
<Directory /usr/local/nagios/share>
AllowOverride AuthConfig
order allow,deny
allow from all
</Directory>
|
Fra le varie istruzioni qui sopra vi è quella di utilizzare dei file locali per la verifica degli accessi. Quindi è necessario configurare un file di accesso come segue:
# cd /usr/local/nagios/sbin # vi .htaccess |
AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users require valid-user |
Creiamo quindi i permessi per un paio di utenti:
# cd /usr/local/nagios/etc # htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin New password: *** Re-type new password: *** Adding password for user nagiosadmin |
Aggiungete anche il vostro account abituale (negli esempi sarà rudig)
# htpasswd /usr/local/nagios/etc/htpasswd.users rudig New password: Re-type new password: Adding password for user rudig |
Ovviamente va aggiunto il dovuto permesso per ogni amministratore o utente che deve accedere all'interfaccia web di Nagios.
A questo punto si può considerare completata l'installazione e digitando nel browser il percorso http://localhost/nagios/ (se utilizzate il browser in una macchina diversa da quella che contiene Nagios bisognerà ovviamente sostituire a localhost l'indirizzo del server) apparirà una finestra simile a quella che segue:
Chiaramente selezionando le varie voci dei menù si otterranno solo degli errori, ma se si riuscirà a visualizzare questa pagina si potrà passare alla fase di configurazione.
Inizialmente si preparano i file di configurazione partendo dai file di esempio. In seguito ottimizzeremo questa struttura per avere una migliore gestione.
# cd /usr/local/nagios/etc/ # cp nagios.cfg-sample nagios.cfg # cp checkcommands.cfg-sample checkcommands.cfg # cp resource.cfg-sample resource.cfg # cp misccommands.cfg-sample misccommands.cfg # cp cgi.cfg-sample cgi.cfg # cp minimal.cfg-sample minimal.cfg |
Il file di base della configurazione (nagios.cfg) contiene dei riferimenti a dei file esterni che vengono inclusi. Nella configurazione di esempio il file incluso che andremo a modificare è uno solo (minimal.cfg).
Iniziamo quindi a modificare il file minimal.cfg.
All'inizio del file vengono definiti i Time Periods, ovvero le finestre temporali
nelle quali verranno gestiti gli eventi o spedite le notifiche. Il file definisce
solo il periodo "24x7", ovvero tutte le ventiquattro ore di tutti i giorni della
settimana. Per iniziare con il piede giusto consiglio di definire altri due
periodi, uno relativo alle ore lavorative, l'altro relativo alle ore non lavorative.
Se nel vostro caso si tratta di turni di lavoro nelle ventiquattro ore o simili, può essere
utile definirli.
Quindi al termine della definizione del periodo 24x7 aggiungiamo altri due periodi più un periodo per definire un periodo vuoto utile per indicare la non esecuzione di un evento o altre finezze del genere:
# '24x7' timeperiod definition
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
# 'workhours' timeperiod definition
define timeperiod{
timeperiod_name workhours
alias "Normal" Working Hours
monday 08:00-18:00
tuesday 08:00-18:00
wednesday 08:00-18:00
thursday 08:00-18:00
friday 08:00-18:00
}
# 'nonworkhours' timeperiod definition
define timeperiod{
timeperiod_name nonworkhours
alias Non-Working Hours
sunday 00:00-24:00
monday 00:00-08:00,18:00-24:00
tuesday 00:00-08:00,18:00-24:00
wednesday 00:00-08:00,18:00-24:00
thursday 00:00-08:00,18:00-24:00
friday 00:00-08:00,18:00-24:00
saturday 00:00-24:00
}
# 'none' timeperiod definition
define timeperiod{
timeperiod_name none
alias No Time Is A Good Time
}
|
Passiamo ora direttamente alla modifica dei contatti ovvero l'elenco delle persone che verranno contattate ogni volta che viene rilevato un problema. Da notare che Nagios permette di definire dei contatti diversi per ogni macchina, gruppo di macchine, servizio, gruppi di servizi. Nell'esempio che segue inserirò un solo nominativo come contatto. Eliminate quindi i contatti standard inseriti e inserite i vostri riferimenti come da esempio:
# 'rudig' contact definition
define contact{
contact_name rudig #nome dell'account
alias Rudi Giacomini #nome esteso
service_notification_period workhours #si vuole ricevere notifiche
host_notification_period workhours #solo durante l'orario di lavoro
service_notification_options c,r
host_notification_options d,r
service_notification_commands notify-by-email #riceveremo la
host_notification_commands host-notify-by-email #notifica via email
email rudig@localhost
}
|
Come si vede la definizione del precedente periodo temporale "workhours" è già utile in quanto viene impiegato per indicare gli orari nei quali si desidera ricevere la notifica. Per quanto riguarda le voci, service_notification_options e host_notification_options vengono utilizzate per indicare quali stati del sistema sotto controllo si desidera vengano notificati. I valori possibili sono:
u=unreachable (irragiungibile), d= down (spento-assente), r=recoveries (ripristino del servizio), f=flapping (intermittente-instabile), w=warning (avvisi), c=critical (condizione critica-guasto), n=none (nessuna segnalazione).
Modificate anche i gruppi dei contatti inserendo i nominativi aggiunti come da esempio:
define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members rudig
}
|
Nel nostro esempio è sufficiente un gruppo, ma se gestite un'azienda molto ampia con personale molto specializzato potreste definire un gruppo da contattare per i problemi relativi a Linux, un altro gruppo per i database, uno per il gestionale e così via. Potrebbe essere importante anche la definizione di contatti o gruppi di contatti "geograficamente" vicini ai dispositivi da controllare; cosa ancora più vera nel caso di reti distribuite sul territorio.
Un passo ulteriore: cancellate la definizione dei comandi dal file minimal.cfg Cancellate tutta la sezione. I comandi riportati in tale file sono un duplicato di quelli del file checkcommands.cfg che viene giustamente usato dal file nagios.cfg.
Ora la parte più importante, ovvero la definizione di cosa controllare. Seguiamo per un attimo il file di esempio e decidiamo di mettere sotto controllo l'host che esegue Nagios stesso.
Modifichiamo leggermente l' host ed il gruppo di default ottenendo quanto segue:
define host{
use generic-host ;ci basiamo su un template generico predefinito
host_name localhost
alias Nagios Server
address 127.0.0.1 ;indirizzo per il momento usiamo localhost
check_command check-host-alive ; tipo di test da eseguire
max_check_attempts 10 ;tentativi massimi
notification_interval 120
notification_period 24x7
notification_options d,r
contact_groups admins
}
# We only have one host in our simple config file, so there is no need to
# create more than one hostgroup.
define hostgroup{
hostgroup_name test
alias Primo test
members localhost
}
|
Per quanto riguarda i servizi sotto test manteniamo inalterato quanto proposto nei file di esempio.
Ultimo sforzo: sistemiamo i permessi per l'interfaccia grafica editando il file
cgi.cfg: individuate tutte le righe che iniziano con authorized_for_,rimuovete il
commento e inserite alla fine il nome che avete definito quando avete configurato
gli accessi alla sezione web.
La riga di esempio dovrebbe chiarire più di mille parole:
authorized_for_system_information=admin,nagios,rudig |
Dopo aver preparato la configurazione Nagios mette a disposizione un comando per verificarla:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg |
E` possibile preparare uno script per semplificare il test, sia per evitare di digitare ogni volta tutta la sintassi sia perché il comando e il file da testare saranno sempre gli stessi in quanto, partendo dal file nagios.cfg, il comando è in grado di testare tutti i file dipendenti inclusi a partire da questo. Quindi con
# vi /usr/bin/chechnagios |
inserendo le righe seguenti
#!/bin/sh /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg |
e poi settando il file come eseguibile
# chmod +x /usr/local/bin/chechnagios |
si può eseguire il comando. Sarà ora possibile testare il file di configurazione:
# checknagios
Nagios 2.0b4
Copyright (c) 1999-2005 Ethan Galstad (http://www.nagios.org)
Last Modified: 08-02-2005
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 5 services.
Checking hosts...
Checked 1 hosts.
Checking host groups...
Checked 1 host groups.
Checking service groups...
Checked 0 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 22 commands.
Checking time periods...
Checked 4 time periods.
Checking extended host info definitions...
Checked 1 extended host info definitions.
Checking extended service info definitions...
Checked 0 extended service info definitions.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
|
Come si vede va tutto bene e possiamo verificare il sistema facendo partire il demone di controllo:
# service nagios start |
Riaprendo il browser possiamo finalmente ammirare il risultato controllando i servizi:
Come si vede dall'immagine nella configurazione di default c'è un errore nella definizione di un servizio e viene segnalato un problema.
Poiché si voleva solo eseguire un test del sistema è possibile ignorare l'errore relativo al comando check_procs e passare a qualcosa di più pratico.
Passiamo ad un esempio un po' più serio e supponiamo di dover controllare un server che ospita un servizio web con un database MySQL e un mail server. Supponiamo che il server Nagios abbia indirizzo 192.168.1.22 e il web server 192.168.1.8 e che i due host si trovino sulla stessa rete locale.
Per iniziare a migliorare la gestione manteniamo il file minimal.cfg che conterrà, invariate, le definizione dei periodi temporali, dei contatti e dei gruppi di contatti. Separiamo le definizione degli hosts e dei servizi in due file aggiuntivi. Modifichiamo quindi per primo nagios.cfg rimuovendo il commento dalle righe relative a hosts e services:
#cfg_file=/usr/local/nagios/etc/hostgroups.cfg cfg_file=/usr/local/nagios/etc/hosts.cfg cfg_file=/usr/local/nagios/etc/services.cfg #cfg_file=/usr/local/nagios/etc/timeperiods.cfg |
Rimuoviamo da minimal.cfg qualsiasi riferimento a host e servizi e andiamo a preparare hosts.cfg.
Prima di inserire le configurazioni degli host e dei servizi chiariamo un
concetto sul modello di definizione usato da Nagios: esso permette l'uso dei
template (modelli) per le definizione di host e servizi. Si possono cioè inserire
delle descrizioni generiche con già preconfigurati tutti i parametri standard.
Nella definizione del singolo host o servizio si può indicare di utilizzare il
modello e poi aggiungere solo i parametri mancanti o quelli che variano rispetto
al modello.
Fra l'altro è permesso l'uso di modelli in cascata, come andremo a descrivere di seguito.
Creiamo il file hosts.cfg e inseriamo il template generico di host già presente nel file minimal.cfg.
################################################################################
# HOST DEFINITIONS
################################################################################
# Generic host definition template
define host{
name generic-host ; il nome di questo template
notifications_enabled 1 ; Notifiche abilitate
event_handler_enabled 1 ; Eventi abilitati
flap_detection_enabled 1 ; Rilevamento stati indefiniti abilitato
process_perf_data 1 ; Analisi performance abilitata
retain_status_information 1 ; Mantenimento stato d'errore
retain_nonstatus_information 1 ; Mantenimento informazioni aggiuntive
register 0 ; NON VA` REGISTRATO NON E` UN HOST REALE.
}
|
Da questo ereditiamo subito un modello più dettagliato:
# Template più dettagliato
define host{
use generic-host ; Eredita il template precedente
name my_host
check_command check-host-alive ;Test di default
max_check_attempts 10 ;Massimo num. tentativi
notification_interval 120 ;Intervallo di notifica
notification_period 24x7 ;Riferimento al periodo
notification_options d,r ; Eventi da notificare
contact_groups admins ;Gruppo da contattare
register 0 ; NON VA` REGISTRATO NON E` UN HOST REALE.
}
|
Definiamo ora il server da controllare:
# 'web_server' definizione
define host{
use my_host ; Eredita i modelli
host_name web_server ;nome del server
alias Linux Web & Mail
address 192.168.1.8 ;indirizzo
}
#informazioni aggiuntive
define hostextinfo {
host_name web_server
icon_image linux.png
icon_image_alt Linux Host
vrml_image linux.png
statusmap_image linux.gd2
}
|
Nelle informazioni aggiuntive sono stati inseriti solo i riferimenti alle icone da usare.
E ora il gruppo (anche se per ora abbiamo un solo host):
################################################################################
# HOST GROUP DEFINITIONS
################################################################################
# 'linux-boxes' host group
define hostgroup{
hostgroup_name linux-boxes
alias Linux Servers
members web_server
}
|
Passiamo quindi alla definizione dei servizi nel file services.cfg:
################################################################################
# SERVICE DEFINITIONS
################################################################################
# template per un servizio generico
define service{
name generic-service ; Nome del template
active_checks_enabled 1 ; Controllo di tipo attivo abil.
passive_checks_enabled 1 ; Controllo passivo abilitato
parallelize_check 1 ; Attiva controlli in parallelo
obsess_over_service 1 ;Se necessario mantiene il monitoraggio
check_freshness 0 ; Non controlla se il dato è fresco
notifications_enabled 1 ; Notifiche abilitate
event_handler_enabled 1 ; Abilita la gestione del servizio
flap_detection_enabled 1 ; Abilita su stato instabile
process_perf_data 1 ; Abilita controllo performances
retain_status_information 1 ; Mantiene le informazioni su riavvio
retain_nonstatus_information 1
register 0 ; NON REGISTRA IL SERVIZIO (TEMPLATE)
}
# Test del mail server
define service{
use generic-service ; Usa il template precedente
host_name web_server ;nome server
service_description SMTP ;nome servizio
is_volatile 0 ;non è volatile
check_period 24x7 ;periodo usato per i test
max_check_attempts 3 ;massimo numero di tentativi
normal_check_interval 3 ;intervallo fra i test
retry_check_interval 1 ;intervallo in caso di errore
contact_groups admins ;contatti
notification_interval 120 ;intervallo fra le notifiche
notification_period 24x7 ;periodo di notifica
notification_options w,u,c,r ;errori notificati
check_command check_smtp ;comando usato per i test
}
# Test del web server
define service{
use generic-service ; Usa il template precedente
host_name web_server ;nome server
service_description HTTP ;nome servizio
is_volatile 0 ;non è volatile
check_period 24x7 ;periodo usato per i test
max_check_attempts 3 ;massimo numero di tentativi
normal_check_interval 3 ;intervallo fra i test
retry_check_interval 1 ;intervallo in caso di errore
contact_groups admins ;contatti
notification_interval 120 ;intervallo fra le notifiche
notification_period 24x7 ;periodo di notifica
notification_options w,u,c,r ;errori notificati *
check_command check_http
}
|
*Per quel che riguarda gli errori notificati le opzioni sono: w=warning (avvisi), c=critical (errori critici), u=unknown (sconosciuto) e r=recoveries (riavvio) f=flapping(instabile) n=none (nessuna segnalazione).
Abbiamo definito due dei tre servizi che ci eravamo prefissati di controllare. In
caso di errore di un servizio verrà inviata una notifica al gruppo indicato.
Testiamo la nuova configurazione con il comando
# checknagios
Nagios 2.0b4
Copyright (c) 1999-2005 Ethan Galstad (http://www.nagios.org)
Last Modified: 08-02-2005
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 2 services.
Checking hosts...
Checked 1 hosts.
Checking host groups...
Checked 1 host groups.
Checking service groups...
Checked 0 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 22 commands.
Checking time periods...
Checked 4 time periods.
Checking extended host info definitions...
Checked 1 extended host info definitions.
Checking extended service info definitions...
Checked 0 extended service info definitions.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
|
La verifica ci conferma che abbiamo definito un host e due servizi, per cui facciamo ripartire Nagios
# service nagios restart |
e apriamo l'interfaccia web per verificare:
Non male come primo risultato, ma dobbiamo ancora testare il database.
Per il test del database MySQL dobbiamo modificare i comandi standard aggiungendo
un comando ad-hoc. Nella directory /usr/local/nagios/libexec troviamo il comando
check_mysql: eseguendolo col l'opzione - help otteniamo
# ./check_mysql --help
check_mysql (nagios-plugins 1.4.2) 1.26
Copyright (c) 1999-2004 Nagios Plugin Development Team
|
Notate che viene chiaramente indicato che la password utilizzata sarà visibile in chiaro per cui non utilizzate questo test in un ambiente a rischio. Modifichiamo, quindi, il file checkcommands.cfg aggiungendo banalmente
# 'check_mysql' command definition
define command{
command_name check_mysql
command_line $USER1$/check_mysql -d my_db -H 192.168.1.4 -u rudig -p testpass
}
|
e poi il file services.cfg aggiungendo
# Test del database
define service{
use generic-service ; Usa il template precedente
host_name web_server ;nome server
service_description MYSQL ;nome servizio
is_volatile 0 ;non è volatile
check_period 24x7 ;periodo usato per i test
max_check_attempts 3 ;massimo numero di tentativi
normal_check_interval 3 ;intervallo fra i test
retry_check_interval 1 ;intervallo in caso di errore
contact_groups admins ;contatti
notification_interval 120 ;intervallo fra le notifiche
notification_period 24x7 ;periodo di notifica
notification_options w,u,c,r ;errori notificati
check_command check_mysql
}
|
Dopo il solito riavvio otterremo il risultato voluto.
Chiudo qui questo primo articolo, dopo avere fornito gli elementi di base per iniziare ad operare con Nagios.
Mi rendo conto che molti di voi avrebbero potuto trovare molte di queste informazioni nel manuale del programma, ma la loro esposizione è stata necessaria per capire quanto verrà esposto nel prossimo articolo, nel quale vedremo ulteriori esempi di utilizzo del programma ricavati da casi reali.
L'autore |
|
|
<- Grazie Claudio! - Indice Generale - Copertina - Piccoli server web -> |
|