In Debian Lenny è entrata la versione 3 di Nagios. Si installa il pacchetto nagios3 e possibilmente anche nagios-plugins-standard che portano dietro un sacco di dipendenze, tra cui notiamo:
Dopo l'installazione c'è in esecuzione il demone nagios3 che logga in /var/log/nagios3/nagios.log
, il log dell'acquisizione dati vengono messi in /var/log/nagios3/archives/
.
Per attivare l'interfaccia web bisogna includere nella configurazione di Apache il file /etc/nagios3/apache2.conf
. L'accesso all'interfaccia web è protetto da autenticazione htpasswd, si devono aggiungere al file /etc/nagios3/htpasswd.users
gli utenti, tra cui l'amministratore di nome nagiosadmin.
È possibile dare accesso ristretto solo ad alcuni host ad un utente, vedere questa pagina, oppure:
/etc/nagios3/conf.d/contacts_nagios2.cfg
.contacts
oppure contact_groups
.contact_name
con l'opportuna password al file /etc/nagios3/htpasswd.users
./etc/nagios3/cgi.cfg
ci sia use_authentication=1
.
L'accesso si ottiene puntando il browser all'url http://host/nagios3/
.
Per il monitoraggio di host remoti conviene installare NRPE. Si tratta di un protocollo client-server sviluppato apposta per Nagios, che si occupa di trasportare le richieste da Nagios verso i plugin remoti. Il server Nagios in questo caso si comporta da client NRPE, il pacchetto di cui ha bisogno è:
ATTENZIONE: il resto di questi appunti sono basati su Nagios 2, ci potrebbero essere delle incongruenze con la nuova versione.
Se si desidera monitorare una caratteristica su un host remoto (di nome Everest, in questo esempio) si deve installare almeno il pacchetto Debian nagios-nrpe-server, vari plugin di monitoraggio sono invece inclusi nel pacchetto nagios-plugins-basic. Il server risponde al sistema NRPE (nagios remote plugin execute) ed ascolta sulla porta TCP 5666. I client accettati (un minimo di controllo di accesso) sono indicati in /etc/nagios/nrpe.cfg
.
Per verificare la connettività dall'host Nagios verso il server NRPE:
# /usr/lib/nagios/plugins/check_nrpe -H everest.texnet.it NRPE v2.5.1
NOTA: Il plugin check_swraid
qui descritto non è incluso in Debian ed ha il difetto di non gestire correttamente la situazione di check e resync degli array, segnalando inutilmente un allarme. Si consiglia pertanto di usare il plugin check_linux_raid
fornito dal pacchetto Debian Sqeeze nagios-plugins-standard. Gli appunti che seguno sono pertanto da considerarsi obsoleti e utili solo come riferimento.
NOTA2: Il plugin check_linux_raid
è cambiato in Debian Wheezy: viene fornito dal pacchetto nagios-plugins-contrib, ma si chiama check_raid
perché è in grado di monitorare lo stato di salute di diversi tipi di RAID.
Si installa il plugin check_raid che controlla lo stato di salute del RAID software Linux. Non esiste un plugin adatto nel pacchetto basic, si scarica e si installa lo script Python check_swraid. Lo script va messo nella directory /usr/local/lib/nagios/plugins/
, salvandolo con nome check_swraid
.
Si definisce il nuovo comando nagios aggiungendo una riga a /etc/nagios/nrpe_local.cfg
:
command[check_swraid]=/usr/local/lib/nagios/plugins/check_swraid
Bisogna quindi fare un reload di nagios-nrpe-server
. Per verificare che l'host Nagios possa interrogare il plugin remoto:
# /usr/lib/nagios/plugins/check_nrpe -H everest.texnet.it -c check_swraid All md devices ( md10 md3 md2 md1 md0 ) Ok.
Il plugin check_disk
fa parte del pacchetto nagios-plugins-basic. Sull'host si configura la sonda aggiungendo una riga a /etc/nagios/nrpe_local.cfg
:
command[check_disk]=/usr/lib/nagios/plugins/check_disk --warning=20% --critical=10% \ --iwarning=20% --icritical=10% --units=GB --mountpoint --path=/opt1
Sull'host che ospita Nagios (il demone e le pagine web) si installano i pacchetti Debian:
Per aggiungere al monitoraggio il servizio “Check RAID” sull'host Everest si interviene su alcuni file di configurazione:
Contiene la configurazione generale del programma: dove cercare gli altri file di configurazione, dove scrivere i file di log, ecc. Dovrebbe essere stato configurato automaticamente durante l'installazione del pacchetto Debian. In particolare Debian indica le directory /etc/nagios3/conf.d/
e /etc/nagios-plugins/config
e il file /etc/nagios3/commands.cfg
.
Anzitutto si aggiunge la definizione dell'host Everest. Si crea il file apposito e si indicano solo i parametri indispensabili, tutto il resto viene ereditato dal template generic-host:
define host { use generic-host host_name Everest alias everest.texnet.it address 217.19.150.4 }
Quindi si definiscono i servizi, un servizio per Nagios è genericamente una caratteristica da monitorare. Poiché sono servizi generici usati su più host, si definiscono collettivamente in questo file messo a disposizione dal pacchetto Debian. Per lo stesso motivo invece di indicare il nome dell'host su cui sono attivi (host_name
) si indica un gruppo di host (hostgroup_name
).
Nella definizione dei servizi si indica lo script da eseguire sull'host remoto tramite il plugin check_nrpe_1arg. Rispetto al template generic-service si è ridefinito solo il normal_check_interval (in minuti):
# Check software RAID via NRPE define service { hostgroup_name nrpe-swraid service_description Check RAID check_command check_nrpe_1arg!check_swraid use generic-service normal_check_interval 120 } # Check disk space via NRPE define service { hostgroup_name nrpe-memory service_description Disk free check_command check_nrpe_1arg!check_disk use generic-service normal_check_interval 120 }
Il plugin check_nrpe_1arg esegue l'interrogazione via NRPE con un solo argomento: il nome dello script da eseguire sull'host remoto. In generale è una cattiva idea passare altri argomenti al server NRPE e infatti la configurazione predefinita non li considera (dont_blame_nrpe=0
).
In questo file si dichiarano due gruppi di host (nrpe-swraid e nrpe-disk) che saranno interessati al servizio dichiarato in precedenza. A questi gruppi appartiene l'host Everest:
define hostgroup { hostgroup_name nrpe-swraid alias Check software RAID via NRPE members Everest } define hostgroup { hostgroup_name nrpe-disk alias Check disk free space via NRPE members Everest }
L'installazione Nagios3 di Debian prevede che le notifiche via mail siano spedite all'utente root, bisogna che tali messaggio siano correttamente indirizzati eventualmente con un alias in /etc/aliases
.
I contatti per le notifiche sono configurati in /etc/nagios3/conf.d/contacts_nagios2.cfg
.
Un'impostazione frequente è che tutti gli allarmi di un host vadano ad un determinato contatto, l'impostazione predefinita di Nagios in Debian invece prevede che un singolo contatto riceva tutti gli allarmi per un determinato servizio (anche su host diversi). La ricetta che segue serve a risolvere il problema.
Le mail di notifica sono inviate ai destinatari indicati dalle direttive contacts
oppure contact_groups
e sono relative a problemi dell'host (contatti definiti nella sezione define host
) oppure del servizio (contatti definiti nella sezione define service
).
Il servizio eredita i contatti dall'host solo se non li definisce in proprio. Per questo conviene che le definizioni di service
e il template generic-service
non definiscano alcun contatto, in modo che siano ereditate le impostazioni dell'host.
In questo modo la definizione dell'host assume il seguente aspetto:
define host { use generic-host host_name Thassos alias thassos.rigacci.org address 78.47.114.234 contact_groups customer_admins }
Il template generic-host
definisce i contatti generici, la direttiva contact_groups
li sovrascrive con quelli specifici per l'host.
Questa è la definizione dei contatti specifici:
define contact{ contact_name n.rigacci alias Niccolo Rigacci service_notification_period 24x7 host_notification_period 24x7 # (w)arning, (u)nknown, (c)ritical, (r)ecoveries, (f)lapping, (n)one. service_notification_options w,u,c,r # (d)own, (u)nreachable, (r)ecoveries, (f)lapping, (s)cheduled downtime, (n)one. host_notification_options d,u,r,f service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email email niccolo@rigacci.org } define contactgroup{ contactgroup_name customer_admins alias Custom Administrators members n.rigacci }
Con questa configurazione il server Nagios esegue il plugin check_clamd
via NRPE. Con tale accorgimento la configurazione è identica sia che il demone clamd
sia in esecuzione sull'host Nagios, sia che si tratti di un host remoto.
L'host su cui gira clamd
deve autorizzare l'interrogazione via NRPE, quindi in /etc/nagios/nrpe.cfg
si deve aggiungere l'indirizzo da cui proviene l'interrogazione agli allowed_hosts
(elenco separato da virgole).
Poi si definisce un comando NRPE, di nome check_clamd, in /etc/nagios/nrpe_local.cfg
:
command[check_clamd]=/usr/lib/nagios/plugins/check_clamd -H /var/run/clamav/clamd.ctl
Il plugin check_clamd
viene fornito dal pacchetto Debian nagios-plugins-basic
, in questo caso interroghiamo clamd
via Unix socket (per vedere altri parametri supportati dal plugin, eseguirlo con --help
).
Sul server Nagios3 si definisce il servizio clamd-servers, in /etc/nagios3/conf.d/services_nagios2.cfg
:
# check that ClamAV service is running, via NRPE define service { hostgroup_name clamd-servers service_description CLAMD check_command check_nrpe_1arg_long!check_clamd use generic-service notification_interval 180 ; renotify every 3 hours }
Infine si definisce la lista degli host su cui monitorare tale servizio, in /etc/nagios3/conf.d/hostgroups_nagios2.cfg
:
# A list of your ClamAV servers define hostgroup { hostgroup_name clamd-servers alias Clamd servers members localhost }
Dopo aver cambiato i file di configurazione riavviare i servizi nagios3 e nagios-nrpe-server sui rispettivi host.
L'interrogazione via NRPE viene eseguita dal plugin check_nrpe
tramite il comando check_nrpe_1arg
, definito in /etc/nagios-plugins/config/check_nrpe.cfg
:
# this command runs a program $ARG1$ with no arguments define command { command_name check_nrpe_1arg command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }
In tal modo non è possibile passare (via NRPE) ulteriori parametri al plugin check_clamd
. Conviene infatti che i parametri siano contenuti nella definizione del comando NRPE (locale al server su cui viene eseguito il plugin) definito in /etc/nagios/nrpe_local.cfg
. Nell'esempio sopra viene passato solo il nome del socket.
Nagios si integra facilmente con il sistema SNMP. E' possibile monitorare apparati che offrono solo SNMP oppure installare sull'host da monitorare il server NRPE e con questo interrogare localmente il demone SNMP.
Installando il plugin check_snmp sull'host che deve essere monitorato è possibile leggere i parametri SNMP tramite Nagios. Il plugin si trova nel pacchetto Debian nagios-plugins-standard, va installato insieme al demone SNMP. In pratica la richiesta del dato avviene seguendo questa catena:
Server Nagios → protocollo NRPE → host monitorato → check_snmp → protocollo SNMP → snmpd
Per configurare il gateway NRPE → SNMP sull'host monitorato si deve aggiungere una riga al file /etc/nagios/nrpe_local.cfg
:
command[check_memory]=/usr/lib/nagios/plugins/check_snmp -H 127.0.0.1 -C Tex.NET -o UCD-SNMP-MIB::memAvailReal.0 \ -w 50000: -c 20000: \ --label="SNMP memAvailReal.0" --units=kb
Eseguire check_snmp -help
per i dettagli sui parametri.
Il server Nagios effettua l'interrogazione via NRPE, verificare con:
/usr/lib/nagios/plugins/check_nrpe -H router.texnet.it -c check_memory
Il plugin check_snmp (dal pacchetto nagios-plugins-standard
) viene eseguito sul server Nagios e l'interrogazione dell'host da monitorare avviene via SNMP.
La configurazione predefinita rende disponibili diversi comandi Nagios che corrispondono a diverse grandezze SNMP monitorabili. Vedere tutti i define command
contenuti in /etc/nagios-plugins/config/snmp.cfg
.
Non esiste il sensore per misurare la percentuale di utilizzo della CPU, è possibile definirlo nel modo che segue.
Inziamo definendo il comando Nagios di nome snmp_cpu_usage, basato sul generico plugin check_snmp. Si crea il file /etc/nagios-plugins/config/local.cfg
con dentro:
define command { command_name snmp_cpu_usage command_line /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' \ -o .1.3.6.1.4.1.2021.11.9.0,.1.3.6.1.4.1.2021.11.10.0,.1.3.6.1.4.1.2021.11.11.0 \ -l 'CPU User System Idle:' -u '%,%,%' -D ', ' -w '0:50,0:20,60:100' -c '0:60,0:30,40:100' }
Il comando (grazie ai parametri $HOSTADDRESS$
e $ARG1$
) riceverà l'indirizzo dell'host remoto da interrogare e il nome della community SNMP. Le grandezze SNMP che interessano sono tre e sono state specificate con l'OID numerico, i corrispondenti valori simbolici sono:
UCD-SNMP-MIB::ssCpuUser.0
UCD-SNMP-MIB::ssCpuSystem.0
UCD-SNMP-MIB::ssCpuIdle.0
Una alternativa meno efficace è utilizzare i MIBs UCD-SNMP-MIB::ssCpuRaw*
, questi sensori restituiscono degli interi crescenti che hanno un significato come differenza rispetto alla lettura precedente.
Questa è la definizione del comando snmp_cpu_load:
# 'snmp_cpu_load' command definition define command { command_name snmp_cpu_load command_line /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C $ARG1$ \ -m UCD-SNMP-MIB \ -o ssCpuRawUser.0,ssCpuRawNice.0,ssCpuRawSystem.0 \ -w :,:,: -c :,:,: -l "CPU load" }
La percentuale di utilizzo CPU è data dalla somma di ssCpuRawUser.0, ssCpuRawNice.0 e ssCpuRawSystem.0, questi però sono valori raw (semplici contatori), per ottenere la percentuale bisogna fare la differenza tra due letture successive e dividere per il tempo trascorso.
Per mantenere la semplicità del plugin check_snmp
, l'aggregazione dei dati (calcolo della percentuale) verrà fatta solo quando i performance data vengono salvati nell'archivio RRD (vedi più avanti le note su Nagiostat). Unico inconveniente è che sui contatori non possiamo stabilire un warning range e un critical range, pertanto questa sonda Nagios restituisce sempre un valore STATE_OK e serve solo per generare il grafico sui performance data.
Per definire in Nagios il servizio che utilizza il comando definito sopra, ecco un estratto del file /etc/nagios3/conf.d/services_nagios2.cfg
:
define service { hostgroup_name snmp-cpu-usage service_description SNMP CPU usage check_command snmp_cpu_usage!secret use generic-service notification_interval 720 ; set > 0 if you want to be renotified first_notification_delay 240 ; notify after 4 hours of problem }
Problema: il plugin check_ide_smart
che controlla lo stato S.M.A.R.T. di un disco deve essere eseguito con permessi di root sulla macchina locale. Noi invece eseguiamo il comando da remoto tramite nagios-nrpe-server
che gira con l'utente nagios.
Anzitutto si abilita il server NRPE ad eseguire il comando tramite sudo, in /etc/nagios/nrpe_local.cfg
aggiungiamo:
command[check_smart_sda]=/usr/bin/sudo /usr/lib/nagios/plugins/check_ide_smart -n -d /dev/sda
È buona norma non passare argomenti tramite NRPE, quindi si definisce un comando differente per ogni disco da monitorare (check_smart_sda, check_smart_sdb, ecc.).
Quindi si abilita l'utente nagios ad eseguire il comando sudo, senza neanche il bisogno che abbia una shell valida. Basta installare sudo e creare il file /etc/sudoers.d/check_ide_smart
:
# Cmnd alias specification Cmnd_Alias NAGIOS_UTIL = /usr/lib/nagios/plugins/check_ide_smart # User Host = (Runas) [NOPASSWD:] Cmnd nagios ALL = (root) NOPASSWD: NAGIOS_UTIL
Per testare il corretto funzionamento, da remoto si esegue:
/usr/lib/nagios/plugins/check_nrpe -H 192.168.9.8 -c check_smart_sda OK - Operational (25/25 tests passed)
Nel pacchetto nagios-plugins-standard esiste lo script /usr/lib/nagios/plugins/check_mysql
utilizzabile via NRPE per monitorare lo stato di salute del servizio MySQL. Se esite l'utente anonimo MySQL (cioé ''@''localhost'', senza password) non è necessario indicare un nome utente e il test predefinito funziona. In altre condizioni è necessario fare alcuni preparativi.
Creare un utente database:
CREATE USER 'nagios'@'localhost' IDENTIFIED BY 'MySecret'; FLUSH PRIVILEGES;
quindi definire il comando da eseguire via NRPE in /etc/nagios/nrpe_local.cfg
:
command[check_mysql]=/usr/lib/nagios/plugins/check_mysql --username=nagios --password=MySecret
Ovviamente il file in questo modo contiene delle credenziali sensibili, è opportuno proteggerlo con:
chown root:nagios /etc/nagios/nrpe_local.cfg chmod 640 /etc/nagios/nrpe_local.cfg
In generale un singolo servizio viene erogato da molti server, quindi nel file services_nagios2.cfg
il servizio viene associato ad un hostgroup_name
:
define service { hostgroup_name http-servers service_description HTTP check_command check_http use generic-service }
Se invece si ha bisogno di una configurazione diversa per ogni host conviene creare un file specifico (ad esempio wget_services.cfg
) e ad ogni servizio assegnare un solo host_name
:
define service { host_name Hostname1 service_description WGET use generic-service check_command check_http_get!80!http://www.hostname1.com/dokuwiki/ } define service { host_name Hostname2 service_description WGET use generic-service check_command check_http_get!80!http://www.hostname2.com/drupal/ }
Si vuole dare accesso come utente non amministratore all'interfaccia di Nagios. L'autenticazione è comunque fortemente consigliata per evitare abusi del servizio.
Il nome utente scelto (guest) non deve essere uguale ad uno de contact di Nagios, infatti i contatti autenticati hanno accesso a tutte le informazioni relative ai servizi e host per i quali sono un contatto. Noi invece creiamo un semplice utente autenticato, che non corrisponde ad alcun contatto.
Aggiungiamo l'utente all'autenticazione HTTP:
htpasswd /etc/nagios3/htpasswd.users guest
Poi nel file /etc/nagios3/cgi.cfg
aggiungiamo l'utente almeno a due direttive:
authorized_for_all_services=nagiosadmin,guest authorized_for_all_hosts=nagiosadmin,guest
È possibile indicare come link la sola pagina di Service detail, passando eventualmente anche login e password (visibile in chiaro!) sull'URL:
http://guest:guest@nagios.host.it/cgi-bin/nagios3/status.cgi
Per concedere altri diritti all'utente consultare la pagina Authentication And Authorization In The CGIs.
Quando Nagios è in esecuzione può ricevere dei comandi sulla pipe /var/lib/nagios3/rw/nagios.cmd
, ma questa esiste solo se sono attivi gli external commands. Per questo verificare che in /etc/nagios3/nagios.cfg
ci siano almeno queste impostazioni:
check_external_commands=1 command_check_interval=10
Anche l'interfaccia web utilizza la pipe per comandare Nagios (ad esempio per disabilitare le notifiche). L'impostazione predefinita Debian tuttavia non imposta i privilegi sufficienti, ecco la ricetta per abilitare l'interfaccia web ai comandi esterni (da /usr/share/doc/nagios3/README.Debian
):
/etc/init.d/nagios3 stop dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3 /etc/init.d/nagios3 start
Si vuole monitorare e segnalare quando è disponibile un aggiornamento di pacchetti su un host Debian.
Sull'host da monitorare si installa il pacchetto nagios-plugins-basic che fornisce lo script /usr/lib/nagios/plugins/check_apt
. Nel file /etc/nagios/nrpe_local.cfg
si aggiunge il comando che verrà invocato via NRPE:
command[check_upgrade]=/usr/lib/nagios/plugins/check_apt
Il plugin viene eseguito con l'utente nagios, quindi non è in grado di fare né l'update né l'upgrade (e va bene così!). Pertanto è necessario creare un cronjob che effettui l'upgrade con la frequenza necessaria, ad esempio /etc/cron.d/check_upgrade
:
MAILTO="" # An apt-get update is required by the Nagios check_upgrade plugin. 31 11 * * * root /usr/bin/apt-get update
Quindi sul server Nagios si definisce il servizio e il gruppo:
define service { hostgroup_name apt-upgrade service_description APT Upgrade check_command check_nrpe_1arg!check_upgrade use generic-service notification_interval 720 ; set > 0 if you want to be renotified }
# Debian hosts, where to run APT upgrade check define hostgroup { hostgroup_name apt-upgrade alias APT Upgrade members Thassos members Naxos }
Nagios effettua la rotazione dei log autonomamente, senza aver bisogno di logrotate o simili. Il file di log /var/log/nagios3/nagios.log
viene ruotato e copiato nella directory /var/log/nagios3/archives/
. I file non devono essere compressi, altrimenti Nagios non è in grado di mostrare il trend o altri valori storici.
Con openSUSE 12.1 viene fornito erroneamente uno script che effettua la compressione dei log (vedere questo post), per disabilitarla impostare in /etc/sysconfig/nagios
:
NAGIOS_COMPRESS_LOGFILES="false"
Questa pare la soluzione ottimale, il pacchetto pnp4nagios è anche incluso in Debian.
Ci sono varie modalità di raccogliere i performance data di Nagios e produrre i grafici relativi. In Debian Wheezy il metodo consigliato è bulk mode with NPCD and npcdmod (vedi /usr/share/doc/pnp4nagios/README.Debian
).
Vediamo ad esempio come attivare i grafici di latenza del ping.
Attivare il demone in /etc/default/npcd
, quindi abilitare la raccolta dei dati e il modulo pnp4nagios in /etc/nagios3/nagios.cfg
:
process_performance_data=1 broker_module=/usr/lib/pnp4nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg
Il tipo di servizio si configura in questo modo:
define service { hostgroup_name ping-servers service_description Ping check_command check_ping!1000.0,20%!2000.0,60% use generic-service }
conviene poi definire un tipo di host sul quale si vogliono i grafici:
define host { name graph-host process_perf_data 1 action_url /pnp4nagios/graph?host=$HOSTNAME$ use generic-host }
infine si definisce l'host con tutte le caratteristiche necessarie:
define host { host_name MyHost address 192.168.1.146 use graph-host } define hostgroup { hostgroup_name ping-servers members MyHost }
Esistono almeno tre progetti per aggiungere grafici a Nagios, purtroppo nessuno pacchettizzato Debian:
Sebbene Nagiosgraph sia più recente e NagiosGrapher pare sia meglio integrato con Nagios, qui si prova NagioStat.
ATTENZIONE: NagioStat ha dei problemi gravi di affidabilità: lo stesso script cgi-bin viene utilizzato sia per il salvataggio dei dati negli RRD sia per la consultazione dei grafici via browser. La configurazione è mantenuta nell'unico file nagiostat.conf. Il parsing del file di configurazione è fragile: se si introduce un errore nel file di configurazione si compromette in un colpo solo la visualizzazione dei grafici e la memorizzazione di tutti i performance data. Ad esempio una riga di commento terminante con un backslash oppure con delle virgolette non bilanciate causa il blocco del programma.
In teoria ci sarebbe l'opzione nagiostat -t
per testare la validità del file di configurazione, peccato che l'exit code del programma sia sempre zero, anche in caso di errori.
Scompattare l'archivio nagiostat-1.0.0.tgz
in /usr/lib/cgi-bin/nagiostat/
, assegnare i permessi opportuni.
Predisporre la directory /var/lib/nagiostat
dove salvare i dati RRD:
mkdir /var/lib/nagiostat mkdir /var/lib/nagiostat/archives chown nagios:nagios /var/lib/nagiostat/archives chmo 755 /var/lib/nagiostat/archives
Configurare NagioStat in modo che utilizzi tale directory: in nagiostat.conf
mettere
RRDArchivePath /var/lib/nagiostat/archives
Predisporre la directory /var/log/nagiostat/
per salvare il debug, assegnare i permessi opportuni e creare un link simbolico:
mkdir /var/log/nagiostat touch /var/log/nagiostat/debug.log chown -R nagios:adm /var/log/nagiostat chmod 2750 /var/log/nagiostat chmod 640 /var/log/nagiostat/debug.log ln -s /var/log/nagiostat/debug.log /usr/lib/cgi-bin/nagiostat/debug.log
Configurare anche logrotate per gestire la rotazione dei log con un file /etc/logrotate.d/nagiostat
:
/var/log/nagiostat/debug.log { rotate 7 daily compress delaycompress missingok notifempty create 640 nagios adm }
Modificare l'eseguibile Perl di NagioStat in modo che trovi tutte le sue componenti:
my $BASE_DIR = "/usr/lib/cgi-bin/nagiostat";
Vedere anche questo esempio più complesso per la generazione del grafico del carico della CPU a partire dai valori SNMP.
Per ogni grafico di Nagiostat bisogna configurare alcune sezioni nel file di configurazione nagiostat.conf
:
Dopo aver configurato i primi 3 parametri, NagioStat è in grado di ricevere i dati e salvarli nel database RRD. Al primo inserimento il database viene creato al volo. Per verificare il contenuto di un file RRD si può utilizzare la riga di comando:
rrdtool dump /var/lib/nagiostat/archives/pierargo-load.rrd
Il parametro RRDCreateTemplate indica come inizializzare l'archivio RRD con rrdcreate quando arriveranno i primi dati. Ecco un esempio tipico (ATTENZIONE: il file di configurazione non accetta le andate a capo, mettere tutto sulla stessa riga!):
RRDCreateTemplate ping_5min --step 300 DS:rta:GAUGE:600:0:5000 DS:pktloss:GAUGE:600:0:100 RRA:AVERAGE:0.5:1:396 RRA:AVERAGE:0.5:6:336 RRA:AVERAGE:0.5:24:480 RRA:AVERAGE:0.5:234:480
In questo esempio si dichiara che i dati saranno acquisiti ogni 300 secondi: –step 300.
Le grandezze acquisite sono due (DS, data source), entrambe sono letture di un valore puntuale (GAUGE). Se la lettura fallisce per più di 600 secondi, il dato viene considerato UNKNOWN. Se il dato non rientra nell'intervallo MIN:MAX viene considerato UNKNOWN.
Il consolidamento dei dati nell'archivio round-robin (RRA) verrà fatto sulla media dei dati (AVERAGE) se questi saranno disponibili almeno al 50% (0.5). Il consolidamento ad 1 (cioè il singolo dato originale) mantiene 396 record, il consolidamento a 6 (300 x 6 = 1800; media su 30 min) sarà di 336 record, ecc.
Con InsertValue si indica a Nagiostat come e quando inserire i dati nell'archivio RRD. Ad esempio:
## RRDArchiveFile RRDCreateTemplate HostRegex ServiceRegex ValueRegexTemplate InsertValue argo-ping.rrd ping_5min /^argo$/ /^PING$/ ping_rta_pktloss
Quando arriva un dato (performance data) proveniente dall'host argo per il servizio PING, viene estratto il valore numerico grazie all'espressione regolare ping_rta_pktloss. Quindi il dato viene memorizzato nell'archivio argo-ping.rrd eventualmente creato con il template ping_5min.
Il parametro ValueRegexTemplate indica come estrarre il dato numerico dall'informazione proveniente da Nagios; tramite un'espressione regolare si analizza il PERFDATA oppure l'OUTPUT (vedere il log di Nagiostat per l'esatto contenuto dei due campi). Ecco un esempio su come estrarre i valori relativi al ping (round trip average e packet loss):
ValueRegexTemplate ping_rta_pktloss "output:rta:/RTA = ([0-9.]+) ms/" "output:pktloss:/loss = (\\d+)%/"
Questa riga indica come deve essere invocato rrdgraph
(vedi anche le man di rrdgraph_data
e rrdgraph_graph
) per generare il grafico. Anche in questo esempio ricordarsi di scrivere tutto sulla stessa riga e notare come alcuni caratteri devono essere preceduti da backslash:
PlotTemplate disk_free --start $s --end $e DEF:disk_free=$f:disk_free:AVERAGE LINE1:disk_free#A00000:\"Disk free (bytes?)\"
Nel file principale di configurazione /etc/nagios2/nagios.cfg
si abilita il trattamento dei dati performance e si definisce il service_perfdata_command (comando da eseguire dopo il check di ogni servizio):
process_performance_data=1 service_perfdata_command=service-perf-data-handler
Quindi si definisce il comando service-perf-data-handler nel file /etc/nagios2/commands.cfg
:
define command { command_name service-perf-data-handler command_line /usr/lib/cgi-bin/nagiostat/nagiostat -p \ "$LASTSERVICECHECK$|!!|$HOSTNAME$|!!|$SERVICEDESC$|!!|$SERVICESTATE$|!!|$SERVICEOUTPUT$|!!|$SERVICEPERFDATA$" }
Si può aggiungere alla pagina Service Detail di Nagios un link che rimanda ai grafici di NagioStat. Si utilizza la funzione Extended Host and Service Information. In uno dei file di configurazione (suggerito /etc/nagios2/conf.d/extinfo_nagios2.cfg
) si mette:
define serviceextinfo { host_name everest service_description Disk free notes_url /nagiostat/nagiostat.cgi?graph_name=everest-df }
Purtroppo l'icona non è personalizzabile, viene utilizzata notes.gif dalla directory /usr/share/nagios2/htdocs/images/
.