Granularité et rétention des données
Agrégation des valeurs de données
Le service Monitor collecte une variété de données, y compris l’utilisation des sessions utilisateur, les détails de performance de l’ouverture de session utilisateur, les détails de l’équilibrage de charge des sessions et les informations sur les échecs de connexion et de machine. Les données sont agrégées différemment selon leur catégorie. Comprendre l’agrégation des valeurs de données présentées à l’aide des API de méthode OData est essentiel pour interpréter les données. Par exemple :
- Les sessions connectées et les défaillances de machine se produisent sur une période donnée. Par conséquent, elles sont exposées comme des maximums sur une période de temps.
- La durée d’ouverture de session est une mesure de la durée, elle est donc exposée comme une moyenne sur une période de temps.
- Le nombre d’ouvertures de session et les échecs de connexion sont des comptes d’occurrences sur une période de temps, ils sont donc exposés comme des sommes sur une période de temps.
Évaluation des données concurrentes
Les sessions doivent se chevaucher pour être considérées comme concurrentes. Cependant, lorsque l’intervalle de temps est de 1 minute, toutes les sessions de cette minute (qu’elles se chevauchent ou non) sont considérées comme concurrentes : la taille de l’intervalle est si petite que la surcharge de performance impliquée dans le calcul de la précision ne justifie pas la valeur ajoutée. Si les sessions se produisent dans la même heure, mais pas dans la même minute, elles ne sont pas considérées comme se chevauchant.
Corrélation des tableaux récapitulatifs avec les données brutes
Le modèle de données représente les métriques de deux manières différentes :
- Les tableaux récapitulatifs représentent des vues agrégées des métriques avec des granularités temporelles par minute, heure et jour.
- Les données brutes représentent les événements individuels ou l’état actuel suivis dans la session, la connexion, l’application et d’autres objets.
Lorsque vous tentez de corréler des données entre les appels d’API ou au sein du modèle de données lui-même, il est important de comprendre les concepts et limitations suivants :
- Aucune donnée récapitulative pour les intervalles partiels. Les résumés de métriques sont conçus pour répondre aux besoins des tendances historiques sur de longues périodes. Ces métriques sont agrégées dans le tableau récapitulatif pour les intervalles complets. Il n’y aura pas de données récapitulatives pour un intervalle partiel au début (données les plus anciennes disponibles) de la collecte de données ni à la fin. Lors de l’affichage des agrégations d’une journée (Intervalle=1440), cela signifie que les premiers jours incomplets et les plus récents n’auront pas de données. Bien que des données brutes puissent exister pour ces intervalles partiels, elles ne seront jamais résumées. Vous pouvez déterminer l’intervalle agrégé le plus ancien et le plus récent pour une granularité de données particulière en extrayant les valeurs min et max de SummaryDate d’un tableau récapitulatif particulier. La colonne SummaryDate représente le début de l’intervalle. La colonne Granularity représente la longueur de l’intervalle pour les données agrégées.
- Corrélation par le temps. Les métriques sont agrégées dans le tableau récapitulatif pour des intervalles complets, comme décrit ci-dessus. Elles peuvent être utilisées pour les tendances historiques, mais les événements bruts peuvent être plus actuels dans l’état que ce qui a été résumé pour l’analyse des tendances. Toute comparaison temporelle des données récapitulatives aux données brutes doit prendre en compte qu’il n’y aura pas de données récapitulatives pour les intervalles partiels qui peuvent se produire ou pour le début et la fin de la période.
- Événements manqués et latents. Les métriques agrégées dans le tableau récapitulatif peuvent être légèrement inexactes si des événements sont manqués ou latents par rapport à la période d’agrégation. Bien que le service de surveillance tente de maintenir un état actuel précis, il ne revient pas en arrière pour recalculer l’agrégation dans les tableaux récapitulatifs pour les événements manqués ou latents.
- Haute disponibilité des connexions. Pendant la haute disponibilité des connexions, il y aura des lacunes dans les totaux de données récapitulatives des connexions actuelles, mais les instances de session continueront de s’exécuter dans les données brutes.
- Périodes de rétention des données. Les données des tableaux récapitulatifs sont conservées selon un calendrier de nettoyage différent de celui des données d’événements brutes. Des données peuvent être manquantes car elles ont été nettoyées des tableaux récapitulatifs ou bruts. Les périodes de rétention peuvent également différer pour différentes granularités de données récapitulatives. Les données de granularité inférieure (minutes) sont nettoyées plus rapidement que les données de granularité supérieure (jours). Si des données sont manquantes pour une granularité en raison du nettoyage, elles peuvent être trouvées dans une granularité supérieure. Étant donné que les appels d’API ne renvoient que la granularité spécifique demandée, ne recevoir aucune donnée pour une granularité ne signifie pas que les données n’existent pas pour une granularité supérieure pour la même période.
- Fuseaux horaires. Les métriques sont stockées avec des horodatages UTC. Les tableaux récapitulatifs sont agrégés sur des limites de fuseaux horaires horaires. Pour les fuseaux horaires qui ne tombent pas sur des limites horaires, il peut y avoir des divergences quant à l’endroit où les données sont agrégées.
Granularité et rétention
La granularité des données agrégées récupérées par Director est fonction de la période (T) demandée. Les règles sont les suivantes :
- 0 < T <= 1 heure utilise une granularité par minute
- 0 < T <= 30 jours utilise une granularité par heure
- T > 31 jours utilise une granularité par jour
Les données demandées qui ne proviennent pas de données agrégées proviennent des informations brutes de session et de connexion. Ces données ont tendance à croître rapidement et ont donc leur propre paramètre de nettoyage. Le nettoyage garantit que seules les données pertinentes sont conservées à long terme. Cela garantit de meilleures performances tout en maintenant la granularité requise pour les rapports. Les clients des sites sous licence Platinum peuvent modifier la rétention du nettoyage pour le nombre de jours de rétention souhaité, sinon la valeur par défaut est utilisée.
Pour accéder aux paramètres, exécutez les commandes PowerShell suivantes sur le Delivery Controller™ :
asnp Citrix.*
Get-MonitorConfiguration
Set-MonitorConfiguration -<setting name> <value>
<!--NeedCopy-->
Les paramètres suivants sont utilisés pour contrôler le nettoyage :
| Nom du paramètre | Nettoyage affecté | Valeur par défaut Platinum (jours) | Valeur par défaut non-Platinum (jours) | ||
|---|---|---|---|---|---|
| 1 | GroomSessionsRetentionDays | Rétention des enregistrements de session et de connexion après la fin de la session | 90 | 7 | |
| 2 | GroomFailuresRetentionDays | Enregistrements MachineFailureLog et ConnectionFailureLog | 90 | 7 | |
| 3 | GroomLoadIndexesRetentionDays | Enregistrements LoadIndex | 90 | 7 | |
| 4 | GroomDeletedRetentionDays | Entités Machine, Catalogue, DesktopGroup et Hyperviseur qui ont un LifecycleState « Supprimé ». Cela supprime également tous les enregistrements Session, SessionDetail, Summary, Failure ou LoadIndex associés. | 90 | 7 | |
| 5 | GroomSummariesRetentionDays | Enregistrements DesktopGroupSummary, FailureLogSummary et LoadIndexSummary. Données agrégées - granularité quotidienne. | 90 | 7 | |
| 6 | GroomMachineHotfixLogRetentionDays | Correctifs appliqués aux machines VDA et Controller | 90 | 90 | |
| 7 | GroomMinuteRetentionDays | Données agrégées - granularité à la minute | 3 | 3 | |
| 8 | GroomHourlyRetentionDays | Données agrégées - granularité horaire | 32 | 7 | |
| 9 | GroomApplicationInstanceRetentionDays | Historique des instances d’application | 90 | 0 | |
| 10 | GroomNotificationLogRetentionDays | Enregistrements du journal de notifications | 90 | ||
| 11 | GroomResourceUsageRawDataRetentionDays | Données d’utilisation des ressources - données brutes | 1 | 1 | |
| 12 | GroomResourceUsageMinuteDataRetentionDays | Données récapitulatives d’utilisation des ressources - granularité à la minute | 7 | 7 | |
| 13 | GroomResourceUsageHourDataRetentionDays | Données récapitulatives d’utilisation des ressources - granularité horaire | 30 | 7 | |
| 14 | GroomResourceUsageDayDataRetentionDays | Données récapitulatives d’utilisation des ressources - granularité journalière | 90 | 7 | |
| 15 | GroomProcessUsageRawDataRetentionDays | Données d’utilisation des processus - données brutes | 1 | 1 | |
| 16 | GroomProcessUsageMinuteDataRetentionDays | Données d’utilisation des processus - granularité à la minute | 3 | 3 | |
| 17 | GroomProcessUsageHourDataRetentionDays | Données d’utilisation des processus - granularité à l’heure | 7 | 7 | |
| 18 | GroomProcessUsageDayDataRetentionDays | Données d’utilisation des processus - granularité journalière | 30 | 7 | |
| 19 | GroomSessionMetricsDataRetentionDays | Données de métriques de session | 1 | 1 | |
| 20 | GroomMachineMetricDataRetentionDays | Données de métriques de machine | 3 | 3 | |
| 21 | GroomMachineMetricDaySummaryDataRetentionDays | Données récapitulatives des métriques de machine | 90 | 7 | |
| 22 | GroomApplicationErrorsRetentionDays | Données d’erreur d’application | 1 | 1 | |
| 23 | GroomApplicationFaultsRetentionDays | Données de défaillance d’application | 1 | 1 | |
Attention : La modification des valeurs dans la base de données du service Monitor nécessite le redémarrage du service pour que les nouvelles valeurs prennent effet. Il est conseillé de n’apporter des modifications à la base de données du service Monitor que sous la direction du support Citrix.
Remarques sur la rétention de l’épuration : GroomProcessUsageRawDataRetentionDays, GroomResourceUsageRawDataRetentionDays et GroomSessionMetricsDataRetentionDays sont limités à leurs valeurs par défaut de 1, tandis que GroomProcessUsageMinuteDataRetentionDays est limité à sa valeur par défaut de 3. Les commandes PowerShell permettant de définir ces valeurs ont été désactivées, car les données d’utilisation des processus ont tendance à augmenter rapidement. De plus, les paramètres de rétention basés sur la licence sont les suivants :
- Sites sous licence Premium - vous pouvez mettre à jour les paramètres de rétention de l’épuration ci-dessus pour n’importe quel nombre de jours.
- Sites sous licence Advanced - la rétention de l’épuration pour tous les paramètres est limitée à 31 jours.
- Tous les autres Sites - la rétention de l’épuration pour tous les paramètres est limitée à 7 jours.
Exceptions :
- GroomApplicationInstanceRetentionDays ne peut être défini que dans les Sites sous licence Premium.
- GroomApplicationErrorsRetentionDays et GroomApplicationFaultsRetentionDays sont limités à 31 jours dans les Sites sous licence Premium.
La conservation des données pendant de longues périodes aura les implications suivantes sur la taille des tables :
-
Données horaires. Si les données horaires sont autorisées à rester dans la base de données pendant une période allant jusqu’à deux ans, un site de 1000 groupes de mise à disposition pourrait entraîner la croissance de la base de données comme suit :
1000 groupes de mise à disposition x 24 heures/jour x 365 jours/an x 2 ans = 17 520 000 lignes de données. L’impact sur les performances d’une telle quantité de données dans les tables d’agrégation est significatif. Étant donné que les données du tableau de bord sont extraites de cette table, les exigences sur le serveur de base de données peuvent être importantes. Des quantités de données excessivement importantes peuvent avoir un impact considérable sur les performances.
-
Données de session et d’événement. Il s’agit des données collectées chaque fois qu’une session est démarrée et qu’une connexion/reconnexion est établie. Pour un site de grande taille (100 000 utilisateurs), ces données augmenteront très rapidement. Par exemple, deux ans de ces tables pourraient accumuler plus d’un To de données, nécessitant une base de données d’entreprise haut de gamme.