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. Vous pouvez déterminer le premier et le dernier intervalle d’agrégation pour une granularité de données particulière en extrayant les valeurs minimales et maximales de SummaryDate pour une table de synthèse 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 d’un résumé aux données brutes doit tenir compte du fait qu’il n’existe pas de données récapitulatives pour des intervalles partiels qui pourraient se produire ou pour le début et la fin de la période.
• É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 existera des espaces dans les données de synthèse du nombre de connexions actives, mais les instances de session seront 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 Director est une fonction de la période de temps (T) demandée. Les règles sont les suivantes :

• 0 < T <= 1 heure - utilise une granularité minute par minute
• 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. Le nettoyage garantit de meilleures performances tout en conservant la granularité nécessaire pour la création de rapports. Les clients sur sites avec licence Premium peuvent modifier la rétention de nettoyage sur leur nombre de jours de rétention désirés, sinon, la valeur par défaut est utilisée. En cas de perte de connectivité avec la base de données du site, Monitor Service utilisera les jours de rétention par défaut pour les droits Premium, comme indiqué dans le tableau ci-dessous.

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-->

Attention :

La modification des valeurs de la base de données de Monitor Service nécessite le redémarrage du service pour que les nouvelles valeurs prennent effet. Vous êtes invités à apporter des modifications à la base de données de Monitor Service uniquement avec l’assistance de Citrix.

Les paramètres 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 du processus ont tendance à croître rapidement. En outre, les paramètres de rétention basés sur les licences sont les suivants :

• Sites sous licence Premium : la rétention de nettoyage pour tous les paramètres est limitée à 1000 jours (Citrix recommande 365 jours).
• Sites sous licence Advanced : la rétention de nettoyage est limitée à 31 jours pour tous les paramètres.
• Tous les autres sites : la rétention de nettoyage est limitée à 7 jours pour tous les paramètres.

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 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. 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.