Granularité et rétention des données

Agrégation des valeurs de données

Le service Monitor collecte diverses données, notamment l’utilisation des sessions utilisateur, les détails des performances d’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 pannes 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, par conséquent, elle est 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 donnée, par conséquent, ils sont 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 tables récapitulatives avec les données brutes

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

• Les tables récapitulatives représentent des vues agrégées des métriques avec des granularités de temps par minute, heure et jour.
• Les données brutes représentent des événements individuels ou l’état actuel suivi 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 :

• Pas de données récapitulatives 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 la table récapitulative pour les intervalles complets. Il n’y a 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 et les plus récents jours incomplets n’ont aucune donnée. Bien que des données brutes puissent exister pour ces intervalles partiels, elles ne sont 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’une table récapitulative particulière. 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 la table récapitulative pour des intervalles complets, comme décrit dans la section précédente. Elles peuvent être utilisées pour les tendances historiques, mais les événements bruts peuvent être plus à jour 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 tenir compte du fait qu’il n’y a pas de données récapitulatives pour les 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 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 décomptes 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 purge différent de celui des données d’événements brutes. Des données peuvent être manquantes parce qu’elles ont été purgé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 à granularité inférieure (minutes) sont purgées plus rapidement que les données à granularité supérieure (jours). Si des données sont manquantes pour une granularité en raison de la purge, elles peuvent être trouvées à 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 horaires de fuseaux horaires. Pour les fuseaux horaires qui ne tombent pas sur des limites horaires, il peut y avoir des écarts 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 purge. La purge garantit que seules les données pertinentes sont conservées à long terme. La purge assure de meilleures performances tout en maintenant la granularité requise pour les rapports. Les clients des sites sous licence Premium peuvent modifier la rétention de la purge selon le nombre de jours de rétention souhaité, sinon la valeur par défaut est utilisée. En cas de perte de connectivité avec la base de données du site, le service de surveillance utilisera les jours de rétention par défaut pour le droit Premium, comme spécifié 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 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é d’apporter des modifications à la base de données du service Monitor uniquement sous la direction du Support 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 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 - la période de rétention de l’élagage pour tous les paramètres est limitée à 1000 jours (Citrix recommande 365 jours).
• Sites sous licence Advanced - la période de rétention de l’élagage pour tous les paramètres est limitée à 31 jours.
• Tous les autres sites - la période de rétention de l’élagage 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 a 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 deux ans maximum, un site de 1000 groupes de mise à disposition peut 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 tirées 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 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 établie. Pour un site important (100 000 utilisateurs), ces données augmentent 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.