Granularità e conservazione dei dati

Aggregazione dei valori dei dati

Il Servizio Monitor raccoglie vari dati, inclusi l’utilizzo delle sessioni utente, i dettagli sulle prestazioni di accesso utente, i dettagli sul bilanciamento del carico delle sessioni e le informazioni sui guasti di connessione e macchina. I dati vengono aggregati in modo diverso a seconda della loro categoria. Comprendere l’aggregazione dei valori dei dati presentati utilizzando le API del metodo OData è fondamentale per interpretare i dati. Ad esempio:

• Le sessioni connesse e i guasti della macchina si verificano in un periodo. Pertanto, sono esposti come massimi su un periodo di tempo.
• La durata dell’accesso è una misura della durata del tempo, pertanto è esposta come media su un periodo di tempo.
• Il conteggio degli accessi e i guasti di connessione sono conteggi di occorrenze in un periodo, pertanto sono esposti come somme su un periodo di tempo.

Valutazione dei dati concorrenti

Le sessioni devono essere sovrapposte per essere considerate concorrenti. Tuttavia, quando l’intervallo di tempo è di 1 minuto, tutte le sessioni in quel minuto (indipendentemente dal fatto che si sovrappongano) sono considerate concorrenti. La dimensione dell’intervallo è così piccola che il sovraccarico di prestazioni coinvolto nel calcolo della precisione non giustifica il valore aggiunto. Se le sessioni si verificano nella stessa ora, ma non nello stesso minuto, non sono considerate sovrapposte.

Correlazione delle tabelle di riepilogo con i dati grezzi

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

• Le tabelle di riepilogo rappresentano viste aggregate delle metriche con granularità temporali per minuto, ora e giorno.
• I dati grezzi rappresentano eventi individuali o lo stato corrente tracciati nella sessione, connessione, applicazione e altri oggetti.

Quando si tenta di correlare i dati tra 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 su 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 (Intervallo=1440), ciò significa che i primi e i più recenti giorni incompleti non contengono dati. Sebbene i dati grezzi possano esistere per tali intervalli parziali, non vengono mai riepilogati. È possibile determinare l’intervallo aggregato più vecchio e più recente per una particolare granularità dei dati estraendo il min e il max SummaryDate da una specifica tabella di riepilogo. La colonna SummaryDate rappresenta l’inizio dell’intervallo. La colonna Granularity rappresenta la lunghezza dell’intervallo per i dati aggregati.
• Correlazione per tempo. Le metriche vengono aggregate nella tabella di riepilogo per intervalli completi, come descritto nella sezione precedente. Possono essere utilizzate per le tendenze storiche, ma gli eventi grezzi potrebbero essere più attuali nello stato rispetto a quanto riepilogato per l’analisi delle tendenze. Qualsiasi confronto basato sul tempo tra dati di riepilogo e dati grezzi deve considerare che non esistono dati di riepilogo per intervalli parziali che potrebbero verificarsi o per l’inizio e la fine del periodo di tempo.
• Eventi persi e latenti. Le metriche aggregate nella tabella di riepilogo potrebbero essere leggermente imprecise se gli eventi vengono persi o sono latenti rispetto al periodo di aggregazione. Sebbene il Monitor Service tenti di mantenere uno stato corrente accurato, non torna indietro nel tempo per ricalcolare l’aggregazione nelle tabelle di riepilogo per gli eventi persi o latenti.
• Alta disponibilità della connessione. Durante l’alta disponibilità della connessione, ci saranno lacune nei conteggi dei dati di riepilogo delle connessioni correnti, ma le istanze di sessione saranno comunque in esecuzione nei dati grezzi.
• Periodi di conservazione dei dati. I dati nelle tabelle di riepilogo vengono conservati con una pianificazione di pulizia diversa rispetto alla pianificazione per i dati di eventi grezzi. I dati potrebbero mancare perché sono stati eliminati dalle tabelle di riepilogo o grezze. I periodi di conservazione potrebbero anche differire per diverse granularità dei dati di riepilogo. I dati a granularità inferiore (minuti) vengono puliti più rapidamente rispetto ai dati a granularità superiore (giorni). Se i dati mancano da una granularità a causa della pulizia, potrebbero essere trovati in una granularità superiore. Poiché le chiamate API restituiscono solo la granularità specifica richiesta, non ricevere 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 archiviate con timestamp UTC. Le tabelle di riepilogo vengono aggregate sui confini orari dei fusi orari. Per i fusi orari che non rientrano nei confini orari, potrebbe esserci qualche discrepanza su dove i dati vengono aggregati.

