Granularité de données et rétention

Agrégation des valeurs de données

Monitor Service collecte les données, notamment l’utilisation de la session utilisateur, les détails des performances de l’ouverture de session utilisateur, les détails de l’équilibrage de charge de la session, et les informations de connexion et d’échec de machine. Les données sont agrégées différemment en fonction de leur catégorie. La compréhension de l’agrégation des valeurs de données présentées à l’aide de l’API OData Method est critique à l’interprétation des données. Par exemple :

  • Les sessions connectées et les échecs de machine se produisent sur une période de temps. Ils sont donc exposés comme valeurs maximales sur une période de temps.
  • La durée d’ouverture de session est une mesure de durée, par conséquent elle est exposée en tant que moyenne sur une période de temps.
  • Le nombre d’ouvertures de session et les échecs de connexion représentent des nombres d’occurrences sur une période de temps, et par conséquent sont exposés en tant que sommes sur une période de temps.

Évaluation des données simultanées

Les sessions doivent se chevaucher pour être considérées comme simultanées. Toutefois, lorsque l’intervalle de temps est de 1 minute, toutes les sessions de cette minute (qu’elles se chevauchent ou pas) sont considérées comme simultanées. La taille de l’intervalle est si petite que la surcharge de performance impliquée dans le calcul de la précision ne vaut 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 de tables de synthèse avec des données brutes

Le modèle de données représente des métriques de deux manières différentes :

  • Les tables de synthèse représentent des vues des mesures détaillées de l’agrégation par minute, heure et jour.
  • Les données brutes représentent des événements individuels ou l’état actuel de l’objet suivi dans la session, la connexion, l’application et autres objets.

Lorsque vous tentez de corréler les données dans les appels API ou dans le modèle de données lui-même, il est important de bien comprendre les concepts et les limitations suivantes :

  • Aucune données de synthèse pour les intervalles partiels. Des résumés de métriques sont conçus pour répondre aux besoins de tendances historiques sur de longues périodes. Les métriques sont agrégées dans la table de synthèse pour effectuer des intervalles. Il n’y a pas de données de synthèse pour un intervalle partiel au début (les plus anciennes données disponibles) de la collection de données ni à la fin. Lorsque vous affichez les agrégations d’une journée (intervalle = 1 440), ceci signifie que la premier et le dernier jour incomplet ne possède pas de données. Bien que des données brutes puissent exister pour des intervalles partiels, elles ne sont jamais synthétisées. Récupérez les valeurs minimales et maximales de SummaryDate pour une table de synthèse particulière pour déterminer le premier et le dernier intervalle d’agrégation pour une granularité de données particulière. La colonne SummaryDate représente le début de l’intervalle. La colonne Granularité représente la durée de l’intervalle pour les données agrégées.
  • Corrélation par heure. Les métriques sont agrégées dans la table de synthèse pour terminer les intervalles comme décrit dans la section précédente. Ils peuvent être utilisés pour les tendances historiques, mais les événements bruts peuvent être plus actifs dans l’état de ce qui a été résumé pour l’analyse de tendances. Toute comparaison temporelle de synthèse des données brutes doit prendre en compte le fait qu’aucune donnée de synthèse pour les intervalles partiels susceptibles de se produire ou pour le début et la fin de la période de temps.
  • Événements manqués et latents. Les mesures qui sont agrégées dans la table de synthèse peuvent être légèrement inexactes si les événements sont manqués ou latents pour la période d’agrégation. Bien que Monitor Service tente de conserver un état courant précis, il ne retourne pas dans le temps pour recalculer l’agrégation dans les tables de synthèse pour les événements manqués ou latents.
  • Haute disponibilité de connexion. Lors de la haute disponibilité de connexion, il existe des espaces dans les données de synthèse du nombre de connexions actives, mais les instances de session sont toujours en cours d’exécution dans les données brutes.
  • Périodes de rétention des données. Les données des tables de synthèse sont conservées sur un programme de nettoyage différent du programme des données brutes d’événement. Il se peut que les données soient manquantes, car elles ont été effacées depuis les tables de données de synthèse ou brutes. Les périodes de rétention peuvent également différer pour différentes granularités de données de synthèse. Les données de granularité inférieures (en minutes) sont nettoyées plus rapidement que les données de granularité supérieures (en jours). Si des données sont manquantes dans une granularité à cause du nettoyage, elles peuvent être détectées dans une meilleure granularité. Étant donné que les appels API retournent uniquement la granularité demandée, l’absence de réception de données pour un niveau de granularité ne signifie pas que les données n’existent pas pour une meilleure granularité pour la même période.
  • Fuseaux horaires. Les métriques sont stockées avec des horodatages UTC. Les tables de synthèse sont regroupées sur des limites de fuseau horaire. Pour les zones qui ne se trouvent pas dans les limites horaires, il se peut qu’il existe une différence pour laquelle les données sont agrégées.

