Granularità e conservazione dei dati

Aggregazione dei valori dei dati

Il servizio di monitoraggio raccoglie vari dati, tra cui l’utilizzo della sessione utente, i dettagli sulle prestazioni di accesso dell’utente, i dettagli del bilanciamento del carico della sessione e le informazioni relative alla connessione e ai guasti della macchina. I dati vengono aggregati in modo diverso a seconda della categoria. Comprendere l’aggregazione dei valori dei dati presentati utilizzando le API del metodo OData è fondamentale per l’interpretazione dei dati. Ad esempio:

• Per un determinato periodo di tempo si verificano errori relativi alle sessioni connesse e alle macchine. Pertanto, sono espressi come valori massimi in un periodo di tempo.
• Logon Duration (Durata dell’accesso) è una misura della durata del tempo, quindi viene esposta come media in un periodo di tempo.
• Logon Count (Conteggio degli accessi) e Connection Failures (Errori di connessione) sono conteggi di occorrenze in un determinato periodo di tempo, pertanto vengono espressi come somme nell’arco di un periodo di tempo.

Valutazione simultanea dei dati

Le sessioni devono essere sovrapposte per essere considerate simultanee. Tuttavia, quando l’intervallo di tempo è di 1 minuto, tutte le sessioni in quel minuto (che si sovrappongano o meno) sono considerate simultanee. La dimensione dell’intervallo è così piccola che il sovraccarico delle prestazioni correlato al calcolo della precisione non ha sostanzialmente valore. Se le sessioni si verificano nella stessa ora, ma non nello stesso minuto, non vengono considerate sovrapposte.

Correlazione delle tabelle di riepilogo con dati non elaborati

Il modello di dati rappresenta le metriche in due modi diversi:

• Le tabelle di riepilogo rappresentano viste aggregate delle metriche in granularità al minuto, ora e giorno.
• I dati non elaborati rappresentano singoli eventi o lo stato corrente individuati nella sessione, nella connessione, nell’applicazione e in altri oggetti.

Quando si tenta di correlare i dati tra le chiamate API o all’interno del modello di dati stesso, è importante comprendere i seguenti concetti e limitazioni:

• Nessun dato di riepilogo per intervalli parziali. I riepiloghi delle metriche sono progettati per soddisfare le esigenze delle tendenze storiche per lunghi periodi di tempo. Queste metriche vengono aggregate nella tabella di riepilogo per intervalli completi. Non ci sono dati di riepilogo per un intervallo parziale all’inizio (dati più vecchi disponibili) della raccolta dati né alla fine. Quando si visualizzano aggregazioni di un giorno (Interval=1440), ciò significa che i primi e i più recenti giorni incompleti non hanno dati. Sebbene possano esistere dati non elaborati per questi intervalli parziali, non vengono mai riassunti. Estrarre la SummaryDate minima e massima da una particolare tabella di riepilogo per determinare il primo e l’ultimo intervallo aggregato per una particolare granularità dei dati. La colonna SummaryDate (Data riepilogo) rappresenta l’inizio dell’intervallo. La colonna Granularity (Granularità) rappresenta la lunghezza dell’intervallo per i dati aggregati.
• Correlazione in base al tempo. Le metriche vengono aggregate nella tabella di riepilogo per intervalli completi come descritto nella sezione precedente. Possono essere utilizzati per le tendenze storiche, ma gli eventi non elaborati potrebbero essere più attuali nello stato di quanto è stato riassunto per l’analisi delle tendenze. Qualsiasi confronto temporale tra riepilogo e dati non elaborati deve tenere conto che non vi sono dati di riepilogo per intervalli parziali che potrebbero verificarsi o per l’inizio e la fine del periodo di tempo.
• Eventi mancati e latenti. Le metriche aggregate nella tabella di riepilogo potrebbero risultare leggermente imprecise se gli eventi non vengono rilevati o sono latenti nel periodo di aggregazione. Sebbene il servizio di monitoraggio cerchi di mantenere uno stato corrente accurato, non torna indietro nel tempo per rielaborare l’aggregazione nelle tabelle di riepilogo per eventi mancanti o latenti.
• Alta disponibilità della connessione. Durante l’alta disponibilità della connessione, ci sono lacune nel conteggio dei dati di riepilogo delle connessioni correnti, ma le istanze di sessione sono ancora in esecuzione nei dati non elaborati.
• Periodi di conservazione dei dati. I dati nelle tabelle di riepilogo vengono conservati in una pianificazione di pulizia diversa dalla pianificazione per i dati non elaborati relativi agli eventi. I dati potrebbero essere mancanti perché sono stati eliminati dal riepilogo o dalle tabelle non elaborate. Anche i periodi di conservazione potrebbero differire a seconda delle diverse granularità dei dati di riepilogo. I dati con granularità inferiore (minuti) vengono puliti più rapidamente rispetto ai dati con granularità più elevata (giorni). Se i dati mancano da una granularità a causa della pulizia, si potrebbero trovare in una granularità più elevata. Poiché le chiamate API restituiscono solo la granularità specifica richiesta, se non si ricevono dati per una granularità non significa che i dati non esistano per una granularità superiore per lo stesso periodo di tempo.
• Fusi orari. Le metriche vengono memorizzate con timestamp UTC. Le tabelle di riepilogo sono aggregate in base ai limiti di un’ora del fuso orario. Per i fusi orari che non utilizzano limiti di un’ora, potrebbe esserci qualche discrepanza riguardo a dove i dati sono aggregati.

Granularità e conservazione

La granularità dei dati aggregati recuperati da Monitor è una funzione dell’intervallo temporale (T) richiesto. Le regole sono le seguenti:

• 0 < T <= 30 giorni d’uso della granularità all’ora
• T > 31 giorni d’uso della granularità al giorno

I dati richiesti che non provengono da dati aggregati provengono dalle informazioni non elaborate sulla sessione e sulla connessione. Questi dati tendono a crescere rapidamente e quindi hanno le proprie impostazioni di pulizia. La pulizia garantisce che solo i dati rilevanti siano conservati a lungo termine. Ciò garantisce prestazioni migliori pur mantenendo la granularità richiesta per la creazione di report.

Attenzione:

Non è possibile modificare i valori nel database del servizio Monitor.

La conservazione dei dati per lunghi periodi ha le seguenti implicazioni sulle dimensioni della tabella:

• Dati orari. Se i dati orari possono rimanere nel database per un massimo di due anni, un sito di 1000 gruppi di consegna può causare la crescita del database come segue:

  1000 gruppi di consegna x 24 ore al giorno x 365 giorni all’anno x 2 anni = 17.520.000 righe di dati. L’impatto sulle prestazioni di una quantità così elevata di dati nelle tabelle di aggregazione è significativo. Poiché i dati della dashboard sono ricavati da questa tabella, i requisiti relativi al server del database potrebbero essere notevoli. Una quantità eccessiva di dati può avere un impatto significativo sulle prestazioni.

• Dati di sessioni ed eventi. Questi sono i dati raccolti ogni volta che viene avviata una sessione e viene effettuata una connessione/riconnessione. Per un sito di grandi dimensioni (100.000 utenti), questi dati crescono rapidamente. Ad esempio, due anni di queste tabelle raccoglierebbero più di un TB di dati, richiedendo un database di livello aziendale di fascia alta.