3. Teoria e gestione del Monitoraggio¶
Contenuti
- Teoria e gestione del Monitoraggio
- Concetti di base del monitoraggio
- Gerarchia del monitoraggio
- Tenant
- Agenti di monitoraggio
- Priorita’ logica dei controlli e livelli di priorita’
- Elementi Monitorabili (dagli agenti)
- Raccolta dati e controlli
- Datagroup
- Cos’e’ un datagroup
- Come definire un datagroup
- Gestione dei datagroup a parte degli agenti: Esecuzione
- Attributi di un datagroup e sotto-elementi di configurazione
- Dipendenze tra datagroup (dependson)
- I Datasource
- Le Condition
- Esecuzione di script automatica con variazioni di stato
- Regole di valutazione di Datasource e Condition
- Parametri opzionali
- Timegraph
- Sospensione e Riattivazione di un datagroup
- Configurazione avanzata dello scheduling
- Datagroup
- Template di Configurazione
- Monitoraggio dei nodi
- Monitoraggio dei interfacce
- Link tra nodi/interfacce
- Monitoraggio degli storage
- Monitoraggio dei servizi
- Monitoraggio di device generici
- Gestione Messaggi/Allarmi
- Calendari e range temporali
- Eventi “Push”
- Trap SNMP
- Concetti di base del monitoraggio
3.1. Concetti di base del monitoraggio¶
3.1.1. Gerarchia del monitoraggio¶
Sanet organizza il monitoraggio in maniera gerarchica.
Il seguente schema mostra la relazione gerarchica delle diverse entita’:
- Tenant (Tenant)
- Agenti (Agenti di monitoraggio)
- Nodi ed elemenenti interni (interfacce, dischi, servizi, ecc.) ( Elementi Monitorabili (dagli agenti) )
- Datagroup, datasource, condition e Timegraph. ( Raccolta dati e controlli )
![digraph sanetentities {
ximagepath="/opt/sanet3/static/webui/images/resources/";
node [fontsize="8"];
"tenant (site)" [ shape="box" ];
"agent (local)" [ shape="box" ];
"agent (remote)" [ shape="box" ];
"node1" [image="./source/_static/resources/node.png", shape=none, imagescale="true", fixedsize="true", width="1pt"];
"node2" [image="./source/_static/resources/node.png", shape=none, imagescale="true", fixedsize="true", width="1pt"];
"node3" [image="./source/_static/resources/node.png", shape=none, imagescale="true", fixedsize="true", width="1pt"];
interface [image="./source/_static/resources/iface.png" , shape=none, imagescale="true", fixedsize="true", width="1pt"];
storage [image="./source/_static/resources/storage.png", shape=none, imagescale="true", fixedsize="true", width="1pt"];
service [image="./source/_static/resources/service.png", shape=none, imagescale="true", fixedsize="true", width="1pt"];
device [image="./source/_static/resources/device.png" , shape=none, imagescale="true", fixedsize="true", width="1pt"];
subgraph datagroups {
datagroup2;
datagroup1;
}
"tenant (site)" -> "agent (local)";
"tenant (site)" -> "agent (remote)";
"agent (local)" -> "node1";
"agent (local)" -> "node2";
"agent (local)" -> "node3";
"node1" -> interface;
"node1" -> storage;
"node1" -> service;
"node1" -> device;
"node1" -> datagroup1;
datagroup1 -> datasource1;
datagroup1 -> condition1;
datagroup1 -> timegraph1;
interface -> "datagroup2";
datagroup2 -> datasource2;
datagroup2 -> condition2;
datagroup2 -> timegraph2;
}](../_images/graphviz-13b0856d605717ff5752965ec3e48387439e7282.png)
3.1.2. Tenant¶
E’ previsto che la stessa installazione di Sanet possa gestire una o piu’ configurazioni di monitoraggio completamente distinte e indipendenti.
Un’intera configurazione di monitoraggio (nodi, interfacce, controlli, dati da raccogliere, ecc…) e’ raggruppata logicamente in un Tenant.
Un tenant e’ caratterizzato dalle seguenti informazioni di base:
Attributo Descrizione Nome Nome identificativo del tenant. Deve essere univoco. Il nomer deve essere in LOWERCASE e puo’ contenere soltanto lettere o numeri (dopo almeno un carattere alfabetico) . Nome lungo Nome “verboso” puramente descrittivo Flag primario Flag vero/falso.
All’interno della stessa installazione i tenant sono completamente indipendenti e non condividono nessuna informazione/configurazione tra di loro (fatta eccezione per alcuni template speciali di configurazione).
Important
Se si organizza il monitoraggio in tenant multipli e si ha necessita’ di monitorare lo stesso host in due tenant, e’ obbligatorio duplicare le configurazioni su tutti e due i tenant.
3.1.2.1. Tenant primario (flag)¶
Tra tutti i tenant definiti deve esistere sempre un tenant in particolare, detto primario.
Il tenant primario viene scelto automaticamente durante le operazioni di configurazione ed utilizzato per mostrare i dati di monitoraggio via web quando non diversamente indicato dall’utente.
Note
Sanet effettua tutti i controlli necessari affinche’ esista sempre un tenant primario.
3.1.2.2. Tenant creato di default¶
In fase di installazione, Sanet crea automaticamente un tenant iniziale configurato come primario.
Se non specificato diversamente durante la fase di installazione il tenant verra’ chiamato “site”.
3.1.2.3. Rimozione di un tenant¶
Tramite i tool di amministrazione e’ possibile rimuovere un tenant dal sistema.
Warning
La rimozione di un tenant non effettua realmente la cancellazione dei dati (ne’ dal database ne’ su disco). Per rimuovere definitivamente tutti i dati bisogna procedere “manualmente” (erase-tenant)
3.1.2.4. Configurazione¶
- CLI: Vedere la sezione: Configurazione Tenant.
- WEB: Vedere la sezione: Tenant.
3.1.3. Agenti di monitoraggio¶
Come spiegato nel paragrafo Architettura, gli agenti (chiamati anche poller) sono le entita’ software (processi) che effettuano il monitoraggio della rete e comunicano i dati raccolti al server centrale di Sanet.
Per ogni tenant e’ possibile configurare piu’ di un agente di monitoraggio e distribuire il carico di lavoro tra i diversi agenti.
Gli agenti effettuano il monitoraggio delle entita’ assegnate loro in maniera completamente autonoma dagli altri agenti e non condividono informazioni tra di loro.
La granularita’ massima con cui e’ possibile suddividere il monitoraggio tra agenti e’ il nodo (Paragrafo Nodi)
Per monitorare un nodo attraverso un agente bisogna associare quel nodo all’agente.
E’ possibile configurare il monitoraggio per far gestire ad un agente solo alcuni nodi (ad esempio solo gli switch di rete), ed ad un altro agente altri nodi (solo i database server).
Important
Non si puo’ configurare esplicitamente e facilmente Sanet per monitorare parte di nodo con un agente e parte con un’altro (i controlli sulla RAM di un host con un agente e i controlli sui dischi con un altro agente).
3.1.3.1. Tipologie di agenti¶
- Esistono due tipi di agenti:
- locali
- remoti
3.1.3.1.1. Agenti locali¶
Gli agenti locali sono a tutti gli effetti processi che vengono eseguiti sul sistema (server) dove e’ stato installato Sanet.
Warning
Il numero di agenti locali che e’ possibile eseguire contemporaneamente sullo stesso sistema dipende dalle caratteristiche hardware/software della stessa.
3.1.3.1.2. Agenti remoti¶
Gli agenti remoti sono processi in esecuzione su macchine diverse (remote) da quella dove e’ installato Sanet.
Danger
E’ sconsigliato avere solo agenti remoti poiche’ sono processi in esecuzione remotamente e potrebbero risentire indirettamente di problemi
La gestione degli agenti remoti prevede alcuni accorgimenti. Per tutti i dettagli si rimanda alla sezione dedicata: Agenti remoti.
3.1.3.2. Agente primario¶
Tra tutti gli agenti definiti in un tenant esiste sempre un agente primario.
Note
Tutti i nodi monitorati all’interno di un tenant, se non specificato esplicitamente, vengono assegnati automaticamente all’agente primario nel momento in cui vengono creati.
Warning
E’ sconsigliato definire come primario un agente remoto. E’ opportuno avere sempre almeno un agente locale definito come primario in maniera che eventuali problemi di rete non blocchino completamente il monitoraggio della rete.
3.1.3.3. Parametri di configurazione di un agente¶
La configurazione di un agente prevede diversi parametri. La modifica di alcuni di questi parametri richiede il riavvio dell’agente (locale o remoto)
Parametro Descrizione Richiede riavvio dell’agente Flag primario Si/No. Indica se l’agente e’ l’agente primario del sistema. Flag attivo Si/No. Indica se l’agente e’ attivo o se e’ stato disabilitato dall’amministratore si Flag remoto Si/No. Indica al sistema se l’agente e’ considerato un agente locale/remoto. si Intervallo di update Intervallo di update per in secondi prima di ricaricare la configurazione per effettuare il monitoraggio si Numero Threads Numero di thread interni usati dall’agente per parallelizzare il monitoraggio si
Warning
Gli agenti non attivi non effettuano alcun tipo di operazione. Il monitoraggio delle risorse associate a quell’agente e’ completamente disabilitato.
3.1.3.3.1. Numero di thread¶
Tutti gli agenti effettuano il monitoraggio dei nodi assegnati loro cercando di parallelizzare il lavoro attraverso un thread pool di esecuzione.
E’ possibile indicare esplicitamente il numero di thread da utilizzare per ogni agente.
Note
Non si puo’ controllare in che modo gli agenti internamente parallelizzano il lavoro, ma e’ possibile obbligare un agente a rischedulare l’esecuzione di singoli controlli tramite appositi comandi (Comando: check_in).
Danger
Non c’e’ alcun limite al numero di thread che e’ possibile configurare per ogni agente, tuttavia la velocita’/prestazioni dell’agente non cresce linearmente col numero di thread. E’ bene impostare un numero di thread non superiore a 40 per iniziare ed aumentare gradualemente il numero finche’ le performance non sembrano subire un degrado.
3.1.3.4. Amministrazione agenti¶
Per amministrare ed interagire con gli agenti in esecuzione e’ necessario usare appositi comandi. Si rimanda alla sezione Strumenti di amministrazione: agentinfo.
3.1.3.5. Configurazione agenti¶
- CLI: si rimanda alla sezione: Configurazione Agenti.
- WEB: si rimanda alla sezione: Agenti.
Poiche’ gli agenti remoti prevedono una gestione/configurazione particolare, si rimanda alla sezione specifica: Agenti remoti.
3.1.4. Priorita’ logica dei controlli e livelli di priorita’¶
Ad ogni elemento del monitoraggio e’ associabile un livello di importanza chiamato priorita’.
La priorita’ e’ un valore numerico compreso tra 1 e 100 (compresi).
La priorita’ non serve ai fini del monitoraggio, ma viene utilizzata per scopo informativi e per facilitare la consultazione dei dati (via web o cli).
Note
Quando un elemento di monitoraggio non ha una priorita’ assegnata, si parla di priorita’ nulla o N/A
Warning
Il sistema utilizza valore 0 per codificare l’assenza di priorita’ (N/A), ma non e’ lecito ritenere questo valore rimarra’ tale in futuro. Non e’ consigliato implementare script o integrare Sanet con altri software assumendo che la priorita’ sia codificata con il valore 0.
3.1.4.1. Livelli di priorita’¶
All’interno di un tenant, la scala di priorita’ da 1 a 100 puo’ essere suddivisa logicamente in livelli (range) di priorita.
Ogni livello e’ caratterizzato da:
- Una etichetta (un nome).
- Una descrizione.
I livelli non sono sovrapponibili/intersecabili tra loro.
Esempio:
Etichetta Range Descrizione IGNORE 1-10 Allarme con priorita’ bassa NORMAL 11-30 Allarme CRITICAL 31-90 Allarme da segnalare subito FATAL 91-100 Problema critico per il sistema
Note
Questi “livelli” sono puramente informativi/descrittivi e non influenzano la gestione del monitoraggio. Possono eventualmente essere usati per facilitare la composizione di messaggi/allarmi.
3.1.4.2. Livelli di default¶
Se l’utente non configura dei livelli di priorita’, Sanet crea di default i seguenti livelli:
Etichetta Range Descrizione LOW 1 - 30 Priorita’ bassa MEDIUM 31 - 60 Priorita’ media CRITICAL 61 - 100 Priorita’ critica
3.1.4.3. Configurazione¶
- CLI: si rimanda alla sezione: Livelli priorita.
- WEB: si rimanda alla sezione: Livelli di priorita e priorita’ minima/critica.
3.1.5. Elementi Monitorabili (dagli agenti)¶
Esistono 5 tipologie di elementi che possono essere monitorati:
3.1.5.1. Nomi degli elementi¶
Tutti gli elementi di monitoraggio sono caratterizzati da un nome:
- Il nome dei nodi e’ univoco all’interno dello stesso tenant.
- Il nome di interfacce/storage/service/device e’ univoco all’interno dello stesso nodo. Due interfacce/dischi/device/ecc. non possono avere lo stesso nome all’interno dello stesso nodo. (es: eth0, root-disk, ecc.)
Warning
il nome di un elemento puo’ contenere SOLO un set di caratteri ben definito e deve rispettare il formato espresso dalla seguente espressione regolare:
^[a-zA-Z0-9]+([-.][a-zA-Z0-9]+)*$
3.1.5.2. Quali entita’ definire e monitorare¶
E’ bene tenere presente che, tecnicamente, e’ possibile definire un nodo e monitorare tutte le sue componenti interne (dischi/interfacce/ecc.) senza definirle esplicitamente nel monitoraggio.
Note
In pratica si definisce solo il nodo e si definisce almeno un controllo puntuale per ogni sotto elemento del nodo (Esempio: un controllo sul’interfaccia eth0, un controllo sul disco, ecc.)
Questo approccio e’ fortemente sconsigliato.
Note
Questo e’ anche il sistema utilizzato da altri sistemi di monitoraggio (Esempio: Nagios).
Il consiglio per chi usa Sanet e’ cercare di inserire nel sistema una configurazione granulare, esplicitando quando possibile, e compatibilmente con le proprie esigenze, tutte le entita’ monitorate per i seguenti motivi:
- Tutte le entita’ (nodi/interfacce/ecc.) sono caratterizzate da attributi specifici (e parametrizzabili) pensati per razionalizzare il piu’ possibile la configurazione.
- La definizione dei dati da raccogliere e dei controlli da eseguire su ogni entita’ monitorata risulta piu’ comprensibili e modulare.
- E’ piu’ facile consultare i dati raccolti.
3.1.5.3. Nodi¶
I nodi sono l’elemento principale di monitoraggio in Sanet.
Qualunque elemento sulla rete in grado di comunicare/rispondere tramite uno o piu’ protocolli di rete (piu’ o meno standard) e’ classificabile logicamente come un nodo. Alcuni esempi di elementi di rete che e’ possibile consideare come nodi in Sanet:
- PC e server di rete (reali o virtuali)
- switch, router, firewall
- NAS
- UPS
- Tablet/Cellulari
- Raspberry Pi
- ecc.
Note
Anche un processo in esecuzione su un server (apache) risponde a protocolli di rete, ma in questo caso si tratta di un entita’ software in esecuzione (su quello che si puo’ considerare come nodo) e per tanto dovrebbe essere monitorato attraverso un’apposita entita’ in Sanet (un service).
Note
I nodi sono le uniche entita’ del monitoraggio che possono contenere altre entita’ (dischi, interfacce, ecc.), ma non altri nodi.
Important
non e’ possibile configuarare esplicitamente alcune situazioni particolari. Ad esempio non si riesce ad esplicitare la relazione che esiste tra un server di virtualizzazione (nodo) e le macchine virtuali (nodi) che contiene.
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Monitoraggio dei nodi.
3.1.5.4. Interfacce¶
L’entita’ interfaccia rappresenta un’interfaccia (fisica o virtuale) presente su un nodo di rete.
Le interfacce vengono definite all’interno dei nodi (sono sotto-entita’ di un nodo) e sono identificate da un nome che deve essere univoco all’interno del nodo (es: eth0).
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Monitoraggio dei interfacce.
3.1.5.4.1. Interfacce e ifindex¶
L’ ifindex di una interfaccia e’ un valore (utilizzato principalmente nel protocollo SNMP) che serve per identificare dinamicamente un’interfaccia all’interno di un apparato di rete.
Sanet supporta un meccanismo per scoprire automaticamente questo valore e semplificare la scrittura di controlli basati sull’ifindex. Si rimanda alla sezione: Attributi Distinguisher, xform e valore ifIndex;
Important
Normalmente l’ifindex e’ un valore numerico, ma (purtroppo) esistono casi reali in cui non e’ cosi e per tanto Sanet gestisce l’ifindex come stringa.
3.1.5.5. Storage¶
Questa entita’ rappresenta genericamente uno storage all’interno di un nodo di rete:
- memoria RAM
- memoria ROM
- hardisk,
- memorie USB
- partizione montata via rete
- ecc.
Gli storage vengono definiti all’interno dei nodi (sono sotto-entita’ di un nodo) e sono identificati da un nome che deve essere univoco all’interno del nodo (es: root, C, netshared).
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Monitoraggio degli storage.
3.1.5.5.1. Storage e stindex¶
L’ stindex di uno storage e’ un valore (utilizzato nel protocollo SNMP) che serve per identificare dinamicamente uno storage all’interno di un apparato di rete.
Sanet supporta un meccanismo per scoprire automaticamente questo valore e semplificare la scrittura di controlli basati sull’stindex. Si rimanda alla sezione: Attributi Distinguisher, xform e valore stIndex;
Important
Normalmente l’stindex e’ un valore numerico, ma (purtroppo) esistono casi reali in cui non e’ cosi e per tanto Sanet gestisce l’stindex come stringa.
3.1.5.6. Servizi¶
Questa entita’ serve per rappresentare nel monitoraggio qualunque entita’ software, univocamente identificabile, presente (non necessariamente in esecuzione costante) su un nodo di rete.
- script BATCH per la produzione di dati.
- demoni di rete (inetd, apache, postfix, syslogd, ecc.).
- DB Manager.
- Broker di rete.
- Processi utente in esecuzione sulla macchina.
- Genericamente qualunque entita’ software composta da uno o piu’ programmi/script.
I servizi vengono definiti all’interno dei nodi (sono sotto-entita’ di un nodo) e sono identificati da un nome che deve essere univoco all’interno del nodo (es: apache, mysql, oracle, squid, ecc.).
Note
Il termine “servizio” e’ molto generico. Potrebbe trarre in inganno e far pensare che tramite una entita’ servizio si debba monitorare SOLO dei servizi complessi come “la posta” o lo “streaming video”.
In realta’ un servizio di posta completo coinvolge molte entita’ monitorabili (server POP, server IMAP, server SMTP, sistemi di storage, processi di logging, ecc…).
Spetta all’amministratore di Sanet decidere come sfruttare le risorse di tipo servizio di Sanet, quale sia il loro effettivo significato e quali sono effettivamente le entita’ reali sulla rete associate al quel servizio.
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Monitoraggio dei servizi.
3.1.5.6.1. Servizi e swrunindex¶
L’ SwRunIndex e’ un valore (utilizzato nel protocollo SNMP) che serve per identificare dinamicamente un processo in esecuzione su un server di rete che risponde a richieste SNMP.
Sanet supporta un meccanismo per scoprire automaticamente questo valore e semplificare la scrittura di controlli basati sull’SwRunIndex. Si rimanda alla sezione: Attributi Distinguisher, xform e valore swRunIndex;
Important
Normalmente l’SwRunIndex e’ un valore numerico, ma (purtroppo) esistono casi reali in cui non e’ cosi e per tanto Sanet gestisce l’SwRunIndex come stringa.
3.1.5.7. Dispositivi generici (device)¶
Qualunque dispositivo hardware presente all’interno di un server o apparato di rete, univocamente identificabile e monitorabile (attraverso protocolli di comunicazione o attraverso programmi esterni) e’ potenzialmente classificabile come device.
Alcuni esempio:
- Sensori (di qualunque tipo)
- Hardware interno (CPU, ventole, moduli, ecc..)
- Hardware esterno (es: Webcam attaccato tramite presa USB)
In Sanet gli elementi di tipo dispositivo (device) vengono definiti all’interno dei nodi (sono sotto-entita’ di un nodo) e sono identificati da un nome che deve essere univoco all’interno del nodo (es: fan0, usb-card-reader, printer1, ecc.).
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Monitoraggio di device generici.
3.1.5.7.1. Device e devindex¶
Alcuni apparati di rete espongono (via SNMP o altri protocolli) informazioni su dispositivi interni e spesso li identificano attraverso un valore univoco (tipicamente numerico).
Questo valore viene chiamato in Sanet devindex.
Sanet supporta meccanismo analoga a quello per il calcolo di ifindex, stindiex, ecc. per scoprire automaticamente il valore di devindex. Si rimanda alla sezione: Attributi Distinguisher, xform e valore swRunIndex;
3.1.5.8. Link tra interfacce¶
Un link rappresenta e’ un collegamento tra due interfacce. Tra due interfacce e’ possibile definire piu’ link.
Esistono 3 tipi di link:
Tipo Descrizione Fisico Rappresenta un collegamento tra due interfacce tramite cavi/fibre. Rete Rappresenta un collegamento non fisico. Virtuale Codifica un collegamento puramente virtuale definito per permettere controlli particolari in fase monitoraggio delle interfacce coinvolte.
Note
La differenza tra un link di “rete” e un link virtuale e’ che col primo si vuole identificare collegamenti tra interfacce che esistono ad un certo livello dello stack ISO/OSI, mentre il link virtuale e’ un’astrazione che potrebbe anche essere puramente logica e utile solo per esigenze di monitoraggio.
Attention
In Sanet puo’ essere definito un solo link fisico tra due interfacce, mentre possono essere definiti un numero arbitrario di link di rete o virtuali.
Attention
Il monitoraggio delle interfacce si basa esclusivamente (per il momento) sui link fisici. Link di rete e Virtuali sono ignorati al momento e non e’ possibile utilizzarli in nessun modo per implementare controlli specifici.
3.1.5.8.1. Nome di un link¶
Un link e’ caratterizzato da un nome “univoco”. Se non specificato, il sistema assegna automaticamente ai link un nome univoco componendolo a partire dai nodi/interfacce che coinvolge.
Per i dettagli sui parametri di configurazione/monitoraggio si rimanda a: Link tra nodi/interfacce.
3.1.6. Raccolta dati e controlli¶
3.1.6.1. Datagroup¶
3.1.6.1.1. Cos’e’ un datagroup¶
Per ogni entita’ monitorabile e’ necessario raccogliere dati logicamente collegati tra di loro e definire controlli su di essi. Ad esempio:
- CPU: Load average e percentuale di occupazione
- DISCO: spazio utilizzato/spazio totale
- TRAFFICO: traffico IN unicast/multicast/broadcast, traffico OUT unicast/multicast/broadcast.
- Servizio Email: numero email inviate/ricevute, percentuale di spam, ecc.
- Sensore di temperature: temperatura registrata in gradi.
Un gruppo di informazioni/controlli da monitorare insieme in un dato momento e’ rappresentato da un Datagroup.
Un datagroup codifica:
- Quali dati raccogliere dalla rete e come raccoglierli.
- Quali controlli effettuare sui dati raccolti.
- Con quale frequenza effettuare queste operazioni.
3.1.6.1.2. Come definire un datagroup¶
Per definire le varie parti di un datagroup, Sanet utilizza un sistema di configurazione basato su template chiamato datagroup template (che specifica il datagroup in ogni sua parte).
Ad ogni elemento del monitoraggio (nodo, interfaccia,ecc.) e’ possibile associare zero o piu’ datagroup template e questa associazione crea i datagroup.
Per i dettagli sul meccanismo di templating usato da Sanet si rimanda alla sezione dedicata: Template di Configurazione.
3.1.6.1.3. Gestione dei datagroup a parte degli agenti: Esecuzione¶
Il datagroup e’ l’entita’ atomica che gli agenti processano per effettuare le operazioni di rete.
Gli agenti periodicamente:
- caricano dal server centrale tutte le informazioni sulle entita’ da monitorare.
- caricano dal server centrale tutti i datagroup associati alle entita’ da monitorare.
- A intevalli regolari, utilizzano le informazioni contenute di ogni singolo datagroup per effettuare i controlli di rete e inviare i dati raccolti al server centrale.
Quando un agente decide di usare un datagroup per effettuare le operazioni di monitoraggio si dice che l’agente ESEGUE UN DATAGROUP.
3.1.6.1.4. Attributi di un datagroup e sotto-elementi di configurazione¶
Un datagroup possiede diversi attributi (opzioni di configurazione). Questa tabella riassume gli attributi specifici del datagroup:
Attributo Modificabile Opzionale Default Descrizione path no no Stringa mnemonica generata automaticamente dal sistema titolo si si Titolo che compare nelle descrizioni e nell’interfaccia web. minperiod si si 60 Pausa (in secondi) tra due esecuzioni dello stesso datagroup. timeout si si 3 Timeout di default (in secondi) utilizzato per effettuare le operazioni di rete. shorttries si si 5 Valore di default che indica il numero di tenatativi per effettuare una certa operazione di rete nel datagroup (un GET SNMP, un ping, ecc.) classification si si Stringa mnemnoica per cataloga il tipo di datagroup passive match si si Stringa per identificare un datagroup in un un controllo passivo dependson si si Stringa che codifica la catena di dipendenza del datagroup
Un datagroup e’ composto da i seguenti sotto-elementi:
Tipo Descrivono i dati che si vogliono raccogliere dalla rete, come devono essere raccolti e come devono essere salvati nel sistema. Parametri Variabili opzionali utilizzabili per rendere parametrizzabile la valutazioni di Datasource e Condition. Datasource Descrivono i dati che si vogliono raccogliere dalla rete, come devono essere raccolti e come devono essere salvati nel sistema. Condition Condizioni da verificare. Ogni condition e’ caratterizzata da diversi attributi che descrivono il controllo da eseguire. Timegraph Definizione per visualizzare grafici temporali dei dati raccolti (e storicizzati) dai DataSource.
3.1.6.1.4.1. Esempi di dati (datasource) e condizioni (condition)¶
- La raggiungibilita’ calcolata attraverso protocollo ICMP puo’ essere monitorata definendo un datagroup con:
- 4 datasource: rttmin, rrtmax, rttavg, pktloss (in percentuale)
- 1 condition: pktloss < 100%
- Il datagroup con tutte le informazioni STP di un’interfaccia potrebbe contenere:
- 1 datasource: numero transizioni di stato corrente
- 1 condition: varizione sul numero di transizioni rilevate rispetto al
- 1 condition: verifica adiacenza STP con l’interfaccia collegata
3.1.6.1.4.2. Titolo¶
Il titolo e’ una stringa descrittiva che viene visualizzata dall’interfaccia web.
E’ possibile utilizzare numerose variabili/wildcard per espandere automaticamente nel testo del titolo alcune informazioni sull’entita’ monitorata collegata al datagroup.
Tutte le variabili utilizzabili hanno come prefisso il carattere ‘$’.
L’elenco effettivo di variabili valide dipende dal tipo di risorsa (nodo, interfaccia, ecc.) a cui sara’ associato il datagroup.
Variabili usabili nel titolo di un datagroup/condition/datasource associato ad un nodo:
$node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo Tutti i parametri opzionali con $*parametro* Es. $threshold
Variabili usabili nel titolo di un datagroup/condition/datasource associato ad una interfaccia:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $iface nome dell’interfaccia $instance distinguisher dell’interfaccia $linked_iface (interfaccia collegata con un link fisico) $linked_node (nodo dell’interfaccia collegata con un link fisico) Tutti i parametri opzionali con $*parametro* Es. $threshold
Variabili usabili nel titolo di un datagroup/condition/datasource associato ad uno Storage:
Variabile Descrizione Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $storage nome dello storage $instance distinguisher dello storage Tutti i parametri opzionali con $*parametro* Es. $threshold
Variabili usabili nel titolo di un datagroup/condition/datasource associato ad un Service:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $service nome del servizio $distinguisher distinguisher del servizio Tutti i parametri opzionali con $*parametro* Es. $threshold
Variabili usabili nel titolo di un datagroup/condition/datasource associato ad un Device:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $device nome del device $distinguisher distinguisher del device Tutti i parametri opzionali con $*parametro* Es. $threshold
3.1.6.1.4.3. Path¶
Un datagroup (e anche i suoi datagroup/datasource) e’ identificato univocamente all’interno del tenant da una stringa chiamata path.
Il path* condifica implicitamente informazioni su:
- l’elemento (nodo) ed eventualmente il sotto-elemento (interfaccia,storage,service,device) a cui e’ associato.
- element-template di configurazione (si veda: Template di Configurazione);
- nome del datagroup
- nome datasource o nome della condition (per i path di datasource e condition).
La sintassi del path e’ la seguente:
Path Datagroup
<nome nodo> [ : <nome sub elemento> ] ; [ < element-template > ; ] <nome datagroup>
Path Datasource
<nome nodo> [ : <nome sub elemento> ] ; [ < element-template > ; ] <nome datagroup> : <nome datasource>
Path Condition
<nome nodo> [ : <nome sub elemento> ] ; [ < element-template > ; ] <nome datagroup> : <nome condition>
Esempi:
localhost;;icmp-reachability PATH datagroup
localhost:eth0;;iface-data:iferrs PATH datasource
Warning
il path e’ una stringa che dovrebbe restare opaca per l’utente e per software esterni. E’ preferibile evitare di basarsi su porzioni parziali del path per implementare elaborazioni ad hoc.
3.1.6.1.4.4. Periodicita’ dei controlli (minperiod) e scheduling¶
Ogni datagroup viene eseguito ad intervalli regolari.
L’intervallo di tempo MINIMO tra un’esecuzione e l’altra e’ chiamato minperiod e viene espresso in secondi.
Il valore di default per il minperiod e’ 60 secondi.
Attention
Il range di valori ammessi e’ compreso tra 0 to 32767 secondi, pari circa a 9 ore.
E’ possibile configurare Sanet per gestire uno scheduling piu’ sofisticato, e non solo basato sul minperiod. Si veda la sezione XXXXXXXXXXXXXXXXXXXX.
Se il minperiod e’ valorizzato a 0, il datagroup non viene mai schedulato e viene definito passivo.
E’ possibile eseguire un datagroup passivamente attraverso meccanismi come le Trap SNMP ( Trap SNMP ) o eventi push ( Eventi “Push” ).
Piu’ il minperiod e’ basso, piu’ e’ alta la frequenza con cui viene eseguito un datagroup.
Il carico di elaborazione per il sistema e’ direttamente proporzionale alla numero totale di datagroup ed alla loro frequenza di esecuzione.
Attention
Il sistema non impedisce di mettere minperiod piu’ bassi di 60 secondi, tuttavia e’ altamente sconsigliato scendere sotto i 15 secondi.
E’ possibile configurare Sanet per gestire uno scheduling piu’ sofisticato, e non solo basato sul minperiod. Si veda la sezione XXXXXXXXXXXXXXXXXXXX.
3.1.6.1.4.5. Timeout delle operazioni (timeout)¶
Nel 90% dei casi un datagroup deve raccogliere dati dalla rete. Per evitare di attendere indefinitivamente il completamento di una operazione (es: un ping) ogni datagroup puo’ specificare un valore di timeout in secondi.
Il valore specificato viene considerato come il timeout di default del datagroup. Ogni singola operazione eseguita dal datagroup puo’ decidere se utilizzare questo valore, ignorarlo o utilizzare questo dato per calcolare un timeout diverso.
Il default e’ 5 secondi.
Attention
non tutte le funzioni/operazioni eseguibili da sanet tengono conto di questo valore.
3.1.6.1.4.6. Numero di tenativi per operazione (shorttries)¶
Per ogni datagroup si puo’ specificare quante volte “tentare” una singola operazione di raccolta dati (es: un ping, un GET SNMP, una connect). Questo valore e’ chiamato shorttries.
Il valore di default e’ 3.
Attention
non tutte le funzioni/operazioni eseguibili da sanet tengono conto di questo valore.
3.1.6.1.4.7. Passive match¶
L’attributo passive match e’ una stringa utilizzata nel meccanismo di esecuzione dei datagroup passivi e serve per discriminare quali datagroup passivi (tra tutti i datagroup di una risorsa monitorata) devono essere eseguiti allo scatenarsi di un evento (Si veda Datagroup passivi (non schedulati)).
Ad ogni evento esterno puo’ essere associato un identificativo in formato stringa che viene confrontato con il passive match.
La stringa di match contenuta in passive match puo’ avere due formati:
- Stringa di caratteri semplice.
Vengono gestiti dal datagroup tutti gli eventi il cui identificativo corrisponde esattamente alla stringa specificata.
- Stringa con prefisso regex: :
La stringa dopo il prefisso viene interpretata come regular expression. Vengono gestiti dal datagroup tutti gli eventi il cui identificatvio fa match con la regular expression
Esempi:
Passive match Identificativo evento Risultato event12345 event12345 Datagroup passivo ESEGUITO event12345 event345 Datagroup passivo NON ESEGUITO regex:^event event345 Datagroup passivo ESEGUITO
I Datagroup passivi vengono impiegati per implementare la gestione di trap snmp (vedi Trap SNMP ) ed eventi push (vedi Eventi “Push” ).
3.1.6.1.4.8. Classificazione di datagroup/datasource/condition (classification)¶
Due o piu’ datagroup diversi potrebbero raccogliere dati logicamente simili.
Due o piu’ datasource potrebbero raccogliere lo stesso dato, ma con meccanismi diversi.
Due o piu’ condition potrebbero effettuare lo stesso controllo logico, ma con parametri diversi.
Ad esempio, due datagroup progettati per effettuare il controllo della memoria possono avere nomi diversi, ma effettuare logicamente lo stesso tipo di operazioni.
Per poter confrontare in maniera automatica i valori che vengono raccolti dai datasource, i controlli effettuati dalle condition e gli eventuali allarmi che seguono e’ necessario introdurre il concetto di classificazione.
La classificazione serve per idenditificare il contenuto semantico dei dati del monitoraggio.
La classificazione e’ una stringa mnemonica abitraria che si puo’ specificare per ogni datagroup/datasource/condition.
Anche se non formalmente obbligatorio, una classificazione e’ definita da una stringa di caratteri composta da “token” separati da “.”.
Ogni “token” e’ una stringa che codifica il nome di un nodo all’interno di uno namespace gerarchico.
Esempi di stringhe di classificazione:
servizi.principali.posta
servizi.secondari.marcatempo
rete.apparati.switch
rete.apparati.switch.
rete.apparati.router.hp
rete.apparati.router.cisco
rete.apparati.wireless.accesspoint
Concettualmente, la classificazione e’ logicamente gerarchica ed e’ rappresentabile con un albero. Il meccanismo di codifica e’ virtualmente analogo a quello delle OID (o dei package java, dei namespace C#, ecc.).
Si rimanda alle appendici Classificazioni per avere un elenco delle classificazioni possibili gia’ utilizzabili internamente per i controlli base di Sanet3.
Attention
datagroup, condition e datasource sono tutti classificati indipendentemente. Non esiste nessun meccanismo automatico di assegnamento di classificazioni.
3.1.6.1.5. Dipendenze tra datagroup (dependson)¶
Il sistema permette di definire relazioni di dipendenza tra datagroup. Questo permette di eseguire un particolare datagroup solo se la valutazione della condition di un altro datagroup e’ avvenuta con successo.
- Esempio: il datagroup per la raccolta dei dati relativi al servizio web “Apache” in esecuzione sul nodo “server1”, deve essere eseguito solo se la condizione
- che verifica la raggiungibilita ICMP (contenuta in un datagroup che raccoglie dati sulla raggiungibilita’ ICMP) del nodo ha verificato che il nodo sia effettivamente raggiungibile via rete.
La gestione delle dipendenze e’ gestita in automatico dal sistema, ma e’ possibile intervenire manualmente.
Si rimanda alla sezione Condition primary e dependson per maggiori dettagli.
3.1.6.1.6. I Datasource¶
Un datasource rappresenta il singolo dato di interesse per il monitoraggio raccolto/calcolato analizzando lo stato di un componente della rete.
Il valore calcolato da un datasource puo’ essere:
- numerico (intero o virgola mobile)
- stringa di caratteri ascii o byte
- valore complesso
Il valore calcolato da un datasource puo’ essere storicizzato da Sanet.
Important
il valore calcolato per un datasource viene storicizzato SOLO se numerico (intero o in virgola mobile).
Il valore di un datasource puo’ essere:
- raccolto singolarmente (un singolo valore raccolto via SNMP)
- essere il risultato di un’aggregazione di piu’ valori raccolti (es: a + b + c) e/o di altri datasource (dello stesso datagroup) calcolati/raccolti (immediatamente) prima di lui.
Proprieta’ di un datasource:
Dato Opzionale Default Descrizione expr si Espressione da valutare che indica come raccogliere/calcoalre il valore. Vedi Espressione e valore di un datasource. min val si Valore minimo consentito. Questa propieta’ non altera il dato raccolto, ma serve per fornire indicazioni sulla validita’ o meno del dato raccolto. max val si Valore massimo consentito. Questa propieta’ non altera il dato raccolto, ma serve per fornire indicazioni sulla validita’ o meno del dato raccolto. absolute value si si Flag SI/NO. Vedi Tipi di datasource: GAUGE o RATE (COUNTER). save value si si Indica se il valore calcolato deve essere salvato dal sistema o se scartato al termine dell’elaborzione del datagroup. order si Ordine di valutazione del datasource rispetto agli altri. Default 0. Vedi Ordine di valutazione di datasource e condition. cascade si no (flag si/no) Indica se, in caso di errore nella valutazione, i datasource successivi devono essere valutati o meno. (default no) classification si Stringa di classificazione storage-spec si Attributo per specificare parametri di configurazioni specifici del backend di storicizzazione dei dati. Vedi DataSource Storage Backends.
3.1.6.1.6.1. Tipi di datasource: GAUGE o RATE (COUNTER)¶
Il parametro absolute value serve per indicare in che modo salvare e storicizzare il valore di un datasource.
I due valori possibili sono:
- SI: il valore raccolto viene storicizzato come valore puntuale. Si parla in questo caso di valore GAUGE.
- NO: il valore raccolto viene storicizzato sotto forma di rate al secondo. Il sistema effettua automaticamente il calcolo del delta tra il valore corrente del datasource e il valore precedentemente calcolato. Si parla in questo caso di valore COUNTER.
Esempi di dati da raccogliere e quale tipo di datasource usare:
Dato Natura del dato absolute value numero utenti loggati valore puntuale si spazio disco occupato e spazio disco totale valore puntuale si Rtt min, max, avg, % packet loss valore puntuale si CPU %, Load Average valore puntuale si Traffico interfaccia (bit/s) rate no STP Topology change/s rate no
Important
il parametro absolute value altera significativamente le strutture dati utilizzate per storicizzare i dati su disco. Una volta che il sistema ha iniziato a raccogliere i dati di un datasource, ogni modifica al parametro absolute value e’ possibile, ma non produce alcun effetto nel sistema. Sono possibili alcune operazioni sui dati salvati di un datasource per “resettare” un datasource dopo modifiche al valore absolute value, ma fortemente sconsigliata.
3.1.6.1.6.2. Espressione e valore di un datasource¶
Il valore raccolto da un datasource viene calcolato valutando l’espressione (expr) associata al datasource.
L’espressione deve essere definita utilizzando un particolare linguaggio funzionale. In questo linguaggio si possono funzioni e variabili ricalcolate da Sanet ad ogni esecuzione dell’espressione.
Si rimanda alla sezioni Expression Language e SANET built-in expression symbols per maggiori dettagli sulla sintassi del linguaggio utilizzato dall’espressione.
Per altri dettagli sulla valutazione della expr si rimanda alla sezione Regole di valutazione di Datasource e Condition.
3.1.6.1.6.3. Precisione dei dati storicizzati¶
I dati storicizzati per ogni datasource vengono processati prima di essere memorizzati/storicizzati da Sanet.
Note
attualemente i dati vengono storicizzati tramite RRDTools, quindi file RRD.
Questo implica due cose:
- Esiste un lieve margine di approssimazione tra i dati raccolti e quelli effettivamente storicizzati da Sanet.
- Lo scostamento tra i dati raccolti e quelli effettivamente mostrati da Sanet e’ piu’ evidente per datasource GAUGE, mentre lo e’ meno per i datasource rate/COUNTER.
3.1.6.1.6.4. Modalita’ di calcolo del rate attuale¶
Per rate attuale si intende l’ultimo rate calcolato da Sanet per un datasource COUNTER.
Sanet mantiene due valori di rate attuale:
- rate istantaneo : Calcolato dagli agenti di monitoraggio in fase di raccolta dei dati. Questo valore e’ piu’ grezzo.
- rate storicizzato: Calcolato da sanet in fase di storicizzazione del dato nel database. Questo valore tende ad essere piu’ mediato e quindi puo’ nascondere anomalie (picchi nel rate) in alcuni casi.
Warning
Questi due valori sono SEMPRE DIVERSI e non e’ predicibile lo scostamento che potrebbero avere.
Warning
nei grafici mostrati da interfaccia Web viene sempre mostrato il rate storicizzato. Il rate istantaneo viene mostrato solo in alcune sezioni dell’interfaccia, per completezza.
3.1.6.1.6.5. Stato di un datasource¶
Dopo che un datasource viene eseguito, il sistema calcola uno stato che rappresenta l’esisto della valutazione. Questi sono gli stati possibili:
STATO Descrizione OK Il valore e’ stato calcolato correttamente. STRANGE VAL Il valore attuale (puntuale o rate al secondo) del datasource non rispetta il range (min_val, max_val) indicato in configurazione. CASCADE Il valor non e’ stato calcolato poiche’ un datasource calcolato prima di questo ha dato errore bloccando l’esecuzione dei successivi. Vedi Ordine di valutazione di datasource e condition. DEPENDSON Tutto il datagroup associato non e’ stato calcolato perche’ dipende da una condition non verificata. Vedi Ordine di valutazione di datasource e condition. UNCHECKABLE Il valore del datasource non e’ stato calcolato correttamente per un errore rilevato durante la raccolta dei dati
3.1.6.1.6.6. Datasource con valori fuori range (STRANGE VAL) e storicizzazione¶
Quando un datasource e’ in stato STRANGE VAL significa che:
- Il valore letto dalla rete non e’ numerico. In questo caso il dato non viene storicizzato.
- Il valore letto e’ fuori dal range min val / max val. In questo caso il dato viene storicizzato, ma in fase di estrazione, il dato viene scartato e considerato nullo.
3.1.6.1.7. Le Condition¶
Rappresenta il controllo puntuale di una condizione (invariante), effettuato sui dati raccolti dalla rete.
I dati raccolti possono essere valori calcolati dai datasource o raccolti direttamente dalla rete.
Una condition e’ caratterizzata dai seguenti attributi:
Parametri informativi
Dato Opzionale Default Descrizione classification si Classificazione priorita’ si n/a Livello di proprita’ di questa condizione. Parametri di Valutazione
Dato Opzionale Default Descrizione expr si Espressione da valutare per la verifica della condizione max tries si 3 numero di check da ripetere prima di considearre la condizione come non verificata primary si no questa condizione e’ da considerare come la condizione principale per il datagroup. Tutte le altre condizioni non vengono elaborate se questa non e’ verificata. La condizione primaria e’ sempre verificata per prima rispetto alle altre. dependson si La valutazione di questa condizione e’ subordinata alla condition specificata. order si 0 Specifica l’ordine di esecuzione delle condition all’interno del datagroup. Subordinato al flag “primary”. cascade si no Se la condition non e’ verificata, tutte le condition valutate successivamente non vengono eseguite. uncheckable-fallback si “UP” o “DN”. Indica se considerare verificata o non verificata una condition quand uncheckable. statuschange-action si Script eseguito ogni volta che avviene un cambio di stato della condition. Vedi Esecuzione di script automatica con variazioni di stato. Parametri per gli allarmi:
Dato Opzionale Default Descrizione upemail si Recipient per gli allarmi di stato UP. Vedi Generazione allarmi e transizioni di stato da UP e DOWN. si Recipient per gli allarmi DOWN (e UP se upemail non e’ valorizzato). Vedi Generazione allarmi e transizioni di stato da UP e DOWN. msg_downsubj si Soggetto per allarmi DOWN. Vedi Generazione allarmi e transizioni di stato da UP e DOWN. msg_downbody si Corpo messaggio allarmi DOWN. Vedi Generazione allarmi e transizioni di stato da UP e DOWN. msg_upsubj si Soggetto per allarmi UP. Vedi Generazione allarmi e transizioni di stato da UP e DOWN. msg_upbody si Corpo messaggio allarmi UP. Vedi Generazione allarmi e transizioni di stato da UP e DOWN.
3.1.6.1.7.1. Espressione e valore di una condition¶
La expr di una condition e’ una espressione per calcolare un valore vero o falso.
Quando il valore di una espressione non puo’ essere calcolato (per un timeout di rete, un errore di sintassi, ecc.) si dice che l’esisto della valutazione di una condition e’ uncheckable.
Si rimanda alla sezioni Expression Language e SANET built-in expression symbols per maggiori dettagli sul linguaggio valido per l’espressione.
Per altri dettagli sulla valutazione della expr si rimanda alla sezione Regole di valutazione di Datasource e Condition.
3.1.6.1.7.2. Condition primary e dependson¶
Quando una condition e’ flaggata come primary il sistema fa dipendere da questa tutte le altre condition dello stesso datagroup e tutti gli altri datagroup associati direttamente all’elemento.
E’ possibile avere una sola condition primary per nodo (elemento di monitoraggio).
I sotto elementi interfacce/storage/servizi/dischi possono avere anche loro una condition primary. In questo caso il sistema crea una catena di dipendenze:
condition primary del nodo
^ ^ ^
| | |
| | `------------- condition dello stesso datagroup
| |
| |
| `-------------------- altri datagroup del nodo
|
|
condition primary del sotto elemento
^ ^
| |
| `------------- condition dello stesso datagroup
|
|
`-------------------- datagroup del sotto elemento
3.1.6.1.7.3. Condition primary, ordine di esecuzione e cascade¶
L’attributo order permette di specificare in quale ordine vengono valutate le condition di uno stesso datagroup.
La condition primary viene sempre e comunque eseguita prima di tutte le altre, indipendentemente, dal valore dell’attributo order.
Quando una condition ha l’attributo cascade impostato a True, se non e’ verificata (valore False) oppure non e’ valutabile (uncheckable) tutte le condition valuate successivamente (con order uguale o maggiore), non vengono eseguite e vanno in stato Depenson (vedi _condition-states:).
3.1.6.1.7.4. Stato di una condition¶
Dopo che una condition viene controllata, il suo stato viene deciso in base al valore restituito dalla sua expr:
- valore true : condition verificata
- valore false : condition non verificata
- errore: condition uncheckable
Questi sono tutti gli stati possibili:
CODICE Titolo Descrizione DN Down Controllo non verificato (tries = max-tries) FA Failing Controllo non verificato (tries < max-tries) UP Up Controllo verificato IN Suspended Stato sospeso DU Depenson UP Controllo dipendente da altro controllo sospeso/uncheckable/down (stato precedente UP) DD Depenson DOWN Controllo dipendente da altro controllo sospeso/uncheckable/down (stato precedente DN) UU Uncheckable UP Controllo non verificabile per errori di rete/timeout/ecc. (stato precedete UP) UD Uncheckable DOWN Controllo non verificabile per errori di rete/timeout/ecc. (stato precedete DN)
Schema delle transizioni di stato possibili:
Note
Le transizioni, all’interno del MACRO STATO UP, da e verso lo stato FA (Failing) sono leggermente semplificate.
Note
Lo stato suspended (IN) puo’ essere raggiunto da un qualsiasi degli altri stati. Gli stati uncheckable (UU, DU, UD, DD)
Per semplificare la gestione delle transizioni che generano allarmi, gli stati di una condition sono raggruppati in MACRO STATI chiamati MACRO UP e MACRO DOWN (lo stato SOSPESO e’ uno stato a parte).
Sanet genera allarmi quando lo stato di una condition passa da un qualunque stato appartenente al macro stato UP a qualunque stato appartenente al macro stato DOWN o viceversa.
CODICE Nome MACRO STATO UP Up UP UU Uncheckable UP UP DU DependsON UP UP FA Failing UP DN Down DOWN DD DependsON DOWN DOWN UD Uncheckable DOWN DOWN IN Sospeso SOSPESO
Per semplificazione, quando lo stato di una condition e’ uno qualunque di questi, la condition e’ considerata virtualmente UNCHECKABLE (UN):
- Uncheckable UP (UU)
- Dependson UP (DU)
- Uncheckable DOWN (UD)
- Dependson DOWN (DD)
Important
Questa semplificazione e’ puramente concettuale, in virtu’ del fatto che se una condition si trova in un uno di questi stati, significa la sua valutazione non e’ stata verificata con certezza (timeout, errori di rete, errori nella expr, ecc.), al contrario di quando si trova in stato UP, DOWN, FA o SOSPESO.
3.1.6.1.7.5. Ultima variazione significativa¶
Alcune variazioni di stato intermedie di una condition potrebbero essere cosi’ frequenti da essere poco significative.
Sanet tiene traccia di quella che viene definita l’ultima variazione significativa.
Una variaizone di stato e’ significativa quando lo stato di una condition passa da uno stato MACRO UP , MACRO DOWN o Sospeso.
In particolare Sanet ricorda:
- L’orario dell’ultima variazione significava
- Lo stato precedente al momento dell’ultima variazione significativa.
Important
la data di ultimo cambiamento di stato o la data dell’ultima variazione sono visualizzate in diversi punti dell’interfaccia grafica, alcuni regolabili da configurazione utente.
3.1.6.1.7.6. Uncheckable fallback¶
Quando la valutazione di una condition non e’ possibile (per errori di rete, timetout, ecc.), l’esito della valutazione e’ considerato uncheckable (non verificabile).
Quanto l’esito e’ uncheckable, lo stato assegnato di una condition puo’ passare a Uncheckable UP (UU) o Uncheckable DOWN (UD), a seconda dello stato precedente (vedi schema nel paragrafo Stato di una condition).
Il parametro uncheckable-fallback serve ad indicare se la condition deve essere considerata verificata o non verificata se la valutazione della condition e’ uncheckable.
Warning
Non confondere esito della valutazione (verificato/non verificato) con stato della condition.
I valori ammessi sono:
- UP - Considera la condition come verificata.
- DN - Considera la conditonn come non verficata.
Esempio
Ipotizziamo di avere una condition in stato UP.
Sanet valuta la condition e calcola come esito della valutazione il valore uncheckable.
Se il parametro uncheckable fallback non e’ impostato:
- Lo stato della condition passa da UP a Uncheckable UP (UU).
Se il parametro uncheckable fallback e’ impostato a UP:
- La condition viene considerata come verificata.
- Lo stato della condition resta in UP.
Se il parametro uncheckable fallback e’ impostato a DN:
- La condition viene considerata come non verificata.
- Lo stato della condition passa da UP a FA o DN (a seconda del parametro max-tries).
3.1.6.1.7.7. Messaggi di allarme¶
Quando Sanet deve generare un allarme in seguito ad DOWN (o UP) di una condition, utilizza i dati di configurazione della condition per produrre un messaggio composto da:
- destinatario (indirizzo email/alias valido)
- soggetto
- corpo del messaggio
I valori di questi parametri vengono specificati attraverso specificati dai campi di testo:
- upemail e email
- msg_upsubj e msg_upbody
- msg_downsubj e msg_downbody
Il testo dei campi msg_upsubj, msg_upbody, msg_downsubj, msg_downbody possono contenere wildcard speciali per aggiungere automaticamente al testo informazioni di sistema.
Si rimanda alla sezione Gestione Messaggi/Allarmi.
3.1.6.1.8. Esecuzione di script automatica con variazioni di stato¶
Il parametro statuschange-action e’ una stringa che permette di specificare uno programma/script esterno da eseguire ogni volta che una condition cambia di stato.
La stringa deve contenere il path del programma/script esterno da eseguire seguito da eventuali parametri di esecuzione.
Esempi di stringe valide:
action1.shaction1.sh -t 10 -p "param with spaceses"/usr/local/action1.sh -t 10 -p "param with spaceses"
Il path del programma/script da eseguire puo’ essere:
- Assoluto:
- Esempio: /usr/share/scripts/action.sh
- Relativo:
- Lo script verra’ cercato all’interno della directory specificata dal parametro di configurazione SANETD_EXEC_DIR
- Esempio:
action2.shh -> {{SANETD_EXEC_DIR}}/action2.sh
- Esempio:
prova/action1.sh -> {{SANETD_EXEC_DIR}}/prova/action1.sh
Important
di default SANETD_EXEC_DIR punta alla directory {{VAR_DIR}}/_action_scripts. Questa directory non viene creata automaticamente.
Warning
il programma/script esterno viene eseguito con i permessi del processo del server di Sanet (root)
3.1.6.1.8.1. Action UUID¶
Ad ogni esecuzione di script esterni Sanet associat un UUID univoco generato al momento dell’esecuzione.
Questo permette di identificare univocamente ogni singola esecuzione.
3.1.6.1.8.2. Passare dati di “input” al processo esterno¶
E’ possibile passare dati al processo da eseguire in due modi:
- Parametri a riga di comando
- Variabili d’ambiente
3.1.6.1.8.3. Parametri a riga di comando¶
Sono specificati insieme al path del programma nella stringa statuschange-action.
action1.sh -t 10 -p "param with spaceses" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Il primo parametro dei parametri a riga di comando ($0 per le shell) contiene il path completo del programma/script eseguito.
3.1.6.1.8.4. Variabili di ambiente¶
Sono variabili create da Sanet nel contesto di esecuzione del processo ed hanno il prefisso SANET_.
Queste sono le variabili d’ambiente disponibili:
Variabile d’ambiente Descrizione SANET_ACTION_UUID UUID univoco di esecuzione SANET_TENANT_NAME Nome del tenant SANET_TENANT_UUID UUID del tenant SANET_NODE_UUID UUID del nodo associato alla condition SANET_NODE_NAME Nome del nodo associato alla condition SANET_ELEMENT_UUID UUID dell’elemento di monitoraggio associato alla condition SANET_ELEMENT_NAME Nome dell’elemento di monitoraggio associato alla condition SANET_CONDITION_UUID UUID della condition SANET_CONDITION_PATH Path della condition SANET_CONDITION_LASTCHANGE Timestamp con la variazione di stato della condition SANET_CONDITION_NEW_STATE Stato corrente della condition SANET_CONDITION_OLD_STATE Stato precedente della condition
3.1.6.1.8.5. Modalita’ di esecuzione dello script¶
Il programma/script esterno viene eseguito da server principale come processo parallelo ed assolutamente indipendente.
Warning
Il server centrale non controlla/attende la terminazione del processo eseguito prima di elaborare altri dati.
Warning
Lo stesso script potrebbe essere eseguito piu’ volte in parallelo. Problemi di concorrenza devono essere gestiti dallo script.
Warning
Il processo esterno e’ indipendente e la sua esecuzione non si interrompe anche se il server di Sanet viene fermato/ravviato.
3.1.6.1.8.6. Output del processo esterno¶
Il processo esterno viene eseguito come demone e per tanto il suo stdout e stderr non sono collegati a nessuno stream (file).
Se il processo esterno deve produrre dati in output deve utilizzare le funzioni di shell o altre api per salvare questi dati:
- logger (syslog)
- cat, echo, tee, ecc.
3.1.6.1.9. Regole di valutazione di Datasource e Condition¶
3.1.6.1.9.1. Valutazione di una expr¶
La valutazione di una expr di una condition o di un datasource avviene sempre seguendo le stesse regole.
A seconda che si stia valutando la expr di una condition o di un datasource possono cambiare i simboli (variabili $foo) utilizzabili che Sanet prepara al momento dell’esecuzione. Si rimanda alla sezione SANET built-in expression symbols.
La valutazione di expr puo’ restiture due tipi di risultati:
- un valore null o None (risultato UNCHECKABLE)
- un qualunque valore numero intero, numeroi virgola mobile, stringa di byte o booleano (vero/falso)
Quando si parla di expr di una condition, la valutazione dell’espressione si considera verificata se il valore prodotto e’:
- diverso da null
- numerico <> 0
- stringa di byte diversa da stringa vuota (‘’)
- true (booleano)
3.1.6.1.9.2. Valori correnti e valori precedenti¶
A volte e’ necessario effettuare dei controlli confrontando dati / valori (calcolati e/o letti via rete) al momento dell’esecuzione con gli stessi dati/valori calcolati al check precedente.
Sanet distingue due tipi di valori al momento dell’esecuzione:
- correnti : sono i dati calcolati al momento del check (OID SNMP, valori prodotti da chiamate a funzione, ecc.)
- precedenti (o old): sono i dati calcolati/raccolti dalla expr durante check precedente.
Quando Sanet valuta una espressione, i valori correnti che sono stati calcolati con successo (ovvero senza errori che causano lo stato uncheckable), vengono salvati in attesa del check successivo. Al check successivo verranno considerati valori precedenti.
Note
Quando una expr contiene il riferimento a valori precedenti e viene eseguita per la prima volta, l’espressione viene eseguita ma l’esito della valutazione produce un valore nullo, ovvero UNCHECKABLE.
Esempio:
sanet-manage exec_expr phink0 '1.3.6.1.2.1.1.1.0#'
VALUE: None
INFOS:
Warning
se una expr referenzia (in qualche modo) solo valori precedenti senza referenziare/produrre anche valori correnti, l’esisto della valutazione sara’ perennemente UNCHECKABLE.
Esistono tre modi per poter utilizzare valori correnti/precedenti nelle expr di Sanet:
Quando la expr di un datagroup viene valutata con successo Sanet memorizza:
- l’istante temporale dell’ultimo check valido.
- il valore associato all’ultimo check valido.
Puo’ essere utile valutare quanto tempo e’ passato dall’ultima volta che una espressione e’ stata calcola senza errori e usare questa informazione come parametro aggiuntivo per effettuare un controllo.
All’interno di una expr il simbolo $delta memorizza il tempo trascorso dall’ultimo check avvenuto con successo. Il valore e’ memorizzato in secondi in virgola mobile (es. 1.3 secondi, 0.003 secondi, ecc.)
Questo e’ uno schema di come viene calcolato il parametro $delta al momento del check in base all’esito del check precedente.
1 2 3 4 5 6
TEMPO ----|---------|----------|----------|----------|-----------|------------> secondi
CHECK OK UNCHECK UNCHECK UNCHECK OK ...
expr
$delta |----1----|
|----------2---------|
|-----------------3-------------|
|---------------------4--------------------|
|-----1-----|
I datasource di tipo COUNTER utilizzano il valore del parametro $delta e il valore precedente per calcolare il rate istantaneo.
Important
il rate istantaneo calcolato dopo una valutazione UNCHECKABLE puo’ essere molto impreciso in virtu’ della logica di aggiornamento del $delta e del valore precedente descritta nel paragrafo precedente.
Esempio: sequenza di valutazioni di un datasource COUNTER:
1 2 3 4 5 6
TEMPO ----|-------|--------|--------|--------|---------|-----> secondi
check expr
(valore corrente) 1 5 8 UNCHECK 10 11
$delta n/a 1 1 1 2 1
valore precedente n/a 1 5 8 8 10
rate istantaneo n/a 4/s 3/s 3/s(*) 1/s 1/s (*) rate non aggiornato
(new-old)/$delta
Sanet implementa un meccanismo build-in per gestire i valori correnti/precedenti letti dalla rete attraverso SNMP.
Per sfruttare questo meccanismo bisogna utilizzare una sintassi particolare nelle expr.
<OID expr> @ Valore corrente (letto via rete)
<OID expr> # Valore precedente
Esempio:
1.3.6.1.2.1.1.1.0@
1.3.6.1.2.1.1.1.0#
Per i dettagli sulle regole di composizione delle espressioni SNMP si rimanda alla sezione: SNMP Sub-expressions.
Esistono funzioni che permettono di calcolare un valore al momento di un check e utilizzare quel valore al check successivo.
Ad esempio:
- saveval e getlastval.
- exec.
- …
Si rimanda all’elenco completo SANET standard expression functions.
Il valore calcolato di un datasource o il valore precedente di un datasource puo’ essere utilizzato nelle expr usando la seguente sintassi:
{ <nome> @ } Valore del datasource calcolato dal sistema al momento di check del datagroup.
{ <nome> # } Valore del datasource check precedente del datagroup.
Danger
Assicuratevi di non referenziare entrambi i valori nella stessa expr del datasource stesso. Esempio:
{ds1@} + {ds2@}
Important
Bisogna fare attenzione all’ordine di esecuzione dei datasource e condition altrimenti si rischia di referenziare valori non ancora calcolati.
E’ possibile sapere e utilizzare il tempo di check di una condition o di un datasource utilizzando la seguente sintassi:
{ <nome>.checktotaltime @ } Tempo di elaborazione
{ <nome>.checktotaltime # } Tempo di elaborazione al check precedente
Important
Bisogna fare attenzione all’ordine di esecuzione dei datasource e condition altrimenti si rischia di referenziare valori non ancora calcolati.
Danger
Se un datagroup contiene un datasource e una condition con lo stesso nome ci possono essere dei problemi di incoerenza con i valori effettivamente utilizzati.
3.1.6.1.9.3. Valori dei datasource usati nelle expr¶
All’interno di un datagroup, una condition puo’ (ma non obbligatoriamente) verificare una condizione basandosi su:
- Un valore raccolto raccolto/calcolato dalle rete (es: valore traffico in input su una interfaccia raccolto via protocollo SNMP)
- il valore corrente di uno o piu’ datasource del medesimo datagroup.
Schema:
DATAGROUP
|
+----------+----------+--------+-------+----------+-----------+
| | | | | |
ds1 ds2 ds3 c1 c2 c3
| | ^ | ^ || | |
| | `--------+ `-------------+| | |
| | | | |
GET script.sh GET GET GET
SNMP SNMP SNMP SNMP
3.1.6.1.9.4. Ordine di valutazione di datasource e condition¶
Quando viene valutato un datagroup (non e’ sospeso), l’ordine di valutazione e’ stabilito nel seguente modo:
- Step 0: verifica se la condition da cui dipende questo datagroup e’ verificata o meno (vedi Condition primary e dependson).
- Step 1: Calcola tutti i datasource ordinati in base al loro attributo “order”
- Se un datasource non e’ verificato ed e’ l’attributo cascade e’ true, viene interrotta la valutazione di tutti i datasource successivi.
- Step 2: Verifica tutte le condition
- Viene valutta la condition primaria.
- Se la condition primaria non e’ verificata, tutte le condition successive non vengono valutate e passano in stato dependson (Up o Down in base al loro stato attuale).
- Vengon valutate le condition non primarie (l’ordine non e’ predefinito).
Important
Se all’interno del datagroup sono presenti piu’ condition primarie, non e’ predicibile quale verra’ valutata per prima e quali saranno le altre condition (anche primarie) a passare in stato dependson.
3.1.6.1.10. Parametri opzionali¶
I parametri opzionali permettono di definire variabili utilizzabili nel calcolo delle espressioni (attribugo expr) di datasource e condition.
Ogni parametro e’ definito tre attributi:
nome: stringa che identifica il parametro. All’interno di un datagroup il nome e’ univoco.
tipo: indica il tipo di parametro. Esistono i seguenti tipi di parametri:
- numero: numero (in virgola mobile)
- stringa: sequenza di caratteri
- boolean: valore booleano vero o falso
3.1.6.1.10.1. I parametri nelle espressioni¶
Ogni parametro viene richiamato all’interno delle espressioni di datasource e condition utilizzando la seguente sintassi:
$<nome>
Esempio: Se in un datagroup e’ definito il parametro url, in una espressione (di datasource o condition) viene utilizzato cosi:
urlContentMatches( $url )
Se una espressione richiama un parametro non definito nel datagroup, la valutazione dell’espressione viene interrotta e il valore dell’espressione e’ uncheckable.
3.1.6.1.11. Timegraph¶
I timegraph permettono di creare grafici temporali utilizzando serie di dati (ma non necessariamente) calcolate sui valori dei datasource di un datagroup.
Un timegraph viene rappresentato utilizzando un piano con due assi ortogonali: l’asse delle ascisse (orizzontale) rappresenta il tempo, mentre l’asse delle ordinate (verticale) rappresenta i valori delle serie definite.
E’ possibile define un numero illimitato di timegraph in un datagroup.
Ogni timegraph e’ caratterizzato dai seguenti attributi:
Attributo Default Descrizione name Nome del timegraph (deve essere univoco all’internod el datagroup) title Titolo descrittivo del timegraph primary no Flag che indica se il timegraph e’ un timegraph primario (vedi sotto) stacked si Indica se il timegraph puo’ ylegend Stringa usata per indicare l’unita’ di misura dell’asse delle ordinate. classification (facoltativo) Permette di indicare una classificazione per il timegraph
3.1.6.1.11.1. Timegraph primario¶
Quando un timegraph ha il flag primary attivo (valore si o true) il timegraph e’ detto timegraph primario.
Quando viene visualizzata la pagina web di un elemento (nodo, interfaccia, disco, servizio, device) il sistema individua il timegraph primario e lo visualizza all’internod ella pagina.
Note
Il sistema non controlla se piu’ di un timegraph appartenenti allo stesso elemento e’ impostato come primario. Se piu’ di un timegraph e’ definito come primario, il sistema scegliera’ uno qualunque di questi e lo visualizzera nella pagina web.
3.1.6.1.11.2. Serie¶
Per poter visualizzare dei dati in un timegraph e’ necessario definire le sue serie dati.
Una serie indica quali dati (valori temporali) rappresentare e come devono essere rappresentate (colore, descrizione, ecc.)
I valori di una serie possono essere calcolati utilizzando i valori temporali di un datasource o i valori di altre serie dello stesso timegraph.
Gli attributi di una serie sono:
Timegraph Default Descrizione name Nome della serie (deve essere univoco) legend Descrizione usata per la leggenda color (facoltativo) Stringa con la codifica del colore style Stile grafico per rappresentare la serie render order (facoltativo) Numero progressivo l’ordine di visualizzazione della serie nel grafico variable value Nome del datasource da cui ricavare i dati computed value expr Espressione per calcolare i valori della serie usando le altre serie dati
Codifica dei Colori
Per indicare il colore di una serie bisogna usare la seguente sintassi:
#<codifica esadecimale RGB>
Esempi:
#ff0000 Rosso #00ff00 Verde #0000ff Blue #ffff00 Giallo #ffffff Bianco #000000 Nero
Stili
Sono definiti i seguenti stili per una serie:
Stile Descrizione line La serie viene rappresentata da una linea (continua) area La serie viene rapppresentata da una area colorata limitata superiormente dai valori della serie. tick Vengono visualizzate delle linee verticali in corrispondenza dei valori della serie > 0 invisible La serie e’ definita ma non viene visualizzata (nemmeno la leggenda)
3.1.6.1.11.3. Serie da datasource o calcolate¶
Come gia’ detto nei paragrafi precendenti, i valori di una serie possono essere calcolati:
- utilizzando i valori temporali di un datasource dello stesso datagroup. In questo caso sono chiamate serie normali.
- utilizzando i valori di altre serie dello stesso timegraph. In questo caso sono chiamate serie calcolate.
Esempio di serie normale: Se nel datagroup e’ definito il datasouce rttmax, per usarlo nella serie e’ sufficiente indicare come valore dell’attributo variable value:
rttmax
Esempio di serie calcolata: Se nel timegraph sono definite due serie chiamate rttmax_serie e rttmin_serie:
sqrt( avg(rttmax_serie, rttmin_serie) + 3.14 )
Note
Quando in un timegraph sono indicate serie di entrambi i tipi, prima vengono calcolate tutte le serie normali e poi tutte le serie calcolate.
Note
Se il sistema non e’ in grado di calcolare un valore per una serie calcolata per un preciso istante temporale (asse x), il valore calcolato e’ nullo e non viene rappresentato nel grafico.
La sintassi per comporre le espressioni di serie calcolate e’ simile a quella di qualunque funzione matematica. L’espressione puo’ contenere:
- numeri
- operatori matematici: + , -, *, / , ec
- funzioni: f(…), sin(….), max( … ), iftrue( … )
- variabili: stringhe di testo che rappresentano un valore.
Esistono due tipi di variabili:
- variabili che si riferiscono a serie
- variabili speciali o built-in ricalcolate ogni volta che deve essere calcolato un singolo valore della serie.
Per maggiori dettagli come vengono calcolate le serie calcolate e su quali funzioni e quali variabili sono utilizzabili si rimanda alla sezione Timegraphs.
3.1.6.1.12. Sospensione e Riattivazione di un datagroup¶
La valutazione dei datagroup (di una qualunque entita’ monitorata) puo’ essere sospesa. Esistono due tipi di sospensioni:
- provvisoria: si deve indicare la timeline oltre la quale viene riattivato il monitoraggio del datagroup
- permanente: il monitoraggio del datagroup deve essere riabilitato manualmente.
Con la definizione sospendere un nodo si intende dire che si sospendono tutti i datagroup associati al nodo e alle sue sotto-entita’.
3.1.6.2. Configurazione avanzata dello scheduling¶
3.1.6.2.1. Scheduling di base (best effort)¶
Quando non specificato diversamente, i datagroup vengono schedulati per essere eseguiti ogni minperiod.
Esiste sempre un lieve overhead di elaborazione per cui l’istante di scheduling non corrisponde esattamente all’istante di inizio elaborazione.
Una volta che un agente di monitoraggio termina di elaborare (esegue) un datagroup, viene ri-schedulato calcolando l’istante temporale ( next time ) usando la semplice formula:
next_time = now + minperiod
Esempio: Datagroup con minperiod di 60 secondi (nota: nel grafico viene evidenziato il ritardo di esecuzione rispetto allo scheduled time)
Questo sistema di scheduling e’ il sistema di default.
Questo sistema e’ molto semplice da configurare, ma presenta il seguente problema: diversi datagroup per uno stesso nodo/cluster possono essere eseguiti nello stesso istante in parallelo causando aumento di carico sul nodo target.
Esempio: Nel seguente schema indichiamo la sequenza temporale di elaborazione di 3 datagroup (A,B,C) con tre minperiod diversi. Si possono notare dei momenti di esecuzione concorrente.
3.1.6.2.2. Scheduling avanzato: gestione di Scheduling Group¶
Uno scheduling group rappresenta logicamente un gruppo di datagroup che devono essere schedulati cercando di rispettare vincoli temporali precisi.
Esistono tre tipi di scheduling group che Sanet e’ in grado di gestire e si distinguono dal modo con cui vengono configurati:
- Specificare parametri di scheduling a livello di elemento di monitoraggio (a livello di nodo, o singolo sotto-elemento)
- In questo caso si dice che lo scheduling group e’ definito implicitamente a livello di elemento.
- Specificare parametri di scheduling a livello di cluster.
- In questo caso lo scheduling group e’ definito implicitamente a livello di cluster.
- Definire uno scheduling group ed assegnare singoli datagroup (anche di nodi diversi) o elementi di monitoraggio allo scheduling group.
- In questo caso la configurazione dello scheduling group e’ comune a tutti gli elementi esplicitamente assegnati allo scheduling group.
Important
La gestione dello scheduling per ogni scheduling group ignora completamente l’elemento di appartenenza del datagroup. E’ possibile configurare il sistema per gestire i datagroup (tutti o solo alcuni) di un nodo tramite uno scheduling group (esplicito o implicito) ed assegnare comunque i datagroup dei sotto-elementi ad altri scheduling group (impliciti o espliciti).
3.1.6.2.2.1. Parametri di scheduling¶
Il min-gap inidica la distanza minima (in secondi) che deve esistere in fase di scheduling (NON DI ESECUZIONE) tra due datagroup dello stesso scheduling group.
Specificare il valore 0 significa schedulare i datagroup uno dietro l’altro senza alcun gap aggiuntivo.
Esempio: Gruppo di due datagorup in un gruppo con min-gap impostato (10 secondi).
Note
In pratica, il min-gap serve per regolare il rate di datagroup da eseguire nel tempo.
Warning
Poiche’ il min-gap viene utilizzato per calcolare il momento di scheduling successivo, da solo non evita l’esecuzione in parallelo di datagroup dello stesso gruppo. Vedi max-parallel.
Il tempo massimo di esecuzione di un datagroup non e’ mai certo e potrebbe capitare che l’esecuzione di due datagroup di uno stesso gruppo (anche se schedulati in istanti temporali diversi in base al min-gap) si sovrapponga,
Il parametro max-parallel serve per obbligare il sistema a limitare il numero massimo di datagroup lanciati in esecuzione contemporaneamente.
Quando arriva il momento (scheduled time) di eseguire un datagroup appartenente ad un gruppo, se e’ gia’ stato raggiunto il limite indicato max-parallel, l’agente di monitoraggio mette in attesa (accorda) il datagroup finche’ un qualunque altro datagroup dello stesso gruppo non termina l’esecuzione.
Al termine dell’esecuzione del datagroup corrente, il sistema controlla la coda di esecuzione e verifica quanti datagroup in attesa lanciare.
Specificare il valore 1 significa impedire l’esecuzione in parallelo di due datagroup dello stesso gruppo.
Note
Il numero massimo di datagroup eseguiti in parallelo da un agente e’ pari al numero di thread configurati per l’agente. E’ inutile configurare max-parallel con un numero superiore al numero di thread per agente.
Warning
Impostare un valore per max-parallel potrebbe causare una attesa eccessivamente lunga per i datagroup pendenti. Per forzare comunque lo “sblocco” di piu’ datagroup pendenti si puo’ configurare max-deadline.
Numero massimo di secondi oltre il quale non e’ comunque possibile tenere in attesa un datagroup bloccato all’interno di un gruppo ( a causa del parametro max-parallel ) rispetto all’istante di scheduling.
Warning
configurand max-deadline il sistema potrebbe eseguire comunque in parallelo alcuni datagroup dello stesso gruppo.
Esempio 2: Esecuzione con min-gap (linea gialla) e max-deadline (linea viola) configurati. Come si puo’ vedere, in fase di wakeup dei datagroup in pending, max-deadline forza comunque l’esecuzione del datagroup B e anche di C poiche’ il max-deadline di C e’ stato superato.
3.1.6.2.2.2. Calcolo del momento di scheduling: min_period e min_gap¶
Quando un datagroup termina la sua esecuzione, il sistema deve calcolare il prossimo momento di esecuzione.
Il sistema cerca di schedulare il datagroup partendo dal suo min-period.
Se l’istante di scheduling calcolato e’ troppo vicino (min_gap) ad quello di un altro datagroup dello stesso gruppo, il tempo viene aumentato fino a trovare un istante temporale che non crei sovrapposizioni.
Warning
il parametro max-deadline non viene MAI considerato in questa fase (scheduling), ma solo nella fase di esecuzione o sblocco.
Esempio:
3.1.6.2.2.3. Parametri di scheduling a livello di agente¶
È possibile definire una configurazione di scheduling generale per ogni agente di monitoraggio.
Tutti i controlli dei nodi associati da un agente verranno gestiti applicando i parametri di scheduling impostati per quell’agente, solo se:
- non e’ gia’ presente una parametrizzazione di scheduling più specifica nel cluster a cui il nodo appartiene.
- non e’ gia’ presente una parametrizzazione di scheduling più specifica per il singolo nodo/sotto-elemento/datagroup.
I parametri di scheduling configurati a livello di agente utilizzati per creare automaticamente dei “gruppi di scheduling” nel seguente modo:
- Tutti i controlli (datagroup) di tutti i nodi appartenenti ad uno stesso cluster vengono raggruppati e schedulati insieme nello stesso gruppo (gruppo automatico del cluster).
- Tutti i controlli di nodo non appartenente a nessun cluster, vengono raggruppati e schedulati insieme (gruppo automatico del nodo).
3.1.6.2.2.4. Scheduling iniziale (avvio dell’agente)¶
Se sono stati configurati parametri di scheduling, all’avvio l’agente organizza temporalmente i controlli coerentemente ai parametri specificati.
In particolare tutti I controlli di un “gruppo di scheduling” vengono schedulati/intervallati rispettando il min_gap del gruppo.
3.1.6.2.2.5. Configurazione¶
- Configurazione da CLI: Scheduling Group.
3.1.7. Template di Configurazione¶
3.1.7.1. Datagroup template¶
Un datagroup-template permette di specificare il valore di tutti i parametri di configurazione che un datagroup dovra’ avere.
Il datagroup-template definisce:
- Gli attributi/campi del datagroup
- i datasource e tutti i loro attributi/campi
- le condition e tutti i loro attributi/campi
- i parametri opzionali
- i timegraph e tutti i loro attributi/campi e le serie
3.1.7.1.1. Nome di un datagroup-template¶
Ogni datagroup-template e’ identificato da un nome univoco.
Il nome di un datagroup-template deve rispettare la seguente espressione regolare:
^[a-zA-Z0-9][a-zA-Z0-9-_]*$
3.1.7.1.2. Gerarchia di template¶
E’ possibile creare un datagroup-template a partire da un datagroup-template gia’ definito; in questo caso il primo e’ chiamato datagroup-template figlio, mentre il secondo e’ chiamato datagroup-template padre.
Quando un datagroup-template viene definitio a partire da un datagroup-template esistente e’ possibile:
- sovrascrivere il valore di uno degli attributi del datagroup-template.
- sovrascrivere il valore degli attributi dei datasource/condition/timegraph/parametro gia’ esistente.
- aggiungere nuovi datasource/condition/timegraph/parametro a quelli gia’ definiti.
Esempio di gerarchia e modifica di attributi:
3.1.7.1.3. Attributo “deleted”¶
Il sistema di eriditarieta’ e’ di tipo additivo, ovvero e’ possibile SOLO aggiungere nuovi elementi (condition/datasource/ecc.) ad un datagroup-template che si sta estendendo.
Puo’ succedere che un determinato datagroup-template non sia applicabile esattamente ed interamente ad un elemento monitorabile. Alcuni datasource o condition potrebbero non avere senso o non essere applicabili (perche’ l’apparto non implementa alcune MIB SNMP, ecc.).
Poiche’ non si puo’ definire un datagroup-template con l’intenzione di togliere attributi/sotto-elementi, si puo’ risolvere il problema in due modi:
- Definire un datagroup-template nuovo che non definisce i datasource/condition non applicabili.
- Estendere un datagroup-template gia’ esistente marcando alcune sotto-entita’ come deleted.
Quando una condition/datasource/ecc. e’ marcato come deleted viene semplicemente ignorato dal monitoraggio.
3.1.7.1.4. Configurazione¶
- CLI: si rimanda alla sezione: Datagroup Template
- WEB: La configurazione via web dei template non e’ disponibile.
3.1.7.2. Configurazioen locale e Library¶
I datagroup-template si possono dividere in due tipologie:
- locali : sono definiti solo in un particolare tenant.
- library : sono definiti globalmente nel sistema e sono utilizzabili in tutti i tenant.
I datagroup-template della library sono indentificati univocamente dal nome in tutta l’installazione.
I datagroup-template definiti nel tenant sono identificati dal nome che e’ univoco solo all’interno del tenant. Due tenant diversi possono definire datagroup-template locali con lo stesso nome, ma completamente diversi.
I datagroup-template locali ad un tenant possono estendere/sovrascrivere i datagroup-template nella “library”, ma non viceversa.
Important
Ogni volta che in un tenant si vuole estendere un datagroup-template definito in “library”, il sistema crea automaticamente nel tenant un datagroup-template “locale” con lo stesso nome che eredita quello definito nella library.
Important
Il sistema non permette di creare datagroup-template “locali” con lo stesso nome di datagroup-template nella “library”.
Important
La definizione di datagroup-template nella library ha senso se si intendere “riutilizzare” lo stesso datagroup-template in tenant diversi o in altre installazioni, ma e’ possibile configurare un intero sistema senza utilizzare la library. E’ una scelta possibile. Spetta all’amministratore del sistema decidere cosa deve o non deve essere memorizzato nella library.
3.1.7.2.1. Configurazione¶
- CLI: si rimanda alla sezione: Configurazione Library
- WEB: La configurazione via web dei template non e’ disponibile.
3.1.7.3. Assegnare un datagroup-template ad un elemento di monitoraggio¶
Quando associo un datagroup-template ad un elemento di monitoraggio(nodo, interfaccia, ecc.), sto creando una istanza di quel template, ovvero sto creando un datagroup.
Ogni datagroup (istanza di un datagroup datagroup-template) ha un nome che puo’ essere:
- un nome uguale a quello del datagroup-template corrispondente.
- un nome personalizzato.
Per ogni elemento di monitoraggio, il nome dei datagroup istanziati deve essere univoco.
Note
Ci puo’ essere un solo datagroup con nome uguale a quello del suo datagroup-template; altri datagroup istanziati dallo stesso datagroup-template dovranno specificare per forza un nome personalizzato.
E’ possibile istanziare (associare) un datagroup-template in un elemento di monitoraggio in due modi:
- associare direttamente il datagroup-template all’elemento di monitoraggio: Datagroup diretti.
- Utilizzare un element template: Element template.
3.1.7.3.1. Datagroup diretti¶
I datagroup template associati direttamente ad elementi di monitoraggio creano i datagroup diretti.
I datagroup diretti possono essere personalizzati modificando i singoli attributi del datagroup o i parametri opzionali.
Important
non e’ possibile aggiungere definizione di datasource/condition/timegraph ad un datagroup.
3.1.7.3.1.1. Configurazione¶
- CLI: Si rimanda alla sezione: Datagroup diretti.
- WEB: non disponibile
3.1.7.4. Element template¶
Un element template permette di specificare un blocco di configurazione che deve essere applicata in elememento di monitoraggio.
E’ possibile create element template per ogni tipologia di elemento monitorabile:
- node template
- interface template
- storage template
- service template
- device template
Un element template permette di specificare:
un elenco di datagroup da creare automaticamente per elemento di monitoraggio, indicato quali datagroup-template assegnare e con quale nome. Vedi Datagroup all’interno di un elemente template.
parametri di configurazione specifici per la tipologia di entita’ corrispondente al template (flags, xform, distinguisher, ecc.)
un elenco di sotto-elementi (interfacce, dischi, servizi, device) che devono essere creati automaticamente in fase di assegnamento del template all’elemento di monitoraggio.
- Questo e’ possibile solo per i node template. Vedi Sotto-elementi all’interno di un node-template.
E’ possibile associare piu’ di un element template alla stessa entita’ di monitoraggio.
Important
Eventuali conflitti verranno segnalati e/o impediti: (A) a datagroup con lo stesso nome definiti in due element template associati alla stessa entita; (B) conflitti tra nomi di sub-entita’ definite nei nodi o in node-template gia’ applicati.
3.1.7.4.1. Datagroup all’interno di un elemente template¶
All’interno di un element template ogni datagroup da creare viene specificato indicando il datagroup template e facoltativamente, il nome con cui istanziarlo (per evitare nomi duplicati invalidi)
datagroup-template element-template +-------------------+ | | +-----------+ | +-----------+ | | ta |---------+----------->| ta | | +-----------+ | | +-----------+ | | | | | | +-----------+ | +----------->| ta2 | | | +-----------+ | | | +-----------+ | +-----------+ | | tb | -------------------->| tb | | +-----------+ | +-----------+ | | | +-------------------+
Per ogni datagroup specificato e’ possibile svorascrivere i parametri di configurazione previsti dal datagroup-template (datasource, condition, parametri opzionali).
Note
non e’ possibile aggiungere nuovi datasource/datagroup/timegraph ad un datagroup all’interno di un element template.
In questo schema riassumiamo lo schema di ereditarieta’/associazione di datagroup-template agli elementi di monitoraggio:
3.1.7.4.2. Applicare template multipli¶
E’ possibile applicare piu’ di un element template allo stesso elemento di monitoraggio.
Important
se due element template dichiarano di utilizzare lo stesso datagroup template, e vengono applicati alla stessa entita’, il sistema crea due datagroup distinti e non effettua alcun controllo sulla presenza di due due datagroup simili nella configurazione generata.
3.1.7.4.3. Node template¶
I node template permettono di specificare (oltre ad un elento di datagroup-template) alcuni attributi specifici del nodo:
- flag swtich
- flag router
Si rimanda alla sezione Monitoraggio dei nodi per dettagli sul siggnificato di questi due flag.
3.1.7.4.4. Sotto-elementi all’interno di un node-template¶
All’interno di un node-template e’ possibile specificare quali entita’ devono essere automaticamente create quando il template viene applicato al nodo.
E’ possibile specificare uno o piu’ sotto-elementi per ogni tipologia di entita’ di monitoraggio che e’ possibile definire dentro ad un nodo:
- interfacce
- storage
- service
- device
Per ogni sotto-elemento che si vuole specificare all’interno di un node template, e’ possibile specificare:
- nome dell’entita
- distinguisher
- xform
- uno o piu’ element template da applicare all’entita’ creata.
Important
non e’ possibile specificare per le sotto entita’ dei datagroup singoli o personalizzare i parametri dei datagroup template associati agli element template indicati, ma e’ possibile cambiare le parametrizzazioni per ogni elemento a livello di configurazione di nodo.
Warning
il sistema impedisce che si creino conflitti tra i nomi delle entita’ create automaticamente in base alla definizione di un template applicato ad almeno un nodo ed i nomi delle entita’ create manualmente all’interno di quel nodo. I comandi di configurazione che generano conflitti verrano annullati con un errore.
3.1.7.5. Configurazioni specifiche dei sotto-elementi definiti nei node-template¶
La configurazione di elementi generati in base alla definizione specificata in un node-template puo’ essere modificata:
- aggiungendo il riferimento ad altri element template direttamente all’oggetto del monitoraggio.
- aggiungendo altri datagroup-template diretti all’oggetto del monitoraggio.
3.1.7.5.1. Configurazione¶
- CLI: si rimanda alla sezione: Element Template
- WEB: La configurazione via web dei template non e’ disponibile.
3.1.7.6. Configurazione di datagroup template, element template ed elementi¶
Come descritto nei paragrafi precedenti, un datagroup template puo’ essere istanziato partendo da un datagroup template in due modi:
- Associando il datagroup template direttamente all’elemento di monitoraggio (datagroup diretti).
- Associando il datagroup template ad un element template.
E’ possibile configurare praticamente tutti i campi (di datasource/condition/timegraph/serie) o parametri opzionali di un datagroup in un qualunque punto di questa cascata di configurazione*:
- A livello di datagroup template (1)
- A livello di elemente template (2)
- A livello di datagroup istanziato per un elemento (4)
+-----+ +-----+
| dg1 | | dg2 | min-period=60 DATAGROUP 1
+-----+ +-----+ TEMPLATES
. .
----.------------------.----------------------------------------------------
. .
. . Node ELEMENT 2
. .Template TEMPLATES
. +-.---------+
. | +-------+ |
. | | dg2 | | min-period=120
. | +-------+ |
. +-----.-----+
. . .
----.--------------.-------.------------------------------------------
. . . ELEMENTS 3
. +------+ .
. | Nodo | .
. +------+ .
. / \ .
----.---/----------\-------.------------------------------------------
. / \ .. DATAGROUPS 4
. / \ .
[ dg1 ] [ dg2 ] min-period=30
I livelli piu’ bassi della catena sovrascrivono i livelli piu’ alti, quindi un campo configurato a livello di datagroup sovrascrive qualunque parametrizzazione fatta a livello di datagroup-template o elemente-template.
3.1.7.6.1. Configurazione della priorita’¶
La priorita’ di una condition e’ un caso un po’ particolare di campo configurabile.
E’ possibile assegnare una priorita’ (priorita’ di default) ANCHE ad ogni elemento di monitoraggio (nodo, interfaccia, ecc.).
In assenza di parametrizzazioni a livello di singolo datagroup (istanza), vale (se impostata) la priorita’ impostata per l’elemento. In assenza di priorita’ a livello di elemento vale la priorita’ configurata a livello di element template o datagroup template.
La priorita’ di default specificata per sub-elementi (interfacce, dischi, ecc.) sovrascrive la priorita’ di default del nodo padre (se specificata).
+-----+ +-----+
| dg1 | priority=1 | dg2 | priority=n/a DATAGROUP 1
+-----+ +-----+ TEMPLATES
. .
----.------------------.----------------------------------------------------
. .
. . Node ELEMENT 2
. .Template TEMPLATES
. +-.---------+
. | +-------+ |
. | | dg2 | | min-period=120
. | +-------+ |
. +-----.-----+
. . .
----.--------------.-------.------------------------------------------
. . . ELEMENTS 3
. +------+ .
. | Nodo | . priority=30
. +------+ .
. / \ .
----.---/----------\-------.------------------------------------------
. / \ .. DATAGROUPS 4
. / \ .
[ dg1 ] [ dg2 ]
p = 30 p = 30
3.1.7.7. Best practice¶
Poiche’ la gestione delle configurazioni tramite template e’ gerarchica e basata su un meccanismo di ereditarieta’, le operazioni di aggiornamento/modifca possono essere costose in termini di tempo/CPU.
E’ opportuno seguire le seguenti regole:
- Se si sta creando un nuovo datagroup-template e si vuole testare il suo funzionamento e’ VIVAMENTE CONSIGLIATO di associare il datagroup direttamente ad UN SOLO elemento di monitoraggio e provarlo.
- Evitare, se possibile, di cancellare/aggiungere datasource/condition/timegraph a datagroup-template gia’ esistente e associato a molti elementi di monitoraggio.
- Non reimpotare la library interamente da file, ma importare solo i datagroup template mancanti.
3.2. Monitoraggio dei nodi¶
3.2.1. 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)
3.2.1.1. Flag switch/router¶
I flag switch e router sono due flag puramente informativi e non influiscono in nessuno modo sul monitoraggio.
3.2.1.2. 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.
3.2.2. Configurazione protocollo SNMP¶
3.2.2.1. 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.
3.2.2.1.1. 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
3.2.2.2. 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.
3.2.3. 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.
![digraph prova {
imagepath="/opt/sanet3/static/webui/images/resources/";
subgraph cluster1 {
label="cluster 1";
wc1 -> ap1;
wc1 -> ap2;
wc1 -> ap3;
}
subgraph cluster2 {
label="cluster 2";
wc2 -> ap4;
wc2 -> ap5;
}
wc2 -> ap3 [color = red, label = "no"];
}](../_images/graphviz-028859d06325466007baab38a14c7ae047ddc1eb.png)
3.2.3.1. 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.
3.2.3.2. 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.
3.2.3.3. 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!!!
3.2.4. Configurazione¶
- CLI: si rimanda alla sezione: Nodi
- WEB: non ancora disponibile.
3.3. Monitoraggio dei interfacce¶
3.3.1. Interfacce¶
Le interfacce possiedono tre attributi che possono essere modificati ai fini del monitoraggio.
Dato Descrizione nome Stringa per identificare l’interfaccia nel monitoraggio priorita’ Priorita’ di default delle condition associate (se non specificato diversamente) distinguisher stringa per identificare univocamente l’interfaccia all’interno del nodo. xform Espressione che utilizzando il distinguisher, permette di calcolare automaticamente l’id dell’interfaccia nelle tabelle (SNMP o altro) interne del nodo ifindex Stringa che codifica l’istanza dell’interfaccia da usare per il monitoraggio. Viene calcolato automaticamente e non dovrebbe essere mai valorizzato esplicitamente. backbone Flag per indicare se l’interfaccia e’ usata come dorsale (o uplink, backbone ) speed Valore intero per indicare la (presunta) velocita’ (rate bit/s) dell’interfaccia.
Alcuni di quest attributi possono essere utilizzati direttamente nei controlli (expressioni) di monitoraggio. Si veda: Built-in interface’s variables.
3.3.1.1. Attributi Distinguisher, xform e valore ifIndex¶
Monitorando un’interfaccia di rete tramite protocolli come SNMP (ma anche altri), puo’ succedere che l’interfaccia sia identificata tramite un indice numerico e non tramite una stringa mnemonica.
Questo indice numerico puo’ essere dinamico e quindi cambiare in qualunque momento.
Attraverso l’utilizzo dei parametri distinguisher e xform, Sanet puo’ verificare/ricalcolare, di volta in volta, il valore corretto dell’indice associato all’interfaccia.
Poiche’ nel 99% dei casi il monitoraggio di rete avviene tramite protocollo SNMP, per comodita’ di nomenclatura, l’indice di una interfaccia in Sanet e’ chiamato ifIndex.
I datagroup che associati ad una interfaccia possono utilizzare il valore dell’ifIndex se nelle espressioni di datasource e condition viene indicato in qualche modo il simbolo $ifindex.
Note
in fase di configurazione e’ possibile utilizzare per le xform degli alias al posto delle espressioni. Si veda la sezione: Xform predefinite.
3.3.1.1.1. Come viene calcolato l’IfIndex¶
Se l’attributo distinquisher e’ valorizzato, l’indice dell’interfaccia e’ considerato come il valore dell’ifindex. Valorizzare solo il distinquisher significa considerare l’indice dell’interfaccia come costante e immutabile.
Quando l’attributo xform e valorizzato con una espressione valida, Sanet calcola il valore dell’espressione e questo viene considerato con l’indice valido per l’interfaccia.
Se entrambi gli attributi distinguisher e xform sono valorizzati, Sanet calcola il valore dell’espressione xform e l’espressione puo’ contenere il simbolo $distinguisher per effettuare il calcolo dell’indice dell’interfaccia.
Esempio 1: Solo il distinguisher e’ parametrizzato:
name = eth0
distinguisher = 1 \_____ ifIndex = 1
xform = null /
Esempio 2: Distinguisher e xform parametrizzati, ma l’xform non utilizza il distinguisher:
name = eth0
distinguisher = "eth0.1" \_____ ifIndex = 56
xform = 56 /
Esempio 3: Distinguisher e xform parametrizzati:
name = eth0
distinguisher = "3" \_____ ifIndex = 6
xform = int($distinguisher) * 3 /
Esempio 4: Ipotizzando di avere una funzione findIfIndexByName() che calcola l’ifindex giusto in base al distinguisher dell’interfaccia.
name = eth0
distinguisher = "eth0.0" \_____ ifIndex = 124
xform = findIfIndexByName($distinguisher) /
3.3.1.1.1.1. Distinguisher & XForm Best Practice¶
E’ bene tenere presente che:
- il distinguisher e’ una stringa identificativa che dovrebbe essere univoca
- l’xform e’ una espresssione che puo’, ma non necessariamente, utilizzare il distinguisher per calcolare l’ifindex, stindex, ecc.
Da queste premesse e’ fortemente consigliato:
- Memorizzare sempre nel distinguisher una stringa pura (logicamente completa o parziale in base alle proprie esigenze) e opaca al sistema.
- Scrivere una xform che gestisca correttamente il distinguisher.
- Se si utilizzano meccanismi basati su espressioni regolari assicurarsi che il distinguisher venga manipoloato correttamente (escaping, quoting) e non viceversa (ovvero modificare il distinguisher per far funzionare correttamente l’xform)
3.3.1.1.2. Quando viene calcolato l’IfIndex¶
Sanet effettua il calcolo dell’ifindex di una interfaccia SOLO se un datagroup utilizza nelle sue espressioni (di datasource o condition) il simbolo $ifindex.
Si dice che il simbolo $ifindex e’ un valore LAZY, cioe’ calcolato solo se effettivamente utilizzato.
Note
E’ possibile scrivere datagroup che non sfruttano il meccanismo automatico.
Note
Se l’ifindex e’ presente in piu’ esperessioni di piu’ datasource/condition dello stesso datagroup, questo viene comunque calcolato solo la prima volta che il valore deve essere usato. In pratica se il simbolo $ifindex e’ utilizzato gia’ nel primo datasource, il calcolo avviene immediatamente e il valore resta valido per tutta la valutazione del datagroup.
3.3.1.1.3. Parametri di monitoraggio ed altri simboli (impliciti) nelle espressioni¶
Oltre al simbolo $ifindex e $distinguisher esistono altri parametri di monitoraggio (ed corrispondenti simboli), che possono essere utilizzati nelle espressioni di datasource e condition.
Le interfacce ereditano molti dei parametri di configurazioni dal nodo di appartenenza, altri vengono calcolati automaticamente in base alla configurazione del monitoraggio: interfacce collegate, ecc.
Per un elenco completo di tutti i simboli utilizzabili nelle espressioni dei datagroup si rimanda alla sezione: SANET built-in expression symbols.
3.3.2. Configurazione delle interfacce¶
- CLI: si rimanda alla sezione: Interfacce
- WEB: non ancora disponibile.
3.4. Link tra nodi/interfacce¶
Un link serve per rappresentare un collegamento tra (due) interfacce di rete.
NOTA: Un’interfaccia di rete puo’ comparire in piu’ link contemporaneamente.
Un link e’ definito dai seguenti attributi:
Dato Descrizione nome Stringa univoca.Il nome di un link, se non specificato, viene assegnato automaticamente dal sistema in base alle interfacce coinvolte. descrizione Stringa di testo descrittiva. tipo (obbligatorio) Identifica il tipo di collegamento
Esistono tre tipi codificati di link:
- FISICO : il link collega le interfacce a livello “fisico” (rame, radio, fibra).
- RETE : il link esiste a livello logico (un adiacenza BGP, ess..) ma non fisico
- VIRTUALE: il link esiste perche’ fa comodo definire nel monitoraggio un collegamento che non sia dei due tipi precedenti.
Note
una interfaccia puo’ essere coinvolta in UN SOLO link di tipo FISICO.
3.4.1. Interfaccia linked ed espressioni¶
Quando un’interfaccia (A) e’ collegata ad una seconda interfaccia (B), l’interfaccia (B) e’ detta interfaccia linked.
I datagroup che si occupano di monitorare interfacce possono accedere ad alcuni parametri/dati dell’interfaccia linked attraverso alcuni simboli calcolati automaticamente analogamente a quanto avviene per il simbolo $ifindex.
Il simbolo piu’ importante e’ $linked_ifindex, che rappresenta l’ifindex dell’interaccia linked.
Note
anche $linked_ifindex (ed altri simboli) sono calcolati dinamicamente e solo quando realmente utilizzati.
Per un elenco completo di tutti i simboli associati all’interfaccia linked si rimanda alla sezione: SANET built-in expression symbols.
3.4.2. Configurazione dei link¶
- CLI: si rimanda alla sezione: Link
- WEB: TODO
3.5. Monitoraggio degli storage¶
3.5.1. Parametri di monitoraggio¶
Come per le interfacce, anche gli storage sono caratterizzati da:
Dato Descrizione nome Stringa per identificare lo storage nel monitoraggio priorita’ Priorita’ di default delle condition associate (se non specificato diversamente) distinguisher stringa per identificare univocamente lo storage all’interno del nodo. xform Espressione che utilizzando il distinguisher, permette di calcolare automaticamente l’id dello storage nelle tabelle (SNMP o altro) interne del nodo stindex Stringa che codifica l’istanza dello storage da usare per il monitoraggio. Viene calcolato automaticamente e non dovrebbe essere mai valorizzato esplicitamente.
Alcuni di quest attributi possono essere utilizzati direttamente nei controlli (expressioni) di monitoraggio. Si veda: Built-in storage’s variables.
3.5.1.1. Attributi Distinguisher, xform e valore stIndex¶
Analogamente a quanto avviene con l’ifindex per le interfacce, ogni storage puo’ essere identificato da un valore numerico chiamato stIndex.
Il valore dell’stIndex e’ accessibile nelle espressioni tramite il simbolo $stindex.
Si rimanda alla sezione Attributi Distinguisher, xform e valore ifIndex per una descrizione su come parametrizzare/utilizzare xform e distinguisher per il calcolo dell’stIndex.
3.5.2. Configurazione degli storage¶
- CLI: si rimanda alla sezione: Storage
- WEB: non ancora disponibile.
3.6. Monitoraggio dei servizi¶
3.6.1. Parametri di monitoraggio¶
Come per le interfacce, anche i servizi sono caratterizzati da:
Dato Descrizione nome Stringa per identificare lo storage nel monitoraggio priorita’ Priorita’ di default delle condition associate (se non specificato diversamente) distinguisher stringa per identificare univocamente il servizio nel nodo. xform Espressione che utilizzando il distinguisher, permette di calcolare automaticamente l’id del servozop nelle tabelle (SNMP o altro) interne del nodo swrunindex Stringa che codifica l’istanza del service da usare per il monitoraggio. Viene calcolato automaticamente e non dovrebbe essere mai valorizzato esplicitamente.
Alcuni di quest attributi possono essere utilizzati direttamente nei controlli (expressioni) di monitoraggio. Si veda: Built-in service’s variables.
3.6.1.1. Attributi Distinguisher, xform e valore swRunIndex¶
Analogamente a quanto avviene con l’ifindex per le interfacce, ogni servizio puo’ essere identificato da un valore numerico chiamato swRunIndex.
Il valore dell’swRunIndex e’ accessibile nelle espressioni tramite il simbolo $swrunindex.
Si rimanda alla sezione Attributi Distinguisher, xform e valore ifIndex per una descrizione su come parametrizzare/utilizzare xform e distinguisher per il calcolo dell’swrunindex.
3.6.2. Configurazione dei servizi¶
- CLI: si rimanda alla sezione: Service
- WEB: non ancora disponibile.
3.7. Monitoraggio di device generici¶
3.7.1. Parametri di monitoraggio¶
Come per le interfacce, anche i device sono caratterizzati da:
Dato Descrizione nome Stringa per identificare lo storage nel monitoraggio priorita’ Priorita’ di default delle condition associate (se non specificato diversamente) distinguisher stringa per identificare univocamente il device nel nodo. xform Espressione che utilizzando il distinguisher, permette di calcolare automaticamente l’id del device nelle tabelle (SNMP o altro) interne del nodo devindex Stringa che codifica l’istanza del device da usare per il monitoraggio. Viene calcolato automaticamente e non dovrebbe essere mai valorizzato esplicitamente.
Alcuni di quest attributi possono essere utilizzati direttamente nei controlli (expressioni) di monitoraggio. Si veda: Built-in device’s variables.
3.7.1.1. Attributi Distinguisher, xform e valore devIndex¶
Analogamente a quanto avviene con l’ifindex per le interfacce, ogni device puo’ essere identificato da un valore numerico chiamato devIndex.
Il valore dell’devIndex e’ accessibile nelle espressioni tramite il simbolo $devindex.
Si rimanda alla sezione Attributi Distinguisher, xform e valore ifIndex per una descrizione su come parametrizzare/utilizzare xform e distinguisher per il calcolo dell’devindex.
3.7.2. Configurazione dei device¶
- CLI: si rimanda alla sezione: Service
- WEB: non ancora disponibile.
3.8. Gestione Messaggi/Allarmi¶
3.8.1. Wildcard¶
Ci sono tre metodi per espandere il testo con le informazoni disponibili:
- Utilizzo di wildcard $.
- Utilizzo di wildcard %.
- Utilizzo di wildcard dinamici {{ }}.
3.8.1.1. Wildcard $¶
IMPORTANTE: Queste wildcard sono simili a quelle utilizzabili nei titoli di datagroup/condition/datasource.
Wildcard usabili negli allarmi associati ad un nodo:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo Tutti i parametri opzionali con $*parametro* Es. $threshold
Wildcard usabili negli allarmi associati ad una interfaccia:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $iface nome dell’interfaccia $instance distinguisher dell’interfaccia $distinguisher distinguisher dell’interfaccia $linked_iface (interfaccia collegata con un link fisico) $linked_node (nodo dell’interfaccia collegata con un link fisico) $ifindex Ifindex calcolato da sanet aggiornato all’ultimo check Tutti i parametri opzionali con $*parametro* Es. $threshold
Wildcard usabili negli allarmi associati ad uno storage:
Variabile Descrizione Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $storage nome dello storage $distinguisher distinguisher dello storage $stindex stindex calcolato da sanet aggiornato all’ultimo check Tutti i parametri opzionali con $*parametro* Es. $threshold
Wildcard usabili negli allarmi associati ad uno service:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $service nome del servizio $distinguisher distinguisher del servizio $swrunindex swrunindex calcolato da sanet aggiornato all’ultimo check Tutti i parametri opzionali con $*parametro* Es. $threshold
Wildcard usabili negli allarmi associati ad uno device:
Variabile Descrizione $node nome del nodo $snmpversion snmp version del nodo $community snmp community del nodo $device nome del device $distinguisher distinguisher del device $devindex devindex calcolato da sanet aggiornato all’ultimo check Tutti i parametri opzionali con $*parametro* Es. $threshold
3.8.1.2. Wildcard %¶
Entita’ Wildcard Descrizione %p % Tenant %N Nome del Tenant Allarme %t Orario di generazione dell’allarme (in formato timestamp) %s Orario di generazione dell’allarme (in formato ISO) %y Data in formato YYYY-MM-DD HH:MM:SS Nodo %H Nome del nodo sanet %A Indirizzi IPv4 del nodo risolti da Sanet %D Descrizione del nodo Interfaccia %I Nome interfaccia %ID Descrizione interfaccia %IDsnmp Descrizione interfaccia tramite informazioni SNMP (on-demand) %L Nodo e interfaccia collegata nel formato nodo:interfaccia. Condition %T Path della condition %P Priority della condition %E Espressione della condition %m Descrizione verbosa prodotta dal check della condition (verbstatus) %M Max tries della condition %n Numero di check effettuati al momento della generazione dell’allarme. %U URL della pagina WEB della condition associata all’allarme
Note
Queste wildcard esistono per retro-compatibilita’ con sanet2. Alcuni dei valori espansi sono gli stessi ottenibili attraverso le wildcard descritte nel paragrafo precedente.
3.8.1.3. Wildcard dinamici {{ }}¶
Oltre alle wildcard descritte in precedenza, e’ possibile inserire informazioni legate all’allarme utilizzando un linguaggio di template.
Il linguaggio di template supporta le seguenti feature:
- Espansione di singoli valori
- Formattazione dei valori espansi
- Strutture condizionali if (non trattato in questo documento)
- Cicli for (non trattato in questo documento)
Per stampare un singolo valore si deve usare la seguente sintassi:
{{ <simbolo> }}
Esempio:
{{ node.name }} {{ iface.description }} {{ ds.in.value }}
Important
quando il valore di un simbolo e’ nullo (none, null, nil) vengono espansi con la stringa:
*NULL*
Il valore stringa vuota (‘’) e’ un valore diverso da valore nullo.
Important
i simboli non previsti dal sistema vengono espansi con la stringa:
*UNDEFINED*
Questo e’ l’elenco dei simboli supportati:
Tenant
Simbolo Descrizione tenant.name Nome del tenant
Nodi
Simbolo Descrizione node.name Nome del nodo associato al controllo node.description Descrizione configurata per il nodo, node.sysname Nome SNMP del nodo corrente node.syslocation Localizzazione del nodo corrente node.syscontact Contatto primario relativo al nodo corrente node.sysuptime Tempo di attivita’ del nodo in formato HH:MM:SS node.cluster_element.name Nome del master del cluster per il nodo node.effective_ip L’indirizzo IP che Sanet pensa di dover usare in fase di check di un datagroup. Warning
La wildcard {{ node.effective_ip }} puo’ dipendere da:
- configurazione di Sanet
- indirizzi IP risolti in fase di esecuzione (in presenza di indirizzi multipli non c’e’ certezza di quale venga considerato effettivo al momento del check di un datagroup).
Interfacce
Simbolo Descrizione iface.name Nome dell’interfaccia associata al controllo iface.description Descrizione configurata per l’interfaccia, iface.description_snmp Descrizione SNMP per l’interfaccia.
Simbolo Descrizione linked_node.name Nome del nodo associato al controllo linked_node.description Descrizione configurata per il nodo, linked_iface.name Nome dell’interfaccia collegata associata al controllo linked_iface.name Nome dell’interfaccia associata al controllo linked_iface.description Descrizione configurata per l’interfaccia, linked_iface.description_snmp Descrizione SNMP per l’interfaccia. Note
Le OID usate per calcolare {{iface.description_snmp}} sono:
1.3.6.1.2.1.2.2.1.2.<ifindex> 1.3.6.1.2.1.31.1.1.1.1.<ifindex> 1.3.6.1.2.1.31.1.1.1.18.<ifindex> 1.3.6.1.4.1.9.2.2.1.1.28.<ifindex>Danger
Le informazioni SNMP delle interfacce necessitano che il valore ifIndex dell’interfaccia sia stato calcolato dal sistema di monitoraggio. Questo avviene solo se almeno uno datagroup associato all’interfaccia e’ riuscito a calcolare questo valore.
Warning
I dati raccolti tramite interrogazioni SNMP vengono espansi effettuando interrogazioni on-demand al momento della dell’espansione della wildcard. Il tempo di elaborazione complessivo dipende dallo stato del nodo interessato.
Warning
I dati raccolti tramite interrogazioni SNMP vengono gestiti tramite una cache temporanea di 60 secondi.
Storage
Simbolo Descrizione storage.name Nome storage.distinguisher Distinguisher storage.stindex valore corrente
Service
Simbolo Descrizione service.name Nome service.distinguisher Distinguisher service.swrunindex valore corrente
Device
Simbolo Descrizione device.name Nome device.distinguisher Distinguisher device.devindex valore corrente
Datasource
Simbolo Descrizione ds.*name*.value Valore del datasource (valore puntuale per GAURGE, rate per COUNTER)
Esempio: Se il datagroup definisce due datasource installed, total:
{{ ds.installed.value }} {{ ds.total.value }}
Parametri
Simbolo Descrizione params.*name*.value Espande il valore del parametro con nome name
Esempio: Se il datagroup definisce un parametro con nome threshold:
{{ params.threshold.value }}
Condition
Simbolo Descrizione condition.path Path della condition associata all’allarme condition.priority Priority della condition. condition.alarm_url URL della pagina WEB della condition associata all’allarme.
OID SNMP usate nelle expr
E’ possibile inoltre espandere il valore delle variabili snmp utilizzate nell’esecuzione di un datagroup attraverso le seguenti wildcard:
Simbolo Descrizione exec_snmp.*oid* Valore della variabile snmp avente oid specificata exec_snmp.items Lista di coppie (variabile, valore) in formato stringa che contiene tutte le variabili snmp utilizzate durante l’esecuzione del datagroup
E’ possibile specificare la oid anche in maniera parziale (es: 1.3.6.1). In tal caso viene restituita una stringa che rappresenta una lista di coppie (oid, valore) le cui oid iniziano con quanto specificato.
L’espansione delle variabili SNMP e’ possibile anche nei seguenti modi:
Srestituisce tutte le variabili SNMP utilizzate
{% for oid, value in exec_snmp.items %} {{oid}} = {{value}} {% endfor %}
Restituisce tutte le variabili SNMP utilizzate la cui oid inizia come specificato
{% for oid, value in exec_snmp.1.3.6.1 %} {{oid}} = {{value}} {% endfor %}
In caso di configurazione errata nell’espansione delle variabili SNMP viene visualizzato UNDEFINED. Ad esempio con la seguente configurazione:
{% for oid, value in exec_snmp.1.3.6.1 %} {{oid.3.4}} = {{value}} {% endfor %}
Nell’espansione di otterrebbe il seguente risultato (supponendo come variabili SNMP usate nell’esecuzione del datagroup: 1.3.6.1.4.1.2021.4.6.0@, 1.3.6.1.4.1.2021.4.5.0@, 1.3.6.1.4.1.2021.4.14.0@):
*UNDEFINED* = *UNDEFINED* *UNDEFINED* = *UNDEFINED* *UNDEFINED* = *UNDEFINED*
Variabili di contesto
Analogamente a quanto descritto per le variabili SNMP, e’ possibile espandere anche le altre variabili di contesto utilizzate durante l’esecuzione di un datagroup utilizzando la wildcard:
Simbolo Descrizione exec_vars.*nome* Valore della variabile avente nome specificato
Altri dati
E’ possibile utilizzare molte altre wildcard. Si rimanda all’elenco in appendice: Elenco wildcards per allarmi
3.8.1.4. Formattare i valori¶
E’ possibile formattare i valori numerici espansi utilizzando la seguente sintassi:
Sintassi Descrizione {{ <simbolo>|kilo }} Formatta il numero usando i prefissi del sistema internazionale con base decimale (k, M, G, T) {{ <simbolo>|kibi }} Formatta il numero usando i prefissi con base binaria (ki, Mi, Gi)
Important
questa sinstassi e’ applicabile solo se si utilizzano i wildcard dinamici {{ }}
Esempio:
nome datasource valore datasource Stringa nel messaggio Espansione in 1000 {{ ds.in.value }} 1000 in 1000 {{ ds.in.value|kilo }} 1k in 1000 {{ ds.in.value|kibi }} 0.97ki in 1024 {{ ds.in.value|kilo }} 0.97k in 1024 {{ ds.in.value|kibi }} 1ki
3.8.1.5. Tabella comparativa¶
% $ {{ }} Allarme %t {{ alarm.ts }} %s {{ alarm.ts_iso }} %y {{ alarm.ts_ISO }} Tenant %N {{ tenant.visible_name }} Nodo %H $node {{ node.name }} {{ element.name }} %A {{ node.ipv4_addresses_spaced }} {{ element.ipv4_addresses_spaced }} %D {{ node.description }} {{ element.description }} $snmpversion {{ node.snmp_version }} {{ element.snmp_version }} $community {{ node.snmp_community }} {{ element.snmp_community }} {{ node.cluster_element.name }} {{ element.cluster_element.name }} Interfaccia %I $iface {{ iface.name }} {{ element.name }} %ID {{ iface.description }} {{ element.description }} %IDsnmp {{ iface.description_snmp }} {{ element.description_snmp }} $distinguisher {{ iface.distinguisher }} {{ element.distinguisher }} $ifindex {{ iface.ifindex }} {{ element.ifindex }} $linked_node {{ linked_node.name }} {{ linked_node.description }} $linked_iface {{ linked_iface.name }} {{ linked_iface.description }} {{ linked_iface.description_snmp }} %L $linked_node:$linked_iface {{ linked_node.name }}:{{ linked_iface.name }} Storage $storage {{ storage.name }} {{ element.name }} $distinguisher {{ storage.distinguisher }} {{ element.distinguisher }} $stindex {{ storage.stindex }} {{ element.stindex }} Service $service {{ service.name }} {{ element.name }} $distinguisher {{ service.distinguisher }} {{ element.distinguisher }} $swrunindex {{ service.swrunindex }} {{ element.swrunindex }} Device $device {{ device.name }} {{ element.name }} $distinguisher {{ device.distinguisher }} {{ element.distinguisher }} $devindex {{ device.devindex }} {{ element.devindex }} Datasource {{ ds.<name>.value }} Condition %T $path {{ condition.path }} %P {{ condition.priority }} %E {{ condition.expr }} %m {{ condition.verbstatus }} %M {{ condition.max_tries }} %n {{ condition.tries }} %U {{ condition.alarm_url }} Parametri $<name> {{ params.<name>.value }}
3.9. Calendari e range temporali¶
Un corretto monitoraggio deve essere in grado di:
- gestire range temporali di interesse
- distinguere tra giorni feriali/festivi/pre-festivi/ecc.
3.9.1. Range temporali¶
Un range temporale rappresente e’ un periodo di tempo caratterizzato da un inizio ed una fine, e che puo’ essere valido per uno o piu’ giorni della settimana.
Un range temporale e’ codificato attraverso una stringa che deve rispettare una precisa sintassi.
I formati ammessi per questa stringa sono:
all
Fa match con qualunque giorno.
none
Fa match con qualunque giorno. (Ereditato da sanet2)
time [ | time …]
Dove time e’ una stringa con il seguente formato:
[ hours [ , hours … ] ] / [ days [ , days … ] ]
Dove hours ha il formato:
hh [ : mm ] - hh [ : mm ]
e days ha il formato:
H
d [ - d ]
I valori ammessi per hh vanno da 1 a 24. I valori ammessi per mm vanno da 1 a 59.
Il valore “H” indica qualunque giorno festivo in base al calendario delle festivita’. Si veda Gestione del calendario.
I valori ammessi per d vanno da 1 a 7. La numerazione dei giorni parte da Lunedi’:
1 = Monday 2 = Tuesday 3 = Wednesday 4 = Thursday 5 = Friday 6 = Saturday 7 = Sunday
Esempi:
8:00-18:00/1-7
Dal Lunedi' alla Domenica, tra le 8:00 e le 18:00.
00-24/H
Tutti i giorni festivi, per tutto il giorno.
8:00-18:00,22:30-23:00/1-5|00:00-23:59/6-7,H
Dal Lunedi' al Venerdi', tra le 8 e le 18 e tra le 22:30 e le 23.
Il Sabato e la Domenica e tutti i festivi, tutto il giorno.
3.9.2. Gestione del calendario¶
3.9.2.1. Introduzione¶
Alcuni giorni dell’anno sono speciali poiche’ sono giorni di festivita’ e l’operativita’/allarmistica deve essere gestita in maniera particolare.
Per gestire questi giorni speciali Sanet puo’ essere configurato per tenere in considerazione uno o piu’ calendari di giorni festivi.
Important
La gestione dei calendari si applica a tutti i tenant. Non e’ possibile definire calendari validi solo per alcuni tenant, ma e’ possibile definire calendari e utilizzarli per gestire l’operativita’ di alcuni tenant e non di altri.
3.9.2.2. Calendario di default¶
Ogni calendario e’ identificato da un nome logico. Il calendario di default e’ chiamato “DEFAULT”.
Quando non specificato, Sanet applica al calcolo dei giorni festivi il calendario “DEFAULT”.
3.9.2.3. Configurazione¶
La configurazione del calendario delle festivita’ e’ gestita tramite file di configurazione di Sanet (settings.py).
Il formato di configurazione e’ il seguente:
# Special days always treated HOLIDAYS HOLIDAYS = { 'DEFAULT': set([ <giorno1>, <giorno2>, <giorno3>, ... ]), <nome1>: set([ <giorno1>, <giorno2>, <giorno3>, ... ]), <nome2>: set([ <giorno1>, <giorno2>, <giorno3>, ... ]), ... }
I giorni festivi possono essere indicati in due modi:
MMDD Giorno festivo ricorrente il giorno DD/MM di tutti gli anni. YYYYMMDD Giorno festivo in data DD/MM/YYYY
Questo e’ un esempio di file di configurazione che specifica il calendario di DEFAULT e un calendario applicabile alla citta’ di Roma:
Esempio:
# Special days always treated HOLIDAYS HOLIDAYS = { 'DEFAULT': set([ # All years, only 4 digits MMDD '0101', '0106', '0425', '0501', '0602', '0815', '1101', '1208', '1225', '1226', # Specific year, 4 digits YYYYMMDD # Giorni di pasquetta dal 2015 al 2034 '20150406', '20160328', '20170417', '20180402', '20190422', '20200413', '20210405', '20220418', '20230410', '20240401', '20250421', '20260406', '20270329', '20280417', '20290402', '20300422', '20310414', '20320329', '20330418', '20340410', ]), 'rome': set([ '2906', # Festa patronale ]), }
3.9.2.4. Giorni della settimana speciali (special holidays)¶
Warning
Questa gestione e’ obsoleta. Non utilizzare.
E’ possibile indicare al sistema quale giorno della settimana considerare come “festivo” e dire considerare i giorni festivi in calendario come se ricadessero nel giorno specificato.
HOLIDAYS_AS_WDAY = 7
IMPORTANTE: se HOLIDAYS_AS_WDAY e’ valorizzato a None la gestione delle special holidays viene ignorata:
HOLIDAYS_AS_WDAY = None
3.10. Eventi “Push”¶
Contenuti
- Teoria e gestione del Monitoraggio
- Concetti di base del monitoraggio
- Gerarchia del monitoraggio
- Tenant
- Agenti di monitoraggio
- Priorita’ logica dei controlli e livelli di priorita’
- Elementi Monitorabili (dagli agenti)
- Raccolta dati e controlli
- Datagroup
- Cos’e’ un datagroup
- Come definire un datagroup
- Gestione dei datagroup a parte degli agenti: Esecuzione
- Attributi di un datagroup e sotto-elementi di configurazione
- Dipendenze tra datagroup (dependson)
- I Datasource
- Le Condition
- Esecuzione di script automatica con variazioni di stato
- Regole di valutazione di Datasource e Condition
- Parametri opzionali
- Timegraph
- Sospensione e Riattivazione di un datagroup
- Configurazione avanzata dello scheduling
- Datagroup
- Template di Configurazione
- Monitoraggio dei nodi
- Monitoraggio dei interfacce
- Link tra nodi/interfacce
- Monitoraggio degli storage
- Monitoraggio dei servizi
- Monitoraggio di device generici
- Gestione Messaggi/Allarmi
- Calendari e range temporali
- Eventi “Push”
- Trap SNMP
- Concetti di base del monitoraggio
Il flusso di monitoraggio e’ diviso in tre fasi:
- RECEIVE: Raccolta dati dalla rete ( esecuzione di datagroup da parte di agenti)
- PROCESS: Ricezione ed elaborazione dei dati dal server centrale di sanet
- NOTIFY: Notifica di allarmi
Attraverso gli eventi/allarmi Push e’ possibile inserirsi in questo flusso utilizzando dati prodotti da applicazioni esterne.
E’ possibile effettuare due tipi di operazioni push, che si differenzioano in base al punto di ingresso nel sistema:
- Push di eventi
- Push di allarmi
In questo schema viene riassunto il flusso di:
- monitoraggio di datagroup normali
- monitoraggio di trap snmp attraverso datagroup passsivi
- push di eventi ed elaborazione don datagroup passivi
- push di allarmi in entables
Un evento e’ un insieme di dati in forma chiave/valore che vengono loggati e processati da datagroup passivi.
Quando viene fatto push di un evento, Sanet compie le seguenti operazioni:
- L’evento viene storicizzato nel log di sanet come evento CUSTOM.
- Sanet cerca di capire se l’evento e’ associabile ad un elemento di monitoraggio.
- L’evento viene processato da un datagroup passivo. Le condition di questo datagroup possono produrre o meno allarmi.
In fase di push e’ possibile forzare due valori:
- indirizzo ip sorgente
- elemento di monitoraggio associato all’evento.
Se viene specificato solo l’indirizzo IP sorgente, sanet cerca di identificare il nodo di di monitoraggio associato, con un meccanismo identico a quello per gestire le Trap SNMP.
Per poter elaborare un evento con un datagroup passivo e’ necessario associare all’evento una stringa di passive match.
Questa stringa viene confrontata con l’attributo passive match di tutti i datagroup associati all’elemento di monitoraggio che sanet ha associato all’evento.
Important
l’attributo passive match di un datagroup puo’ specificare, usando una sintassi particoalre, una regular expression. Si veda il paragrafo Passive match.
Tutte le tuple chiave/valore associate ad un evento vengono convertite in simboli accessibile nelle espressioni di datasource e condition.
Esempio:
EVENTO SIMBOLI ACCESSIBILI NELLE EXPR { data : "1/1/2015", -> $data = "1/1/2015" variabile1 : 666 -> $variabile1 = 666 }
Per effetuare il push di un evento bisogna usare il comando:
sanet-manage push_event [optioni]
Esempio:
python manage.py push_event -L 10 --element localhost '{ "val": 10 }'
L’allarme deve essere un dizionario di attributi chiave/valore codificato in formato JSON valido.
Esempio: Dato il seguente allarme:
{ "campo1": "hello", "campo2": "world", "campo3": 1234 }
Il comando e’:
sanet-manage push_event --element localhost '{ "campo1" : "hello", "campo2" : "world", "campo3" : 1234 }'
sanet-manage push_event --element localhost --stdin { "campo1" : "hello", "campo2" : "world", "campo3" : 1234 } Ctrl+d
Per specificare un attributo dell’allarme da environemnt bisogna definire una variabile d’ambiente con il seguente nome:
EVENT_PUSH_{nome}={valore}export EVENT_PUSH_campo1=ciao sanet-manage push_alarm --env --element localhost
L’allarme inviato ad entables sara’:
{ "campo1" : "ciao" }
Configurazione nodo e datagroup passivo:
datagroup-template dgpassive source site description "" passive-match passivo minperiod 0 title "Datagroup per eventi passivi" condition check expr "$var == 1" max-tries 1 msg-downbody "Evento passivo down" msg-downsubj "[DOWN] Evento passivo" msg-upbody "Evento passivo up" msg-upsubj "[UP] Evento passivo" title "Controllo passivo" exit exit node localhost datagroup dgpassive exit exit
Configurazione entables:
entables -t notify -A DEFAULT -j SMTP --smtp_rcpt_to '${mail_to}' --smtp_message '${mail_body} - ${rawalarm}' --smtp_subject '${mail_subject}'
Push dell’evento:
python manage.py push_event -L 10 '{ "var": 0 }' --sourceip 127.0.0.1 --passive passivo
Quando viene generato un allarme da un evento pushed, e’ possibile inserire i dati pushed all’interno del corpo dei messsaggi UP e DOWN usando le wildcard dinamici (Vedi anche Wildcard dinamici {{ }}).
La sintassi e’ la seguente:
{{ pushed_data.<key>[.<key> ...] }}
Esempio: Se questi sono i dati dell’evento pushed:
{ "campo1" : "ciao", "campo2" : [ 1, 2, 3 ], "campo3" : { "key1": 666, "key2": 777, } }
Questi sono alcuni esempi delle wildcard che e’ possibile usare:
{{ pushed_data.campo1 }} --> ciao {{ pushed_data.campo2.1 }} --> 2 {{ pushed_data.campo3.key2 }} --> 777
Un allarme e’ un insieme di tuple chiave/valore. Questi dati possono essere utilizzati in entables per fare match, espandere stringhe e template nei target, ecc.
Un allarme viene processato da entables cosi’ come viene inserito nel sistema.
IMPORTANTE: Sanet non salva nel log degli eventi questa operazione.
IMPORTANTE: I dati dell’allarme non vengono pre-processati in nessun modo. L’allarme viene processato da entables cosi’ come viene fornito.
Per fare push di un allarme in entables bisogna usare il comando:
sanet-manage push_alarm [opzioni] [ dati allarme in formato JSON ]
Esempio:
sanet-manage push_alarm '{ "dato" : 10 }'
L’allarme deve essere un dizionario di attributi chiave/valore codificato in formato JSON valido.
Esempio: Dato il seguente allarme:
{ "campo1": "hello", "campo2": "world", "campo3": 1234 }
Il comando e’:
sanet-manage push_alarm '{ "campo1" : "hello", "campo2" : "world", "campo3" : 1234 }'
sanet-manage push_alarm --stdin { "campo1" : "hello", "campo2" : "world", "campo3" : 1234 } Ctrl+d
Per specificare un attributo dell’allarme da environemnt bisogna definire una variabile d’ambiente con il seguente nome:
EVENT_PUSH_{nome}={valore}export EVENT_PUSH_campo1=ciao sanet-manage push_alarm --env
L’allarme inviato ad entables sara’:
{ "campo1" : "ciao" }
Ogni allarme deve avere due attributi obbligatori.
IMPORTANTE: in assenza di questi due attributi, Sanet calcola automaticamente un valore da asseganre ad entrambi.
Attributo Descrizione Default tenantid UUID del tenant a cui associare l’allarme. (vedi opzione –tenant) UUID del tentant primario uuid UUID univoco dell’alarme Calcolato nuovo
Configurazione di entables:
./bin/entables -t notify -A DEFAULT -j SMTP --smtp_rcpt_to 'root' --smtp_message '${rawalarm}' --smtp_subject 'Evento custom'
Push dell’allarme:
sanet-manage push_alarm '{ "val":10 }'
Invio semplice di allarmi via SMTP:
entables -t notify -F DEFAULT entables -t notify -A DEFAULT -j SMTP --smtp_rcpt_to '${mail_to}' --smtp_message '${mail_body}' --smtp_xheaders '${mail_xheaders}' --smtp_subject '${mail_subject}'
Push di un evento custom. Il campo “mail” conviene i parametri che entables riconosce ed espande con i tag buitin:
sanet-manage push_alarm -L 10 '{ "mail": { "to":"root", "subject": "evento custom", "body": "corpo" } }'
Oppure:
sanet-manage push_alarm -L 10 --stdin '{ "mail": { "to":"root", "subject": "evento custom", "body": "corpo" } }' Ctrl+d
E’ possibile distinguere gli allarmi generati da sanet da quelli pushed attraverso i match disponibili di Entables.
Per dettagli si rimanda alla documentazione di Entables: match Attributes.
Esempio:
entables -t notify -F DEFAULT
entables -t notify -A DEFAULT -m attr --attr_alarmtype "normal" -j SYSLOG --syslog_msg "normale"
entables -t notify -A DEFAULT -m attr --attr_alarmtype "pushed" -j SYSLOG --syslog_msg "pushed"
3.11. Trap SNMP¶
Contenuti
- Teoria e gestione del Monitoraggio
- Concetti di base del monitoraggio
- Gerarchia del monitoraggio
- Tenant
- Agenti di monitoraggio
- Priorita’ logica dei controlli e livelli di priorita’
- Elementi Monitorabili (dagli agenti)
- Raccolta dati e controlli
- Datagroup
- Cos’e’ un datagroup
- Come definire un datagroup
- Gestione dei datagroup a parte degli agenti: Esecuzione
- Attributi di un datagroup e sotto-elementi di configurazione
- Dipendenze tra datagroup (dependson)
- I Datasource
- Le Condition
- Esecuzione di script automatica con variazioni di stato
- Regole di valutazione di Datasource e Condition
- Parametri opzionali
- Timegraph
- Sospensione e Riattivazione di un datagroup
- Configurazione avanzata dello scheduling
- Datagroup
- Template di Configurazione
- Monitoraggio dei nodi
- Monitoraggio dei interfacce
- Link tra nodi/interfacce
- Monitoraggio degli storage
- Monitoraggio dei servizi
- Monitoraggio di device generici
- Gestione Messaggi/Allarmi
- Calendari e range temporali
- Eventi “Push”
- Trap SNMP
- Concetti di base del monitoraggio
3.11.1. Introduzione¶
Sanet puo’ ricevere TRAP SNMP, storicizzarle all’interno del proprio Log ed eventualmente cercare di processarle.
La ricezione delle trap e’ delegata ad un processo di appoggio NON ATTIVO DI DEFAULT.
3.11.2. Flusso di ricezione¶
Il flusso di elaborazione e’ il seguente:
- La trap viene ricevuta dal processo delegato alla ricezione delle TRAP
- La trap viene storicizzata
- Sanet cerca di associare la trap ad un nodo di sanet e processare la trap con un datagroup passivo.
- Eventuali allarmi generati dal datagroup (dalle sue condition) vengono inviati ad entables
SANET SERVER
+------------------------------------------------+
| |
| (1) +-------+ (3) (4) |
switch ------*trap*-------> | trapd |------> datagroup------*alarm*-------> ENTABLES ------> MAIL
| +-------+ | |
| | | |
| (2) | | |
| `----------------`---> LOG |
| |
+------------------------------------------------+
3.11.3. Limiti della gestione delle Trap SNMP¶
3.11.3.1. Elmenti monitorabili¶
Al momento il sistema di gestione della trap non consente di sfruttare il meccanismo di calcolo automatico dell’ifindex/stindex/swrunindex/devindex. (Vedere ad esempio Interfacce e ifindex)
Questo significa che e’ possibile associare le trap ricevute solo a nodi (e i loro datagroup) in maniera automatica.
NOTA: Tentare di associare trap a nodi o interfacce e’ possibile con sistemi non facilmente automatizzabili.
Per questo motivo tutti i datagroup passivi che si vogliono implementare devono essere implementati per essere applicabili solo a nodi (o node template).
3.11.3.2. Limite a cosa e’ possibile gestire nelle espressioni¶
Le espressioni di datasource/condition di datagroup passivi sono limitate.
- Non e’ possibile chiedere valori di OID diverse da quelle contenute nella varbind list della TRAP.
- Non e’ possibile effettuare SNMP Walk o utilizzare altre funzioni che si basano su operazioni di walk snmp.
- L’accesso a simboli speciali (ifindex, linked_ifindex, cluster instance, ecc) produrra eccezioni con conseguente stato uncheckable.
3.11.3.3. Trap SNMP non gestite¶
Sanet potrebbe non essere in grado di processare le trap in input per due motivi:
- Non riesce ad associare l’indirizzo IP sorgente della trap a nessun nodo. (Vedi Associazione con i nodi di sanet)
- Non riesce a processare la trap attraverso nessun datagroup passivo definito per quel nodo. ( Vedi Configurare un datagroup per processare le trap ).
Quando una di queste due condizioni si verifica Sanet invia una mail per segnalare la mancata gestione delle trap.
Si veda il paragrafo Configurazione Notifica delle TRAP non gestite per i dettagli.
3.11.3.4. Associazione con i nodi di sanet¶
Le TRAP SNMP contengono solo l’indirizzo IP sorgente del noto che ha generato la trap.
Sanet cerca di individuare a quale nodo associare la trap in fase di memorizzazione del log.
Se Sanet non riesce ad individuare il nodo, la trap viene solo semplicemente memorizzata con indicazione solo dell’indirizzo IP sorgente.
3.11.3.4.1. Algoritmo per trovare il nodo di sanet¶
- Calcola il FQDN (Full Qualified Domain Name) dall’indirizzo IP sorgente della trap
- Calcola il DN (Domain Name) dell’host su cui e’ in esecuzione Sanet
- Rimuovi il DN dal FQDN della trap.
- Cerca in sanet il nome del nodo corrispondente.
3.11.4. Configurazione¶
3.11.4.1. Abilitare la ricezione delle trap¶
Indicare nel file di configurazione l’indirizzo su cui mettere in ascolto Sanet per le TRAP.
Esempio:
SNMPTRAP_LISTEN = ('0.0.0.0', 162)
3.11.4.2. Configurare un datagroup per processare le trap¶
Per fare in modo che un datagroup venga utilizzato da Sanet per processare delle TRAP bisogna:
- Configurare il datagroup come passivo impostando il min-period a zero.
- Configurare il campo passive-match del datagroup inpostando la OID della trap da processare.
Esempio:
datagroup-template dgtrap
...
passive-match 1.3.6.1.6.3.1.1.5.3
minperiod 0
...
exit
Important
Specificando il passive-match come espressione regolare e’ possibile fare match di OID parziali o sub-OID.
Esempio:
datagroup-template dgtrap
...
passive-match regex:^1.3.6.1.6.*
minperiod 0
...
exit
3.11.4.3. Configurazione Notifica delle TRAP non gestite¶
- Nel file di configurazione di Sanet (settings.py) si possono specificare i parametri (from, to, body) per l’invio di mail in due casi:
- Trap ricevute ma non associate a nessun nodo. Sono definite trap sconosciute o unknown.
- Trap ricevute, associate ad un nodo con successo, ma non processate da alcun datagroup. Sono definite trap non gestite o unmanaged.
Nel soggetto/corpo della mail e’ possibile utilizzare delle wildcard per fornire maggiori dettagli sulla trap segnalata.
SNMPTRAP_MAIL_CONF = {
'from': 'sanet.trapd@localhost',
#
# Settings for TRAPs from unknown hosts
#
'unknown': {
# You can use the following wildcard inside the subject/body text:
#
# {{receive_time}} = timestamp
# {{source_ip}} = Source IP
# {{trap_oid}} = TRAP OID
# {{trap_msg}} = Verbose TRAP description
#
'to' : 'root@localhost',
'subject' : '[sanet trapd] Trap from unknown host {{source_ip}}',
'body' : 'Received SNMP Trap at {{receive_time}}.\n\n{{trap_msg}}s',
},
#
# Settings for unhandled TRAPs linked to sanet nodes
#
'unmanaged': {
# Default notification address. If a node specifies the 'notify-address'
# field, the field will be used instead of this default.
'to' : 'root@localhost',
# You can use the following wildcard inside the subject/body text:
#
# {{receive_time}} = timestamp
# {{source_ip}} = Source IP
# {{trap_oid}} = TRAP OID
# {{trap_msg}} = Verbose TRAP description
# {{sanet_node}} = Sanet node name
#
'subject' : '[sanet trapd] Unmanaged TRAP from {{source_ip}} for node {{sanet_node}}',
'body' : 'Received SNMP Trap at {{receive_time}}.\n\n{{trap_msg}}',
}
}
3.11.4.4. Trap non gestite e notify-address¶
Se la configurazione di un nodo specifica l’attributo notify-address, le trap unmanaged vengono inviate all’indirizzo indicato mentre l’indirizzo specificato in configurazione nella sezione ‘unmanaged’ viene ignorato.
3.11.5. Gestione trap non ricevute e stato dei datagroup¶
E’ possibile che le Trap non vengano ricevute. Questo potrebbe lasciare un datagroup (e le sue condition) in uno stato inconsistente.
E’ possibile forzare lo stato UP o DOWN di un intero datagroup o di alcune sue condition con il comando:
sanet-manage force_dg_status [options] <datagroup path>
Le opzioni disponibili sono:
--status STATUS Codice dello stato: UP o DN
--tenant TENANT Nome del tenant. Default: il tenant primario
--reason REASON Verbstatus che comparira' nei log
--conditions CONDITIONS Elenco coi nomi delle condition da aggiornare. Default: tutte.
-l LOGLEVEL Livello di verbosita dell'output
Esempio:
sanet-manage force_dg_status 'localhost;;dgtrap' --reason "test" --status UP
3.11.6. Trap e agenti remoti¶
E’ possibile configurare gli agenti remoti per ricevere le trap e “inoltrarle” al server centrale.
Questo permette di ricevere trap anche da apparati che non sono in grado di comunicare direttamente con il server centrale.
switch -----*TRAP*--------------------------+
+----> +--------+ +----------+
| SANETD |----> | ENTABLES |
+------------+ .....> +--------+ +----------+
switch -----*TRAP*----->|remote agent|.......
+------------+
Per ottenere questo risultato e’ necessario:
- Abilitare le trap SNMP sul server centrale (anche se potrebbe non essere in grado di riceverle)
- Abilitare le trap SNMP sugli agenti remoti. Vedi sezione: Trap SNMP.