In Debian Lenny è entrata la versione 3 di Nagios. Si installa il pacchetto nagios3 e possibilmente anchenagios-plugins-standard che portano dietro un sacco di dipendenze, tra cui notiamo:

• nagios3-common
• nagios-plugins-basic
• nagios3-doc
• iputils-ping
• procps
• fping
• libmysqlclient15off
• libnet-snmp-perl
• libradiusclient-ng2
• radiusclient1
• smbclient
• snmp

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

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 è:

• nagios-nrpe-plugin

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

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:

• nagios2
• nagios-nrpe-plugin
• nagios-plugins-basic
• nagios-plugins-standard

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

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 idefine command contenuti in /etc/nagios-plugins/config/snmp.cfg.

Non esiste però il sensore per misurare la percentuale di utilizzo CPU. Inziamo definendo il comando Nagios di nome snmp_cpu_load, basato sul generico plugin check_snmp. Si crea il file /etc/nagios-plugins/config/local.cfg con dentro:

# '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"
}

Il comando (grazie alle macro $HOSTADDRESS$ e $ARG1$) farà riferimento all’indirizzo dell’host remoto ed accetterà come parametro il nome dellacommunity SNMP. Le grandezze SNMP che interessano sono tre e sono state specificate con il nome OID che hanno nel MIB UCD-SNMP-MIB. In alternativa si può utilizzare l’OID numerico.

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.

Infine si definisce il nuovo servizio in Nagios, indicando il parametro da passare al comando snmp_cpu_load (separato dal punto esclamativo):

define service {
    host_name               pierargo
    service_description     CPU load
    check_command           snmp_cpu_load!community_name
    use                     generic-service
}

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 gliexternal 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

Esistono almeno tre progetti per aggiungere grafici a Nagios, purtroppo nessuno pacchettizzato Debian:

• Nagiostat
• Nagiosgraph
• NagiosGrapher

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 ilblocco 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:

1. RRDCreateTemplate
2. InsertValue
3. ValueRegexTemplate
4. PlotTemplate
5. Graph

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 ilservice_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/.

Direttamente da http://www.rigacci.org/wiki/doku.php/doc/appunti/linux/sa/nagios