数据粒度和保留
数据值的聚合
Monitor Service收集各种数据,包括用户会话使用情况、用户登录性能详细信息、会话负载均衡详细信息以及连接和机器故障信息。根据数据类别的不同,数据的聚合方式也不同。理解使用OData Method api表示的数据值的聚合对于解释数据至关重要。例如:
- 连接会话和机器故障在一段时间内发生。因此,它们暴露为一段时间内的最大值。
- 登录持续时间是时间长度的度量,因此暴露为一个时间段的平均值。
- 登录计数和连接失败是一段时间内发生的计数,因此公开为一段时间内的总和。
并发数据评估
会话必须重叠才能被认为是并发的。但是,当时间间隔为1分钟时,该分钟内的所有会话(无论它们是否重叠)都被认为是并发的。间隔的大小是如此之小,以至于计算精度所涉及的性能开销不值得增加的价值。如果各届会议在同一小时内举行,但不在同一分钟内举行,则不认为它们重叠。
汇总表与原始数据的相关性
数据模型以两种不同的方式表示度量:
- 汇总表表示以分钟、小时和日时间粒度为单位的指标的聚合视图。
- 原始数据表示会话、连接、应用程序和其他对象中跟踪的个别事件或当前状态。
当尝试跨API调用或在数据模型本身内关联数据时,了解以下概念和限制是很重要的:
- 没有部分区间的汇总数据。度量摘要的设计是为了满足长期历史趋势的需求。这些指标被聚合到汇总表中以获取完整的时间间隔。在数据集合的开始(最古老的可用数据)和结束处都没有部分区间的汇总数据。在查看一天的聚合(Interval=1440)时,这意味着第一个和最近的不完整天没有任何数据。尽管可能存在这些部分区间的原始数据,但从未对其进行汇总。通过从特定汇总表提取最小和最大SummaryDate,可以确定特定数据粒度的最早和最新聚合间隔。SummaryDate列表示时间间隔的开始。粒度列表示聚合数据间隔的长度。
- 相关时间。如上一节所述,指标被聚合到完整间隔的汇总表中。它们可以用于历史趋势,但原始事件可能比用于趋势分析的内容更接近当前状态。任何基于时间的汇总数据与原始数据的比较都必须考虑到,对于可能发生的部分间隔或时间段的开始和结束没有汇总数据。
- 遗漏的和潜在的事件。如果在聚合期间漏掉或隐藏事件,则聚合到汇总表中的度量可能略显不准确。尽管Monitor Service试图维护准确的当前状态,但它不会及时返回,在汇总表中重新计算错过或潜在事件的聚合。
- 连接的高可用性。在连接高可用性期间,当前连接的汇总数据计数将出现空白,但会话实例仍将在原始数据中运行。
- 数据保留时间。汇总表中的数据保留在与原始事件数据调度不同的梳理调度上。数据可能会丢失,因为已经从汇总表或原始表中去除了数据。对于汇总数据粒度的不同,保留期也可能不同。低粒度数据(分钟)比高粒度数据(天)处理得更快。如果某个粒度的数据由于梳理而丢失,则可能在更高粒度的数据中找到它。由于API调用只返回所请求的特定粒度,因此没有接收某个粒度的数据并不意味着同一时间段内不存在用于更高粒度的数据。
- 时区。度量标准使用UTC时间戳存储。汇总表按小时时区边界聚合。对于不以小时为界限的时区,在聚合数据的地方可能会有一些差异。
粒度和保留
Director检索到的聚合数据的粒度是请求的时间(T)跨度的函数。规则如下:
- 0 < T <= 1小时-使用每分钟粒度
- 0 < T <= 30天-使用每小时粒度
- T > 31天-使用每天粒度
不来自聚合数据的请求数据来自原始的会话和连接信息。这些数据往往增长很快,因此有自己的梳理设置。梳理确保只有相关的数据被长期保存。梳理可以确保更好的性能,同时保持报告所需的粒度。在高级授权网站上的客户可以将美容保留天数更改为他们想要的保留天数,否则使用默认值。如果与站点数据库的连接性丢失,Monitor Service将使用下表中指定的Premium授权的默认保留天数。
在Delivery Controller上执行以下PowerShell命令可以访问设置:
asnp Citrix。*Get-MonitorConfiguration Set-MonitorConfiguration -
设置名称 | 影响美容 | 默认值溢价(天) | 默认值non-Premium(天) | |
---|---|---|---|---|
1 | GroomSessionsRetentionDays | 会话和连接记录在会话终止后保留 | 90 | 7 |
2 | GroomFailuresRetentionDays | 记录MachineFailureLog和ConnectionFailureLog日志 | 90 | 7 |
3. | GroomLoadIndexesRetentionDays | LoadIndex记录 | 90 | 7 |
4 | GroomDeletedRetentionDays | 生命周期状态为“已删除”的机器、目录、桌面组和Hypervisor实体。此设置还删除任何相关的Session、SessionDetail、Summary、Failure或LoadIndex记录。 | 90 | 7 |
5 | GroomSummariesRetentionDays | DesktopGroupSummary、FailureLogSummary和LoadIndexSummary记录。聚合数据—每日粒度。 | 90 | 7 |
6 | GroomMachineHotfixLogRetentionDays | 应用于VDA和Controller机器的修复程序 | 90 | 90 |
7 | GroomMinuteRetentionDays | 聚合数据-分钟粒度 | 3. | 3. |
8 | GroomHourlyRetentionDays | 聚合数据-每小时粒度 | 32 | 7 |
9 | GroomApplicationInstanceRetentionDays | 应用程序实例的历史 | 90 | 0 |
10 | GroomNotificationLogRetentionDays | 通知日志记录 | 90 | |
11 | GroomResourceUsageRawDataRetentionDays | 资源利用数据——原始数据 | 1 | 1 |
12 | GroomResourceUsageMinuteDataRetentionDays | 资源利用率汇总数据分钟粒度 | 7 | 7 |
13 | GroomResourceUsageHourDataRetentionDays | 资源利用率汇总数据小时粒度 | 30. | 7 |
14 | GroomResourceUsageDayDataRetentionDays | 资源利用率汇总数据-日粒度 | 90 | 7 |
15 | GroomProcessUsageRawDataRetentionDays | 过程利用率数据——原始数据 | 1 | 1 |
16 | GroomProcessUsageMinuteDataRetentionDays | 流程利用率数据分粒度 | 3. | 3. |
17 | GroomProcessUsageHourDataRetentionDays | 流程利用率数据小时粒度 | 7 | 7 |
18 | GroomProcessUsageDayDataRetentionDays | 流程利用率数据天粒度 | 30. | 7 |
19 | GroomSessionMetricsDataRetentionDays | 会话的度量数据 | 1 | 1 |
20. | GroomMachineMetricDataRetentionDays | 机指标数据 | 3. | 3. |
21 | GroomMachineMetricDaySummaryDataRetentionDays | 机器指标汇总数据 | 90 | 7 |
22 | GroomApplicationErrorsRetentionDays | 应用程序错误数据 | 1 | 1 |
23 | GroomApplicationFaultsRetentionDays | 应用程序故障数据 | 1 | 1 |
警告:
修改Monitor Service数据库上的值需要重新启动服务,新值才能生效。建议您仅在Citrix Support的指导下对Monitor Service数据库进行更改。
GroomProcessUsageRawDataRetentionDays、GroomResourceUsageRawDataRetentionDays和GroomSessionMetricsDataRetentionDays的设置被限制为默认值1,而GroomProcessUsageMinuteDataRetentionDays的设置被限制为默认值3。用于设置这些值的PowerShell命令已被禁用,因为进程使用数据趋向于快速增长。此外,基于许可证的保留设置如下:
- 〇优质持牌网站所有设置的美容保留时间都限制在1000天(思杰推荐365天)。
- 先进的持牌网站所有设置的美容保留期限制在31天。
- 所有其他网站-所有设置的美容保留期限制为7天。
例外:
- GroomApplicationInstanceRetentionDays只能在高级授权网站中设置。
- GroomApplicationErrorsRetentionDays和GroomApplicationFaultsRetentionDays在高级授权网站中限制为31天。
长时间保留数据对表大小的影响如下:
每小时的数据。如果允许每小时的数据在数据库中保留两年,那么一个有1000个交付组的站点可以使数据库增长如下:
1000个交付组x 24小时/天x 365天/年x 2年= 1752万行数据。聚合表中如此大量的数据对性能的影响非常大。由于仪表板数据是从这个表中提取的,因此对数据库服务器的需求可能很大。过大的数据量可能会对性能产生巨大的影响。
会话和事件数据。每次会话启动和连接/重连接时收集的数据。对于大型站点(100 K用户),此数据增长很快。例如,两年的这些表将收集超过1tb的数据,这需要一个高端企业级数据库。