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 espressa 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. È possibile determinare il primo e l’ultimo intervallo di aggregazione per una particolare granularità dei dati estraendo il valore SummaryDate minimo e massimo da una determinata tabella di riepilogo. 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 considerare 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 saranno lacune nel conteggio dei dati di riepilogo delle connessioni correnti, ma le istanze di sessione saranno 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 Director è una funzione dell’intervallo temporale (T) richiesto. Le regole sono le seguenti:

• 0 < T <= 1 ora - utilizza granularità al minuto
• 0 < T <= 30 giorni - utilizza granularità all’ora
• T > 31 giorni - utilizza 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. La pulizia garantisce prestazioni migliori pur mantenendo la granularità richiesta per la creazione di report. I clienti dei siti con licenza Premium possono modificare la conservazione della pulizia sul numero desiderato di giorni di conservazione, altrimenti viene utilizzato il valore predefinito.

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 di monitoraggio richiede il riavvio del servizio perché i nuovi valori abbiano effetto. Si consiglia di apportare modifiche al database del servizio di monitoraggio solo sotto la direzione di Citrix Support.

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

• Siti con licenza Premium: la conservazione della pulizia di tutte le impostazioni è limitata a 1000 giorni (Citrix consiglia 365 giorni).
• Siti con licenza avanzata: la conservazione della pulizia per tutte le impostazioni è limitata a 31 giorni.
• Tutti gli altri siti: la conservazione della pulizia per tutte le impostazioni è limitata a 7 giorni.

Eccezioni:

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

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 potrebbe avere un impatto significativo sulle prestazioni.

• Dati di sessioni ed eventi. 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.