Parliamo di collezione dati

Introduzione

Uno degli aspetti più importanti e sicuramente il più utilizzato negli ultimi tempi è quello della collezione dei dati per la succesiva elaborazione ed analisi.
Il modo più semplice ed immediato per eseguire l’analisi dei dati memorizzati è quello di generare dei grafici che ne rappresentano in modo immediato l’andamento.
La collezione dei dati può avvenire essenzialmente in due modi che possiamo chiamare “Diretto” e “Indiretto”.

Collezione dati diretta

Capitanato dal protocollo SNMP questo metodo vede il server impegnato nella collezione dei dati in modo temporizzato secondo uno scheduler ben definito. Il device remoto deve supportare il procollo SNMP ed esporre le informazioni richieste per il monitoraggio, il server provvederà ad eseguire le oppurtune chiamate SNMP per ogni OID coinvolto nella collezione, dove ad ogni OID corrisponde un valore da monitorare. I dati così collezionati vengono in genere memorizzati in un database circolare oppure su un database tradizionale.

Collezione indiretta

Questo approccio stà crescendo molto negli ultimi tempi soprattutto con l’avvento di dispositivi in grado di avere un accesso diretto ad internet ed essere in grado di elaborare i dati ed inviarli in modo autonomo al server di registrazione. Anche in questo metodo il database può essere di tipo circolare o tradizionale

Collezione diretta

Il protoccollo SNMP

Riporto di seguito la descrizione presente su wikipedia:

In informatica e telecomunicazioni Simple Network Management Protocol (SNMP) è un protocollo di rete che appartiene alla suite di protocolli Internet definito dalla IETF (Internet Engineering Task Force). Il protocollo opera al livello 7 del modello OSI e consente la configurazione, la gestione e la supervisione (monitoring) di apparati collegati in una rete (siano essi nodi interni di commutazione come i dispositivi di rete e nodi terminali di utenza), riguardo a tutti quegli aspetti che richiedono azioni di tipo amministrativo (management).

In breve un sistema SNMP è costituito da “Managers” e “Agents” che possono dialogare tra loro. In genere, come detto, è il manager che invia delle richieste all’agent in base ad un file di definizione delle informazioni che viene chiamato MIB. Il MIB contiene la descrizione di tutti i parametri che sono leggibili per il tipo di oggetto e che vengono chiamati OID.
Un Manager può anche ricevere delle comunicazioni dall’agent, ed in questo caso ci riferiamo all’invio di TRAP.
Le TRAP sono principalmente utilizzate per l’invio di informazioni di allerta o in condizioni particolari quando il dato è variato o assume un valore particolare.

Perchè un sistema SNMP funzioni è necessaria appunto la presenza di un server capace di interrogare gli agent o in grado di ricevere informazioni dagli agents. Viceversa i devices devono supportare ed ospitare un agent in gradi di comunicare con il manager.
Questa funzionalità non è sempre presente nei devices di rete o se presente non con tutte le funzionalità. Ad esempio in molti casi il device ha la funzionalità SNMP ma solamente in letture e non ha la possibilità di inviare TRAP.

Inoltre il funzionamento del MIB file è abbastanza complicato da leggere e l’indicazione dei parametri di gestione complicata da una codifica ad albero numerata.
Ecco un esempio di una lista di OOID

Iso (1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4).card(1).slotCps(2)­
.­cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1).cpsModuleModel(3).3562.3

oppure

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

Va comunque detto che SNMP è il modo più comunemente utilizzato per la gestione dei dati di rete ed è quindi molto diffuso e conosciuto da gestori di rete di tutto il mondo.

Collezione Indiretta

Questo approccio è quello più usato nel nuovo mondo dell’IoT. La crescita di potenza di elaborazione dei dispositivi di rete e la loro capacità di interconnessione alla rete li ha resi capaci di poter interagire in modo diretto con un’entità esterna.
Basato in genere su chiamate API REST o RESTFULL l’invio dei dati avviene con procollo HTTP scambiando i dati con la tecnologia JSON.
JSON
JSON, acronimo di JavaScript Object Notation, è un formato adatto all’interscambio di dati fra applicazioni client-server (fonte wikipedia).
Con una semplice sintassi ereditata dal linguaggio Java Script, JSON permette di descrivere dati in modo serializzato e ad albero, in modo alternativo ad XML.
Ecco un semplice esempio di un dato rappresnetato in json:

{"menu": {
 "id": "file",
 "value": "File",
 "popup": {
 "menuitem": [
 {"value": "New", "onclick": "CreateNewDoc()"},
 {"value": "Open", "onclick": "OpenDoc()"},
 {"value": "Close", "onclick": "CloseDoc()"}
 ]
 }
 }}
