Monitoraggio dei nodi

Parametri di monitoraggio

Un nodo e’ caratterizzato dalle seguenti informazioni:

Dato	Descrizione
description	Descrizione dell’elemento
switch	(flag si/no) indica se il nodo ha funzionalita’ di switching
router	(flag si/no) indica se il nodo ha funzionalita’ di routing
icon	icona usata dall’interfaccia web

Esistono altri attributi per il momento secondari:

Dato	Default	Descrizione
priorita’		Priorita’ di default delle condition associate (se non specificato diversamente)
flag ipv4/ipv6	false	Flag vero/falso per indicare se utilizzare protocollo IPv6 come protocollo di rete di default per questo nodo (default IPv4)
Nome Dns		(facoltativo) Nome Dns da utilizzare se diverso dal nome associato al nodo
Nome DNS ipv6		(facoltativo) Nome Dns da utilizzare se diverso dal nome associato al nodo
IP (v4)		(facoltativo) Indirizzo IPv4 da utilizzare per il monitoraggio
IP (v6)		(facoltativo) Indirizzo Ipv6 da utilizzare per il monitoraggio
Timezone		(facoltativo) Timezone associata a questo nodo
SNMP versione	1	Versione del protocollo SNMP. Valori ammessi 1,2,3. Il valore 0 disabilita l’invio di richieste verso SNMP verso il nodo.
SNMP port	161	Porta SNMP (default 161)
SNMP community	public	Community SNMP
Default Timeout	1	Timeout di default da utilizzare per i controlli associati a questo nodo
Notify Address		Indirizzo di notifica utilizzato per segnalare anomalie non gestite (Trap SNMP o altro)

Flag switch/router

I flag switch e router sono due flag puramente informativi e non influiscono in nessuno modo sul monitoraggio.

Nome del nodo e identificativo effettivo

E’ preferibile che tutti gli apparati/server monitorati siano registrati/inventariati presso un DNS (anche locale sulla stessa macchina dove e’ installato Sanet), ma in certi scenari un nodo potrebbe non essere registrato:

• Non si a’ controllo del DNS, ma c’e’ comunque necessita’ di monitorare il nodo.
• Il nodo appartiene ad una rete esterna monitorata attraverso un agente remoto
• ecc.

In fase di monitoraggio bisogna distinguere tra nome del nodo e identificativo effettivo del nodo:

• nome e’ il nome assegnato in Sanet.
• identificativo effettivo e’ il nome (hostname) o indirizzo IP realmente usato da Sanet per il monitoraggio.

L’identificativo effettivo viene calcolato in questo modo:

• Se il flag IPv4 e’ vero:

  • Se l’indirizzo IP e’ specificato usa quello
  • Se il nome DNS e’ specificato usa quello
  • Usa il nome del nodo in Sanet (quindi il nome del nodo deve essere risolvibile in IPv4: file hosts o record A)

• Se il flag IPv4 e’ falso:

  • Se l’indirizzo IPv6 e’ specificato usa quello
  • Se il nome DNSv6 e’ specificato usa quello
  • Usa il nome del nodo in Sanet (quindi il nome del nodo deve essere risolvibile in IPv6: file hosts o record AAAA)

IMPORTANTE: Questa logica altera anche le variabili utilizzabili nelle espressioni di monitoraggio di sanet. Si veda: Built-in node’s variables.

Configurazione protocollo SNMP

Configurazione SNMPv3

Danger

a causa di problemi nel pacchetto NET-SNMP ufficiale (binding python) il supporto per il protocollo SNMPv3 e’ instabile e puo’ causare crash (con probabile terminazione) dei processi agenti che eseguono operazioni utilizzano il protocollo SNMPv3. Se si ha necessita’ di monitorare nodi con SNMPv3 e’ consigliabile creare un agente ad-hoc in modo che eventuali crash non impattino sul monitoraggio del resto del sistema.

Quando si intende monitorare dei nodi attraverso il protocollo SNMPv3 e’ necessario configurare il parametro SNMP Community in maniera particolare.

La stringa di configurazione deve rispettare una sintassi particolare che serve per specificare tutti i parametri di sicurezza/autenticazione previsti dal SNMPv3.

Si rimanda alla sezione: Opzioni SNMPv3.

Opzioni SNMPv3

La stringa di configurazione delle opzioni SNMPv3 deve rispettare la seguente sintassi:

<option> : <value> [ , <option> : <value> ]*

Important

La stringa e’ CASE SENSITIVE

La option puo’ essere una delle seguenti:

Opzione	Descrizione	Valori ammessi	Default
context	Context Name	stringa	‘’
username	Securety Name	stringa	‘initial’
sec_level	Security Level	noauth, auth, crypt	noauth
auth_proto	Authentication protocol	md5, sha	md5
auth_pass	Authentication passphrase	stringa
crypt_proto	Privacy protocol	stringa
crypt_pass	Privacy passphrase	stringa

Le opzioni auth_proto e auth_pass sono richieste quando sec_level e’ valorizzato a auth or crypt.

Le opzioni crypt_proto e crypt_pass sono richieste quando sec_level e’ valorizzato a crypt.

Esempi:

context:mycontext

sec_level:auth,username:foo,auth_proto:md5,auth_pass:mypassword

sec_level:noauth,context:mycontext

Disabilitare completamente SNMP

La versione SNMP configurata di default e’ la 1.

