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 de connexion utilisateur, les détails de l’équilibrage de charge des sessions et les informations sur les défaillances 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. Par conséquent, elles sont exposées sous forme de maximums sur une période.
- La durée de connexion est une mesure de la longueur du temps, elle est donc exposée sous forme de moyenne sur une période.
- Le nombre de connexions et les défaillances de connexion sont des comptes d’occurrences sur une période, par conséquent, ils sont exposés sous forme de sommes sur une période.
Évaluation des données concurrentes
Vos 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 charge 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 temporelles par minute, heure et jour.
-
Les données brutes représentent des événements individuels ou l’état actuel suivis dans les objets de session, de connexion, d’application et autres.
-
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écapitulatifs des 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 jours incomplets les plus anciens et les plus récents n’ont pas de données. Bien que des données brutes puissent exister pour ces intervalles partiels, elles ne sont jamais résumées. Extrayez les dates SummaryDate minimale et maximale d’une table récapitulative particulière pour déterminer l’intervalle agrégé le plus ancien et le plus récent pour une granularité de données 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 les 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 récents que ce qui a été résumé pour l’analyse des tendances. Toute comparaison basée sur le temps entre les données récapitulatives et les données brutes doit prendre en compte 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 la table récapitulative 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 Monitor tente de maintenir un état actuel précis, il ne revient pas en arrière pour recalculer l’agrégation dans les tables récapitulatives pour les événements manqués ou latents.
- Haute disponibilité des connexions. Pendant la HA de connexion, il y a des lacunes dans les décomptes de données récapitulatives des connexions actuelles, 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 récapitulatives sont conservées selon un calendrier de nettoyage différent de celui des données d’événements bruts. Des données peuvent manquer parce qu’elles ont été nettoyées des tables récapitulatives ou brutes. 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 manquent d’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 tables récapitulatives sont agrégées sur les limites horaires des fuseaux horaires. Pour les fuseaux horaires qui ne tombent pas sur des limites horaires, il peut y avoir un certain écart 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 Monitor dépend de la période (T) demandée. Les règles sont les suivantes :
- 0 < T <= 30 jours : utiliser une granularité horaire
- T > 31 jours : utiliser une granularité journalière
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 disposent donc de leur propre paramètre d’élagage. L’élagage 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.
| # | Nom du paramètre | Table de schéma impactée | Tables et graphiques impactés dans les pages Monitor | Jours de rétention pour Premium | Jours de rétention pour Advanced |
|---|---|---|---|---|---|
| 1 | GroomSessionsRetentionDays | Tables MonitorData.Session et Monitordata.Connection | Ce paramètre impacte les détails de session, la durée d’ouverture de session par session utilisateur, les tables d’utilisation basées sur les applications sur la page Tendances. | 90 | 31 |
| 2 | GroomFailuresRetentionDays | MonitorData.MachineFailureLog et MonitorData.ConnectionFailureLog | Page Tendances : Ce paramètre impacte les graphiques et les tables de l’onglet défaillances. | 90 | 31 |
| 3 | GroomLoadIndexesRetentionDays | MonitorData.LoadIndex | Ce paramètre impacte les données affichées dans l’onglet “Index d’évaluation de charge” sur la page Tendances. | 3 | 3 |
| 4 | GroomDeletedRetentionDays | Entités MonitorData.Machine, MonitorData.Catalog, MonitorData.DesktopGroup et MonitorData.Hypervisor dont le LifecycleState est « Deleted ». Ce paramètre supprime également tous les enregistrements de session, de détail de session, de résumé, de défaillance ou d’index de charge associés. | Entités Machine, Catalog, DesktopGroup et Hypervisor dont le LifecycleState est « Deleted ». Ce paramètre supprime également tous les enregistrements de session, de détail de session, de résumé, de défaillance ou d’index de charge associés. | 90 | 31 |
| 5 | GroomSummariesRetentionDays | MonitorData.DesktopGroupSummary, MonitorData.FailureLogSummary et MonitorData.LoadIndexSummary | Ce paramètre impacte toutes les données graphiques de la page Tendances. | 365 | 31 |
| 6 | GroomMachineHotfixLogRetentionDays | MonitorData.Hotfix | Ce paramètre impacte les données de correctif VDA affichées sur la page Détails de la machine. | 90 | 31 |
| 7 | GroomHourlyRetentionDays | toutes les tables de résumé | Cela impacte les graphiques hebdomadaires affichés sur la page Tendances. | 32 | 31 |
| 8 | GroomApplicationInstanceRetentionDays | MonitorData.ApplicationInstance | Ce paramètre impacte le graphique et les tables de l’onglet Gestion de la capacité et les tables d’utilisation des applications sur la page Tendances. | 90 | Non applicable |
| 9 | GroomNotificationLogRetentionDays | MonitorData.NotificationLog | Ce paramètre impacte les alertes affichées sur Monitor. | 90 | Non applicable |
-
10 GroomResourceUsageRawDataRetentionDays MonitorData.Resourceutilization Ce paramètre impacte les graphiques CPU et Mémoire affichés dans la page Détails de la machine “Utilisation historique de la machine” et le calcul des données dans la zone d’optimisation des coûts “onglet Dimensionnement de la charge de travail”. 3 3 11 GroomResourceUsageHourDataRetentionDays MonitorData.Resourceutilizationsummary Ce paramètre impacte les graphiques CPU et Mémoire affichés dans la page Détails de la machine “Utilisation historique de la machine” et le calcul des données dans la zone d’optimisation des coûts “onglet Dimensionnement de la charge de travail”. 30 30 -
12 GroomResourceUsageDayDataRetentionDays MonitorData.Resourceutilizationsummary Ce paramètre impacte le graphique CPU et Mémoire affiché sur la page “Utilisation des ressources” de la machine sur la page Tendances et la page “Utilisation de la machine” pour une machine spécifique. 365 31 13 GroomProcessUsageRawDataRetentionDays MonitorData.ProcessUtilization Ce paramètre impacte les informations de tendance des ressources par processus affichées sur la page d’utilisation historique de la machine. 1 1 14 GroomProcessUsageHourDataRetentionDays MonitorData.ProcessUtilizationHourSummary Ce paramètre impacte la tendance d’utilisation du CPU et de la mémoire par processus affichée sur la page d’utilisation historique de la machine. 7 7 15 GroomProcessUsageDayDataRetentionDays MonitorData.ProcessUtilizationDaySummary Ce paramètre impacte la tendance d’utilisation du CPU et de la mémoire par processus affichée sur la page d’utilisation historique de la machine. 30 30 16 GroomSessionMetricsDataRetentionDays MonitorData.Sessionmetrics Ce paramètre impacte tous les graphiques affichés dans l’onglet “Performances de session” de la page de détails de l’utilisateur. 1 1 17 GroomMachineMetricDataRetentionDays MonitorData.Machinemetrics Ce paramètre impacte le graphique et la table de l’onglet “Utilisation des ressources” sur la page Tendances. 3 3 18 GroomMachineMetricDaySummaryDataRetentionDays MonitorData.MachineMetricDaySummary Ce paramètre impacte le graphique et la table de l’onglet “Utilisation des ressources” sur la page Tendances. 365 31 19 GroomApplicationErrorsRetentionDays MonitorData.ApplicationError Ce paramètre impacte les détails d’erreur affichés dans la colonne “Erreurs d’application” sur la page Applications. 1 1 20 GroomApplicationFaultsRetentionDays MonitorData.Applicationfailure Ce paramètre impacte la colonne “Défaillances d’application” sur la page Applications. 1 1
Attention :
Vous ne pouvez pas modifier les valeurs dans la base de données du service Monitor.
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 extraites de cette table, les exigences en matière de 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 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.