I fornitori di servizi informatici molto spesso hanno la necessità di monitorare le prestazioni delle infrastrutture dei loro clienti, così come le aziende con diversi filiali. In questo caso la sfida principale consiste nel monitoraggio di componenti, che non sono direttamente connessi via VPN.
Il monitoraggio di sedi remote, che non possiedono alcuna diretta connessione VPN, MPLS, ecc. al server NetEye centrale, è possibile attraverso l’utilizzo del deamon NSCA. Nel seguente articolo, cercherò di illustrarvi quali aspetti vanno tenuti in considerazione e a cosa bisogna porre particolare attenzione.
Prerequisiti della sede remota
I server nelle sedi remote devono possedere una connessione internet (nessun IP pubblico fisso è invece necessario) sulla porta 5667 verso il server NetEye. Il deamon NSCA va quindi installato sul server che deve essere monitorato. Sugli ambienti Linux esiste già l’NSCA, su ambienti Windows invece è raccomandabile l’utilizzo dell’agente NSClient, che dispone di un deamon NSCA.
Il deamon NSCA deve essere configurato in modo tale che l’IP target è l’IP pubblico della sede centrale, che è inoltrata dal firewall al server NetEye. IN questo caso solo la porta 5667 dovrebbe essere aperta.
Su NSClient per gli ambienti Windows, si possono definire diverse possibilità di monitoraggio sulla sezione NSCA (per esempio il monitoraggio della CPU, della memoria, dello spazio sul disco, dei servizi o dei processi). Inoltre, si possono eseguire degli scripts esterni per monitorare l’Exchange Server o i dispositivi hardware che dispongono del deamon NSCA.
Per ogni servizio che deve essere monitorato, ovviamente, andr1a definito un nome, con il quale eseguire il controllo.
Inoltre, l’intervallo di monitoraggio deve essere impostato all’interno della configurazione NSCA (es. un intervallo di 5 minuti). Per gli ambienti Linux, queste configurazioni sono più estese perchè i controlli devono essere eseguiti attraverso gli scripts di un cronjob.
Prerequisiti di una sede centrale
Nella sede centrale il server NetEye deve essere installato sullo stesso server in cui NSCA è in funzione. Nelle installazioni NetEye normalmente il server NSCA è già preinstallato e necessita solo di essere configurato.
La configurazione sul server NSCA, ovviamente deve essere recepita dalla sede remota, altrimenti la comunicazione non sarebbe possibile. In questo caso intendo il livello di crittazione e la password.
Nella sede centrale il firewall deve essere configurato in modo tale che un IP pubblico sulla porta 5667 (porta standard NSCA) è attivo. Sarebbe utile, inoltre, se la sede remota disponesse di un IP pubblico fisso, perchè in questo caso il firewall potrebbe essere configurato in modo più restrittivo.
Nello stesso modo in cui i controlli, che sono definiti sulla sede remota, possono essere visualizzati e notificati in NetEye, l’hostname remoto del server e i servizi configurati, devono essere creati con lo stesso identico nome per l’hosto così come per il servizio creato in NetEye.
Per il controllo dell’host e per il controllo del servizio il controllo attivo deve essere spento, altrimenti i controlli verrebbero eseguiti con dei messaggi di errore.
È consigliabile definire i Freshness Threshold per questi controlli passivi in NetEye. In questo modo, nel caso in cui l’host remoto o certi servizi remoti non rispondono per un periodo predefinito (es. 15 minuti) viene generato un errore in NetEye.
Conclusione
L’approccio descritto può essere utilizzato dai fornitori di servizi IT per monitorare infrastrutture IT meno complesse dei loro clienti. I dati prestazionali di diversi clienti possono essere raccolti e gli allarmi possono essere definiti centralmente. In questo modo, si può disporre di una panoramica generale delle infrastrutture anche dei clienti, anche se per infratrutture IT più complesse è più opportuno eseguire un’implementazione in loco.
Tobias Goller
Author
