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.
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 | 3 | 3 | |
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. | 365 | 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 | Non applicable | |
9 | GroomNotificationLogRetentionDays | Enregistrements de journal de notification | 90 | Non applicable | |
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 | 365 | 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 | 365 | 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.
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.