Granularità e conservazione

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

• 0 < T <= 1 ora - utilizza la granularità al minuto
• 0 < T <= 30 giorni - utilizza la granularità oraria
• T > 31 giorni - utilizza la granularità giornaliera

I dati richiesti che non provengono da dati aggregati provengono dalle informazioni grezze di Sessione e Connessione. Questi dati tendono a crescere rapidamente e, pertanto, hanno una propria impostazione di pulizia. La pulizia garantisce che solo i dati rilevanti vengano conservati a lungo termine. La pulizia garantisce prestazioni migliori mantenendo la granularità richiesta per la reportistica. I clienti con siti con licenza Premium possono modificare la conservazione della pulizia al numero di giorni di conservazione desiderato, altrimenti viene utilizzato il valore predefinito. Nel caso in cui si sia verificata una perdita di connettività con il database del sito, Monitor Service utilizzerà i giorni di conservazione predefiniti per l’abilitazione Premium come specificato nella tabella seguente.

Per accedere alle impostazioni, eseguire i seguenti comandi PowerShell sul Delivery Controller™:

asnp Citrix.*
 Get-MonitorConfiguration
 Set-MonitorConfiguration -<setting name> <value>
<!--NeedCopy-->

Attenzione:

La modifica dei valori nel database del servizio Monitor richiede il riavvio del servizio affinché i nuovi valori abbiano effetto. Si consiglia di apportare modifiche al database del servizio Monitor solo sotto la direzione del supporto Citrix.

Le impostazioni GroomProcessUsageRawDataRetentionDays, GroomResourceUsageRawDataRetentionDays e GroomSessionMetricsDataRetentionDays sono limitate ai loro valori predefiniti di 1, mentre GroomProcessUsageMinuteDataRetentionDays è limitata al suo valore predefinito di 3. I comandi PowerShell per impostare questi valori sono stati disabilitati, poiché i dati di utilizzo del processo tendono a crescere rapidamente. Inoltre, le impostazioni di conservazione basate su licenza sono le seguenti:

• Siti con licenza Premium - la conservazione per la pulizia per tutte le impostazioni è limitata a 1000 giorni (Citrix consiglia 365 giorni).
• Siti con licenza Advanced - la conservazione per la pulizia per tutte le impostazioni è limitata a 31 giorni.
• Tutti gli altri siti - la conservazione del grooming per tutte le impostazioni è limitata a 7 giorni.

Eccezioni:

• GroomApplicationInstanceRetentionDays può essere impostato solo nei siti con licenza Premium.
• GroomApplicationErrorsRetentionDays e GroomApplicationFaultsRetentionDays sono limitati a 31 giorni nei siti con licenza Premium.

La conservazione dei dati per lunghi periodi ha le seguenti implicazioni sulle dimensioni delle tabelle:

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

  1000 gruppi di consegna x 24 ore/giorno x 365 giorni/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. Dato che i dati del dashboard sono estratti da questa tabella, i requisiti per il server di database potrebbero essere elevati. Quantità eccessivamente grandi di dati potrebbero avere un impatto drammatico sulle prestazioni.

• Dati di sessione ed evento. Dati raccolti ogni volta che viene avviata una sessione e viene stabilita 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 fascia alta a livello aziendale.