数据粒度和保留
数据值聚合
Monitor Service 收集各种数据,其中包括用户会话使用情况、用户登录性能详细信息、会话负载平衡详细信息,以及连接和计算机故障信息。根据其类别,数据以不同的方式聚合。了解使用 OData Method API 提供的数据值的聚合是解释数据的关键。例如:
- 一段时间内发生的连接的会话故障和计算机故障。因此它们显示为一段时间内的最大值。
- 登录持续时间是时间长度的度量,因此它们显示为一段时间内的平均值。
- 登录计数和连接失败次数是一段时间内这类事件的计数,因此它们显示为一段时间内的总数。
并发数据评估
您的会话必须重叠才能视为并发。但是,当时间间隔为 1 分钟时,该分钟内的所有会话(无论它们是否重叠)都被视为并发。时间间隔的大小非常小,以致计算精度所涉及的性能开销不值得增加。如果会话发生在同一小时,但不同分钟内,则不会被视为重叠。
关联汇总表和原始数据
数据模型以两种不同方式表示指标:
- 汇总表以每分钟、每小时和每天的时间粒度表示指标的聚合视图。
- 原始数据表示单个事件或在会话、连接、应用程序或其他对象中跟踪到的当前状态。
尝试跨 API 调用或在数据模型自身内部关联数据时,必须理解以下概念和限制:
- 不存在部分时间间隔的汇总数据。指标汇总是为了洞察长时间内的历史趋势。这些指标应该聚合到完整时间间隔的汇总表中。不存在仅包含数据收集的开始时间(最早的可用数据)而不包含结束时间的部分时间间隔的汇总数据。这意味着,当查看一天(时间间隔=1440)的聚合时,最早和最近的不完整日期不包含数据。尽管存在这些部分时间间隔的原始数据,但绝不会汇总这些原始数据。对于特定的数据粒度,请从特定汇总表中提取最小和最大的 SummaryDate,以确定最早和最新的聚合时间间隔。SummaryDate 列表示时间间隔的开始时间。Granularity 列表示聚合数据的时间间隔长度。
- 按时间关联。如上一部分内容中所述,指标聚合到完整时间间隔的汇总表中。它们可以用于了解历史趋势,但是原始事件的状态可能更新,不能通过汇总进行趋势分析。基于时间比较汇总数据和原始数据时,必须注意不存在可能发生的任何部分时间间隔或时间段的开头和结尾部分的汇总数据。
- 缺失的事件和延迟事件。如果在聚合时间段有事件缺失或延迟,聚合到汇总表中的指标可能会略有误差。尽管 Monitor Service 尝试维护准确的最新状态,但是它不会针对缺失或延迟的事件后退到过去重新计算汇总表中的聚合值。
- 连接高可用性。在连接高可用性期间,当前连接的汇总数据计数存在误差,但是会话实例仍在原始数据中运行。
- 数据保留期限。汇总表中的数据保留整理计划不同于原始事件数据的计划。由于数据已从汇总表或原始表格加以整理,因此可能会有所缺失。不同粒度的汇总数据的保留期限可能也有所差异。粒度较低的数据(分钟)的整理速度高于粒度较高的数据(天)。如果由于整理导致数据在某个粒度缺失,可以在更高的粒度找到此数据。由于 API 调用仅返回所请求的特定粒度,未接收到某个粒度的数据并不表示在同一时间段内不存在更高粒度的数据。
- 时区。指标采用 UTC 时间戳存储。汇总表按照小时时区边界聚合。对于没有位于小时边界上的时区,数据聚合的时间可能会有所差异。
粒度和保留
监视器检索的聚合数据粒度是所请求的时间 (T) 跨度的函数。规则如下:
- 0 < T <= 30 天采用每小时粒度
- T > 31 天采用每天粒度
非来源于聚合数据的请求数据来源于原始会话和连接信息。此数据往往增长很快,因此具有自己的整理设置。通过整理可确保仅长期保留相关数据。这样可以确保实现更好的性能,同时维护报告所需的粒度。
设置名称 | 受影响的整理 | Premium 的保留天数 | Advanced 的保留天数 | ||
---|---|---|---|---|---|
1 | GroomSessionsRetentionDays | 会话终止后的会话和连接记录保留期限 | 90 | 31 | |
2 | GroomFailuresRetentionDays | MachineFailureLog 和 ConnectionFailureLog 记录 | 90 | 31 | |
3 | GroomLoadIndexesRetentionDays | LoadIndex 记录 | 3 | 3 | |
4 | GroomDeletedRetentionDays | LifecycleState 为“Deleted”的 Machine、Catalog、DesktopGroup 和 Hypervisor 实体。这还将删除任何相关的 Session、SessionDetail、Summary、Failure 或 LoadIndex 记录。 | 90 | 31 | |
5 | GroomSummariesRetentionDays | DesktopGroupSummary、FailureLogSummary 和 LoadIndexSummary 记录。聚合数据 - 日粒度。 | 365 | 31 | |
6 | GroomMachineHotfixLogRetentionDays | 应用至 VDA 和 Controller 计算机的修补程序 | 90 | 31 | |
7 | GroomHourlyRetentionDays | 聚合数据 - 小时粒度 | 32 | 31 | |
8 | GroomApplicationInstanceRetentionDays | 应用程序实例历史记录 | 90 | 不适用 | |
9 | GroomNotificationLogRetentionDays | 通知日志记录 | 90 | 不适用 | |
10 | GroomResourceUsageRawDataRetentionDays | 资源利用率数据 - 原始数据 | 3 | 3 | |
11 | GroomResourceUsageHourDataRetentionDays | 资源利用率汇总数据 - 小时粒度 | 30 | 30 | |
12 | GroomResourceUsageDayDataRetentionDays | 资源利用率汇总数据 - 天粒度 | 365 | 31 | |
13 | GroomProcessUsageRawDataRetentionDays | 进程利用率数据 - 原始数据 | 1 | 1 | |
14 | GroomProcessUsageHourDataRetentionDays | 进程利用率数据 - 小时粒度 | 7 | 7 | |
15 | GroomProcessUsageDayDataRetentionDays | 进程利用率数据 - 天粒度 | 30 | 30 | |
16 | GroomSessionMetricsDataRetentionDays | 会话指标数据 | 1 | 1 | |
17 | GroomMachineMetricDataRetentionDays | 计算机指标数据 | 3 | 3 | |
18 | GroomMachineMetricDaySummaryDataRetentionDays | 计算机指标汇总数据 | 365 | 31 | |
19 | GroomApplicationErrorsRetentionDays | 应用程序错误数据 | 1 | 1 | |
20 | GroomApplicationFaultsRetentionDays | 应用程序故障数据 | 1 | 1 |
小心:
您无法修改 Monitor Service 数据库中的值。
长期保留数据会对表格大小产生以下影响:
-
小时数据。如果允许小时粒度的数据在数据库中最多保留两年,具有 1000 个交付组的站点将导致数据库按以下方式增长:
1000 个交付组 x 24 小时/天 x 365 天/年 x 2 年 = 17,520,000 行数据。聚合表中存在如此巨大的数据量对性能的影响是非常显著的。如果从此表格提取控制板数据,将需要使用大型数据库服务器。数据量过大会对性能造成巨大影响。
-
会话和事件数据。这是指每次启动会话和建立连接/重新连接时收集的数据。对于大型站点(10 万个用户),此数据的增长速度很快。例如,经过两年时间,这些表格中收集的数据将超过 1 TB,这将要求使用企业级高端数据库。