API REST o RESTFULL

Il REST o RESTFULL non è propriamente uno standard di scambio dati ma più una linea guida sul metodo di interscambiare i dati in modo semplice ed efficace.
Il client invia una richiesta HTTP GET o POST al server inviando i dati necessari per essere riconosciuti. Il server elabora la richiesta e risponde con un formato json. I dati possono essere passati sull’indirizzo con il metodo GET oppure incorporati anche’essi in una struttura json con il metodo POST.

Questo un esempio di una chiamata ad un nostro server con metodo GET:
http://dev.mywaver.it/apitest/e034d436-9311-4293-b39e-29cdbb0788bc/?value=25

Notare in questo esempio l’uso di un UUID di riconoscimento del dispositivo ed il passaggio del valore 25 al server.

Questa la risposta dal server in JSON:

{
 "result":"1",
 "msg":"Result OK",
 "contents":{
 "uuid":"e034d436-9311-4293-b39e-29cdbb0788bc",
 "value":"25"
 }
 }
UUID

Da Wikipedia https://it.wikipedia.org/wiki/UUID

L'identificativo univoco universale (universally unique identifier o UUID) è un identificativo standard usato nelle infrastrutture software, standardizzato dalla Open Software Foundation (OSF) come parte di un ambiente distribuito di computazione.
Lo scopo dell'UUID è di abilitare un sistema distribuito all'identificazione di informazioni in assenza di un sistema centralizzato di coordinamento. In questo contesto la chiave univoca dovrebbe implicare "l'univocità" pratica senza "garantirla". Il fatto che le chiavi siano in numero finito implica che due entità potrebbero avere la stessa chiave identificativa. In pratica, l'ampiezza dello spazio delle chiavi e il loro processo di generazione offrono sufficienti garanzie che la stessa chiave non venga assegnata a due entità differenti. Chiunque può creare un UUID e usarlo con ragionevole probabilità che non venga usato da nessun altro. Le informazioni associate all'uuid possono essere in seguito combinate in un singolo database senza necessità di dover risolvere eventuali conflitti.
L'UUID è composto da 16-byte (128-bit). Nella sua forma canonica, l'UUID è rappresentato da 32 caratteri esadecimali, visualizzati in cinque gruppi separati da trattini, nella forma 8-4-4-4-12 per un totale di 36 caratteri (32 esadecimali e quattro trattini). Ad esempio:
550e8400-e29b-41d4-a716-446655440000
Ci sono 340 282 366 920 938 463 463 374 607 431 768 211 456 possibili UUID (16^32), o circa 3 × 10^38.

In questo sito è possibile generare UUID nel formato corretto: https://www.uuidgenerator.net/
In pratica l’UUID viene utilizzato per identificare il dispositivo in modo univoco nella rete.

Database

Database circolari

Si definiscono database circolari quei database in grado di collezionare informazioni in modo che i dati più vecchi vengono rimossi a favore di quelli più nuovi.
In pratica il DB ha una dimensione prefissata di “N” righe e l’inserimento avverrà sempre nell’ultima riga provocando uno spostamento delle altre ed eliminazione dell’ultima.

DB Circolare

Sopra un esempio che riporta una breve sequenza di 6 valori che vengono ruotati ogni volta che un nuovo valore viene inserito, eliminando l’ultimo.

I due sistemi più famosi di gestione database circolari per le attività di monitoraggio della rete sono MRTG e RRDTools.

Il vantaggio enorme dell’uso di un database circolare stà nel controllo della dimensione massima del file che, essendo preconfigurato non varierà mai.
Questo approccio soffre però del problema di dover definire un intervallo di aggiormamento che deve essere rispettato.

Database tradizione

Per database tradizione intendo qualsiasi database lineare che non prevede una lunghezza fissa del numero di righe, come ad esempio qualsiasi Database Relazionale o non relazione come MySQL e MongoDB.
Faccio notare che MongoDB prevede la presenza di un tipo di collection (così si chiamano le tabelle dentro MongoDB) a lunghezza fissa che lavora in modo circolare.

Si può ovviamente simulare un DB circolare anche con un database tradizionale. Sarà infatti sufficiente tenere sempre il momento in cui il dato è stato scritto e provvedere alla cancellazione di tutti i record più vecchi di una certa data. In questo modo saremo in grado di contenere la dimensione del database ed avere una visione dei dati sempre coerente con le impostazioni iniziali.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.