In alcuni contesti (interfaccia web, CLI) Sanet utilizza il protocollo SNMP per ottenere on-demand informazioni sul nodo o i suoi apparati.

Se si desidera disabilitare completamente qualunque uso del protocollo SNMP bisogna impostare a 0 il numero di versione SNMP.

Impostare a 0 la versione comporta:

• Qualunque dato SNMP richiesta da Sanet avra’ valore nullo (null o none). Questo valore e’ diverso da stringa vuota (‘’).
• Datasource e Condition basati su SNMP verranno eseguiti, ma con buona probabilita’ termineranno con stato UNCHECKABLE.

Raggruppamento di nodi in Cluster

Alcuni apparati non possono essere monitorati direttamente (via SNMP o altri protocolli) ma solamente interrogando altri apparati.

Lo scenario e’ il seguente:

• Esiste una serie nodi che vogliamo monitorare ma non interrogabili direttamente.
• Esiste una serie di nodi che espongono i dati di monitoraggio
• in un dato istante le informazioni di un nodo del primo gruppo sono mantenute da un preciso nodo del secondo gruppo.

Questo capita nel caso di:

• Access Point con Wireless Controller
• Cluster di virtualizzazione con i dati sulle macchine virtuali reperibili interrogando le macchine di virtualizzazione e non le macchine guest.

Per gestire in maniera “elastica” questi particolari apparati Sanet supporta quella che abbiamo definito “gestione di cluster di nodi”.

Un cluster e’ un un raggruppamento logico di nodi del monitoraggio identificato da:

• nome univoco
• dati aggiuntivi

I cluster possono essere pensati come insiemi disgiunti di nodi quindi valgono le seguenti regole regole:

• Possono essere definiti un numero arbitrario di cluster.
• E’ possibile associare un nodo ad un solo cluster alla volta.

Ruoli e associazione in un cluster

All’interno di un cluster le entita’ possono essere di due tipi:

• MASTER : sono le entita’ logicamente principali o piu’ importanti. Espongono le informazioni di monitoraggio degli altri nodi del cluster (DEPENDENT).
• DEPENDENT: entita’ logicamente dipendenti dalle entita’ MASTER.

Alcuni esempi:

• Wireless Controller e Access Point

  • Controller e’ un MASTER
  • Access Point e’ un DEPENDENT

• Cluster VMWare

  • Le macchine host (o hypervisor) sono MASTER
  • Le macchine guest sono DEPENDENT

Quando un MASTER esponde le informazioni di un DEPENDENT, si dice che il DEPENDENT e’ associato al MASTER.

Warning

Tutti i nodi raggruppati in un cluster (MASTER e DEPENDENT) devono essere monitorati (assegnati) dallo stesso agente. E’ da tenere presente questo vincolo quando si deve scegliere quali agenti definit/utilizzare e quali gruppi di nodi monitorare con lo stesso agente.

Configurazione nodi DEPENDENT

Ogni nodo DEPENDENT del cluster deve essere configurato in maniera tale che Sanet sappia come verificare se esiste un’associazione tra il nodo stesso e uno dei MASTER del cluster.

Per fare questo e’ necessario parametrizzare correttamente i seguenti campi del nodo:

• cluster-distinguisher

  Questo campo serve per memorizzare una stringa da utilizzare per identificare univocamente il nodo all’interno del cluster.

  NOTA: il valore di questo campo e’ arbitrario. Nel caso di access point di solito e’ frequente pensare al MAC address come un buon candidato ad essere usato come cluster_distinguisher.

  Quando questo campo e’ valorizzato, Sanet permette di richiamarne il valore in qualunque espressione attraverso la variabile $cluster_distinguisher.

• cluster-xform

  Questo campo deve contenere l’espressione che SANET valutera’ per controllare se il nodo e’ associato ad uno dei nodi del cluster.

  La variabile $cluster_distinguisher dovrebbe essere utilizzata all’interno dell’espressione (ma non e’ obbligatorio).

L’espressione cluster-xform viene eseguita su ogni nodo MASTER del cluster. Se la valutazione restituisce un risultato l’associazione con il nodo del cluster e’ verificata. Il risultato calcolato viene chiamato cluster-instance e puo’ essere usato successivamente per trovare le informazioni del nodo sul MASTER che ha verificato l’associazione.

Esempio:

cluster-distinguisher  ->  00260BAC5E60

cluster-xform          ->  byBinaryValue( 1.3.6.1.4.1.14179.2.2.1.1.1@ , $cluster_distinguisher )

In questo esempio stiamo indicando di usare la funzione byBinaryValue() per cercare nelle MIB 1.3.6.1.4.1.14179.2.2.1.1.1 di tutti i nodi MASTER del cluster un OID che contenga il valore binario 00260BAC5E60. Se viente trovato l’OID con quel valore, l’associazione e’ verificata.

Quando viene effettivamente calcolata l’associazione?

Per motivi di performance la gestione/controller del cluster viene attivata solo se un datagroup utilizza delle espressioni che hanno effettivamente bisogno di dati utilizzando questo meccanismo.

Anche se uno nodo e’ stato configurato con un certo cluster-distinguisher e cluster-xform, se un datagroup NON utilizza funzioni o variabili che coinvolgono la gestione a cluster, l’associazione non viene controllata!!!

Configurazione

• CLI: si rimanda alla sezione: Nodi
• WEB: non ancora disponibile.