Come e' organizzato XA

La struttura di XA e' complessa e mescola assieme elementi di una gerarchia ad albero con elenedi da grafo, ma se ci si limita all'interazione con gli elementi dell'asset di un cliente la complessita si riduce un minimo.

Possiamo immaginare di avere l'asset di un cliente e una serie di servizzi che puntano all'asset, andando ad arricchire l'informazione li presente, oppure aggiungendo funzionalita.

L'asset

Come asset definiamo tutto cio' che costituisce il perimetro fisico del cliente. L'asset e' definito in modo gerarchico dalle seguenti componenti (in ordine gerarchica decrescente: - Customer - Site - Group - Object - Metric_type - Metric - Service

Ogniuno di questi livelli contiene informazione, il customer definisce il cliente, i siti definiscono le filiali del cliente, etc. Ogni livelli e' connesso con un legame uno a molti con il livello sottostante, quindi un sito ha dei gruppi al suo interno, ma un gruppo non puo essere in piu siti. Esiste un eccezione che sono i gruppi, per la maggior parte del loro uso mantengono una relazione uno a molti con i metric_type, ma un oogetto puo essere contenuto in piu gruppi. Quindi diciamo che tra i gruppi e gli oggetti c'e' una relazione molti a molti.

Ogni elemento puo essere identificato da una serie di chiavi primarie che comprendono anche lo uuid del suo livello superiore. Questo ovviamente non e' vero per gli oggetti per via della natura molti a molti con i gruppi.

I servizzi che chiudono la fila, sono una seconda eccezione: hanno una importanza gerarchica simile alle metriche, possono essere legate alle metriche con legame molti a molti ma possono anche non essere legate alle metriche e vivere completamente slegate dall'asset. I servizzi rappresentano informazione aggiuntiva calcolata partendo da valori del cliente o altri dati, non necessariamente sono legate all'asset. Se sono legate all'asset lo sono tramite le metriche, in questi casi esiste un puntamento verso tutte le metriche che hanno contribuito a formare il servizio.

La struttura dal customer al servizio rappresenta l'asset e viene chiamato albero.

Per navigare l'albero esistono API che permettono di ottenere le informazioni di legame di un layer con gli altri. Per fare un esempio, se conosco una metric e voglio sapere in quale object questa e' contenuta, nei dati della metric stessa e' presente lo uuid del metric_type che la contiene. Con quel uuid, posso ricavare i dettagli del metric_type in cui e' presente lo uuid del object che lo contiene. Con quel uuid posso andare a chiedere i dettagli dell'object che mi interessava conoscere.

E' altrettando vero nell'altra direzione, noto un objetc posso sapere tutti gli metric_type che lo compongono, sceltone uno posso chiedere tutte le metrics che lo compongono.

Questo modo di navigare l'albero trova alcune variazioni quando si cerca di superare i layer con relazioni molti a molti. Per conoscere quali groups contengono un object e viceversa, ci sono API apposta che dato uno dei due layer, ti restituisce il secondo. Questo vale anche per i services avengo la stessa natura molti a molti.

Esistono scorciatoie per navigare l'albero, queste scorciatorie vanno sotto forma del set di API tree_hierarchy. Questa API sono disegnate per recuperare un elemento nell'albero con tutti i suoi legami con i layer superiori.

Time series

L'asset rapresenta gli oggetti che producono dati, ma i dati stessi vengono raccolti in un posto diverso. Nello specifico nelle tabelle delle serie temporali. Tali serie si dividono in due tipologie, serie di stato e serie di valore.

Le serie di stato sono una successione di informazioni raccolte in dizionari, possono contenere ogni tipo di informazione e portano con se un indice di gravita. Le serie di valore sono successioni di numeri, ideali per raccogliere dati numerici come temperatura, velocita etc.

Le metrics sono il layer in cui vengono salvate queste serie. Ogni metric e' legata direttamente ad una e una sola serie temporale, sia essa di stato o di valore.

I services possono essere legati a serie temporali a loro volta, e , a differenza delle metrics possono puntare conemporaneamente sia a serie di valore che di stato.

Informazioni aggiuntive

Le ralazioni non finiscono con l'asset, esistono una miriade di informazioni aggiuntive esplorabili, come gli user, le dashboard e cosi via. Il modo di navigare questi legami e' pero lo stesso con cui si naviga l'albero.

La completa connessione tra tutti gli elementi richiamabili con API e' presentata nello schema qui di seguito