Il monitor di un server windows può avere più soluzioni. Tipicamente occorre un agent che interfaccia il sistema operativo e risponde alle richieste del server nagios in modo opportuno. Queste richieste, come il carico della CPU, vengono visualizzate dalla console di Nagios nelle modalità definite dalla configurazione.

L'agent può essere semplicemente WMI (Windows Management Instrumentation) che può essere 'interrogato' anche da remoto. In questo caso, però, occorre un processo linux, sulla macchina Nagios, e dei processi in grado di formattare opportunamente le query WMI in un formato utile a Nagios.

In questa parte si descrive l'uso di un agent, NSClient ++ (NSCP), da installare sulla macchina windows (http://www.nsclient.org/nscp/downloads [7]) e si basa su una installazione minima di nagios descritta qui: http://www.rfc.it/applicativi/monitoring/installare-nagios [8]
NSCP riceve le richieste dal server Nagios (in varie modalità), rigira le richieste al sistema operativo (windows) e ritorna la risposta, opportunamente formattata, al server Nagios. Sembra tutto abbastanza semplice.
NCSP è fortemente personalizzabile. E possibile ad esempio implementare nuove funzioni di monitor, per andare a controllare ogni aspetto di windows, eventualmente anche processi e relativi parametri di applicazioni sviluppate da terze parti.
In questa descrizione ci si limita alle funzioni di base.
Il meccanismo di richiesta da nagios a windows utilizzato è  NRPE (Nagios Remote Plugin Executor) plugin.
Lo scambio di informazioni nagios <-> windows sono ben schematizzati nella figura che segue:

[9]

• Installazione lato windows.

Download e installazione dell'agent NSClient++
La configurazione di NSCP è controllata da nsclient.ini, nella directory %ProgramFiles%/NSClient++. La configurazione richiede la modifica del parametro allowed host = x.x.x.x nella sezione [/settings/default].
NRPE non richiede password.

NSCP può girare come servizio windows o come semplice programma. Il servizio è preferibile in produzione, mentre come programma è utile per il debug.
Lanciare NSCP.exe test dal prompt comandi. I messaggi che seguono sono utili per il debug.

Salvo problemi, no serve altro.

• Configurazione lato Nagios.

Installare il plugin nrpe zypper in nagios-plugins-nrpe

testare la comunicazione nagios - windows
/usr/lib/nagios/plugins/check_nrpe -H 10.0.0.5
Se l'agent è raggiungibile e risponde (attenzione al firewall, NRPE lavora. di default, sulla porta 5666) nel seguente modo:
I (0,4,1,66 2012-11-18) seem to be doing fine...

definire il server windows  e i relativi servizi.
Per semplicità si può usare il file /etc/nagios/object/winsows.cfg

Abilitare la riga cfg_file=/etc/nagios/objects/windows.cfg nel file /etc/nagios/nagios.cfg

occorre modificare l'indirizzo del server windows con il valore corretto, e le voci check_command.
Qui [10]un esempio del file windows.cfg
La voce check_command indica il il comando da usare e i parametri da passare al comando, separati dal !.
Occorre definire l'uso effettivo del comando. Questo si fa modificando il file /etc/nagios/objects/comamnfs.cfg
La definizione da aggiungere è la seguente:

#### check_nrpe
###############################################################################
# NRPE CHECK COMMAND
#
# Command to use NRPE to check remote host systems
###############################################################################

define command{
        command_name check_nrpe
        command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
        }

Per il controllo di eventuali errori formali si usa il comando nagios -v /etc/nagios/nagios.cfg

Fare ripartire nagios rcnagios restart

Controllare il risultato nella console di Nagios.

Lo stato dei servizi potrebbe essere indeterminato. Basta forzare il check del servizio per ottenere lo stato.

Uno dei metodi più comuni per il monitor di una stampante è usare il protocollo SNMP (Simple Network Management Protocol). Nei casi più frequenti le query alla stampante rispondono a MIB standard, printer MIB. In altri casi, alcuni produttori preferiscono una propria implementazione di MIB, il che può richiedere modifiche dei plugin.

• I casi standard.

Il plugin usato è  check_snmp_printer reperibile su http://exchange.nagios.org [12]. [13] Per installarlo basta copiare il files scaricato in /usr/lib/nagios/plugin

La definizione della stampante può usare come modello il files /etc/nagios/objects/printer.cfg che va modificato nella descrizione della stampante e IP.
Nel caso specifico printer.cfg fa riferimento al plugin check_hpjd, che mi sembra particolarmente scarso. Occorre modificare i le definizioni di check_command per utilizzare il plugin check_snmp_printer e ridefinire la struttura del comando in /etc/nagios/objects/commands.cfg

Qui [14]il file della definizione della stampante rivisto e corretto.

Al file /etc/nagios/objects/commands.cfg aggiungere quanto segue:

#### check_snmp_printer
###############################################################################
# CHECK  snmp printer COMMAND
#
# Command to use smnp_printer to check remote printer
###############################################################################

define command{
        command_name check_snmp_printer
        command_line $USER1$/check_snmp_printer -H $HOSTADDRESS$ -c $ARG1$ -x $ARG2$ -w $ARG3$ -c $ARG4$
        }

Fare il check delle modifiche nagios –v /etc/nagios/nagios.cfg

E forzare nagios a rileggere le modifiche rcnagios  reload

Se tutto è fatto correttamente questo è il risultato.

[15]

Nagios [18]è un software Open Source (OSS) [19] specializzato per il monitoraggio di sistemi informatici. Ogni dispositivo raggiungibile in rete, locale o remoto, può essere controllato per verificare stati di funzionamento e anomalie sia di macchine che di specifici servizi.

I meccanismi disponibili per accedere alle informazioni sono molteplici, dai più semplici, come un ping per verificare la raggiungibilità del sistema, a meccanismi standard e consolidati come consentito dal protocollo SNMP [20], a strumenti proprietari come WMI (Windows Management Instrumentation) [21] di windows. Altri casi sono gestibili con meccanismi personalizzati ad hoc, anche se nella maggior parte selle situazioni non sono necessari.

Le informazioni raccolte sono raggruppabili in vari modi per rendere conveniente e di facile consultazione le informazioni raccolte. Le situazioni anomale sono facilmente evidenziabili e raggruppabili in avvisi o allarmi secondo parametri ampiamente personalizzabili.
Le irregolarità riscontrate sono registrate a log o trasmesse in vari modi agli amministratori di sistema.

Le immagini che seguono sono relative ad un caso reale, dove sono evidenziati allarmi generati da dispositivi.
Le figure si possono ingrandire cliccandole.

Nella prima figura i vari dispositivi raggruppati secondo le necessità dell’azienda.

[22]

Nella seguente lo stato di un gruppo

[23]

I dispositivi, gli host, sono raggruppabili un una struttura grafica che rappresenta quella reale dove è evidenziata la situazione in tempo reale, nell’esempio un alert dovuto ad un aumento di temperature di un UPS.

[24]

La storia degli eventi è consultabile in vari modi. Nella figura che segue è evidenziata una situazione dove si può riscontrare un problema, della durata di circa 6 minuti, su un router. Attraverso le informazioni di uptime è semplice capire che si tratta di un problema sul dispositivo e non di mancata raggiungibilità.

[25]

La situazione a medio e  lungo termine è disponibile in modo facilmente consultabile attraverso i log do Nagios.

[26]