Granularité et rétention

La granularité des données agrégées récupérées par le service Monitor est une fonction de la période de temps (T) demandée. Les règles sont les suivantes :

  • 0 < T <= 30 jours utilise une granularité heure par heure
  • T > 31 jours utilise une granularité jour par jour

Les données requises qui ne proviennent pas de données agrégées proviennent de la session brute et des informations de connexion. Ces données ont tendance à croître rapidement, et par conséquent, disposent de leur propre paramètre de nettoyage. Le nettoyage garantit que seules les données appropriées sont conservées à long terme. Cela garantit de meilleures performances tout en conservant la granularité nécessaire pour la création de rapports.

Citrix Virtual Apps and Desktops Service conserve les données historiques pendant 90 jours uniquement. Par conséquent, les tendances et les rapports d’une année dans l’onglet Surveiller montrent les derniers 90 jours de données. Les données de plus de 90 jours sont stockées pendant une période de 2 ans à des fins de sauvegarde et de restauration.

  Nom du paramètre Nettoyage affecté Jours de rétention pour Premium Jours de rétention pour Advanced
1 GroomSessionsRetentionDays Rétention des enregistrements de session et de connexion après la fermeture de session 90 31
2. GroomFailuresRetentionDays Enregistrements MachineFailureLog et ConnectionFailureLog 90 31
3 GroomLoadIndexesRetentionDays Enregistrements LoadIndex 90 31
4 GroomDeletedRetentionDays Les entités Machine, Catalog, DesktopGroup et Hypervisor qui possèdent un LifecycleState « Supprimé ». Cette opération supprime également tout enregistrement Session, SessionDetail, Summary, Failure ou LoadIndex. 90 31
5 GroomSummariesRetentionDays Enregistrements DesktopGroupSummary, FailureLogSummary et LoadIndexSummary. Données agrégées : granularité quotidienne. 90 31
6 GroomMachineHotfixLogRetentionDays Corrections à chaud appliquées aux machines VDA et Controller 90 31
7 GroomHourlyRetentionDays Données agrégées : granularité horaire 32 31
8 GroomApplicationInstanceRetentionDays Historique des instances d’application 90 Sans objet
9 GroomNotificationLogRetentionDays Enregistrements de journal de notification 90 Sans objet
10 GroomResourceUsageRawDataRetentionDays Données d’utilisation des ressources : données brutes 3 3
11 GroomResourceUsageHourDataRetentionDays Données de synthèse d’utilisation des ressources : granularité par heure 30 30
12 GroomResourceUsageDayDataRetentionDays Données de synthèse d’utilisation des ressources : granularité par jour 90 31
13 GroomProcessUsageRawDataRetentionDays Données d’utilisation des processus : données brutes 1 1
14 GroomProcessUsageHourDataRetentionDays Données d’utilisation des processus : granularité par heure 7 7
15 GroomProcessUsageDayDataRetentionDays Données d’utilisation des processus : granularité par jour 30 30
16 GroomSessionMetricsDataRetentionDays Données de mesure de session 1 1
17 GroomMachineMetricDataRetentionDays Données de mesure de machine 3 3
18 GroomMachineMetricDaySummaryDataRetentionDays Données de synthèse de mesure de machine 90 31
19 GroomApplicationErrorsRetentionDays Données d’erreur d’application 1 1
20 GroomApplicationFaultsRetentionDays Données d’échec d’application 1 1

Attention :

Vous ne pouvez pas modifier les valeurs de la base de données Monitoring du service. Pour modifier les paramètres de la base de données, contactez le support Citrix.

La conservation de données pendant de longues périodes a les conséquences suivantes sur la taille des tables :

  • Données horaires. Si les données horaires sont autorisées à rester dans la base de données pour un maximum de deux années, un site de 1 000 groupes de mise à disposition peut influencer la croissance de la base de données comme suit :

    1 000 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é importante de données dans les tables d’agrégation est significatif. Étant donné que les données du tableau de bord sont tirées de cette table, la configuration requise sur le serveur de base de données peut être importante. Il se peut que des quantités excessives de données aient un impact dramatique sur les performances.

  • Données de session et d’événement. Ce sont les données collectées chaque fois qu’une session est démarrée et qu’une connexion/reconnexion est effectuée. Pour un site important (100 000 utilisateurs), ces données s’accroissent très rapidement. Par exemple, l’équivalent de deux ans de tables rassemblerait plus d’un To de données nécessitant une base de données d’entreprise de haut au niveau.