数据粒度与数据保留
数据值的聚合处理
Monitor Service 收集各种数据,包括用户会话使用情况、用户登录性能详细信息、会话负载平衡详细信息以及连接和计算机故障信息。数据根据其类别以不同方式聚合。了解使用 OData 方法 API 呈现的数据值聚合对于解释数据至关重要。例如:
- 连接会话和计算机故障在一段时间内发生。因此,它们以该时间段内的最大值形式公开。
- 登录持续时间是时间长度的度量,因此以该时间段内的平均值形式公开。
- 登录计数和连接故障是该时间段内发生次数的计数,因此以该时间段内的总和形式公开。
并发的数据评估
会话必须重叠才能被视为并发。但是,当时间间隔为 1 分钟时,该分钟内的所有会话(无论是否重叠)都被视为并发。由于间隔太小,计算精度所涉及的性能开销不值得增加的价值。如果会话发生在同一小时内,但不在同一分钟内,则不被视为重叠。
汇总表与原始数据的关联
数据模型以两种不同的方式表示指标:
- 汇总表以每分钟、每小时和每天的时间粒度表示指标的聚合视图。
- 原始数据表示在会话、连接、应用程序和其他对象中跟踪的单个事件或当前状态。
尝试跨 API 调用或在数据模型本身内关联数据时,了解以下概念和限制非常重要:
- 部分间隔无汇总数据。 指标汇总旨在满足长期历史趋势的需求。这些指标会聚合到汇总表中以形成完整的间隔。在数据收集的开始(最旧的可用数据)和结束时,没有部分间隔的汇总数据。当查看一天的聚合(Interval=1440)时,这意味着第一个和最近的不完整天数没有任何数据。尽管原始数据可能存在于这些部分间隔中,但它从不进行汇总。您可以通过从特定汇总表中提取最小和最大 SummaryDate 来确定特定数据粒度的最早和最晚聚合间隔。SummaryDate 列表示间隔的开始。Granularity 列表示聚合数据的间隔长度。
- 按时间关联。 指标会聚合到汇总表中以形成完整的间隔,如上一节所述。它们可用于历史趋势,但原始事件的状态可能比用于趋势分析的汇总数据更具时效性。任何基于时间的汇总数据与原始数据比较都必须考虑到,对于可能发生的部分间隔或时间段的开始和结束,没有汇总数据。
- 丢失和延迟事件。 如果事件丢失或延迟到聚合周期,聚合到汇总表中的指标可能略有不准确。尽管 Monitor Service 尝试维护准确的当前状态,但它不会回溯时间来重新计算汇总表中丢失或延迟事件的聚合。
- 连接高可用性。 在连接高可用性期间,当前连接的汇总数据计数中会出现空白,但会话实例仍将在原始数据中运行。
- 数据保留期。 汇总表中的数据保留计划与原始事件数据的计划不同。数据可能因已从汇总表或原始表中清除而丢失。不同粒度的汇总数据,其保留期也可能不同。较低粒度的数据(分钟)比较高粒度的数据(天)清除得更快。如果某个粒度的数据因清除而丢失,则可能在更高粒度中找到。由于 API 调用仅返回请求的特定粒度,因此某个粒度未收到数据并不意味着同一时间段内更高粒度的数据不存在。
- 时区。 指标使用 UTC 时间戳存储。汇总表按小时时区边界进行聚合。对于不属于小时边界的时区,数据聚合的位置可能存在一些差异。
数据粒度与保留
Director 检索的聚合数据的粒度是所请求的时间 (T) 跨度的函数。规则如下:
- 0 < T <= 1 小时 - 使用每分钟粒度
- 0 < T <= 30 天 - 使用每小时粒度
- T > 31 天 - 使用每日粒度
未来自聚合数据的请求数据来自原始会话和连接信息。此数据往往增长迅速,因此有其自己的清除设置。清除可确保仅保留相关数据以供长期使用。清除可确保更好的性能,同时保持报告所需的粒度。拥有 Premium 许可证站点的客户可以将其清除保留期更改为所需的保留天数,否则将使用默认值。如果与站点数据库失去连接,Monitor Service 将使用下表中指定的 Premium 授权的默认保留天数。
要访问这些设置,请在 交付控制器™ 上运行以下 PowerShell 命令:
asnp Citrix.*
Get-MonitorConfiguration
Set-MonitorConfiguration -<setting name> <value>
<!--NeedCopy-->
| 设置名称 | 受影响的清除 | Premium 的保留天数 | 高级版保留天数 | ||
|---|---|---|---|---|---|
| 1 | 会话清理保留天数 | 会话和连接记录在会话终止后的保留期限 | 90 | 31 | |
| 2 | 故障清理保留天数 | 机器故障日志和连接故障日志记录 | 90 | 31 | |
| 3 | 负载索引清理保留天数 | 负载索引记录 | 90 | 31 | |
| 4 | 清理已删除记录的保留天数 | 具有 LifecycleState 为“Deleted”的机器、目录、桌面组和虚拟机管理程序实体。此设置还会删除任何相关的会话、会话详细信息、摘要、故障或负载指数记录。 | 90 | 31 | |
| 5 | 摘要清理保留天数 | 桌面组摘要、故障日志摘要和负载指数摘要记录。聚合数据 - 每日粒度。 | 365 | 31 | |
| 6 | 机器热修复日志清理保留天数 | 应用于 VDA 和 Controller 计算机的热修复程序 | 90 | 31 | |
| 7 | 清理分钟保留天数 | 聚合数据 - 分钟粒度 | 3 | 3 | |
| 8 | 清理小时保留天数 | 聚合数据 - 小时粒度 | 32 | 31 | |
| 9 | 清理应用程序实例保留天数 | 应用程序实例历史记录 | 90 | 不适用。 | |
| 10 | 清理通知日志保留天数 | 通知日志记录 | 90 | 不适用此项 | |
| 11 | GroomResourceUsageRawDataRetentionDays | 资源利用率数据 - 原始数据 | 3 | 3 | |
| 12 | 清理资源使用分钟数据保留天数 | 资源利用率汇总数据 - 分钟粒度 | 7 | 7 | |
| 13 | 资源使用小时数据清理保留天数 | 资源利用率汇总数据 - 小时粒度 | 30 | 30 | |
| 14 | 资源使用日数据清理保留天数 | 资源利用率汇总数据 - 天粒度 | 365 | 31 | |
| 15 | 进程使用原始数据清理保留天数 | 进程利用率数据 - 原始数据 | 1 | 1 | |
| 16 | 清理进程使用分钟数据保留天数 | 进程利用率数据 - 分钟粒度 | 3 | 3 | |
| 17 | 清理进程使用小时数据保留天数 | 进程利用率数据 - 小时粒度 | 7 | 7 | |
| 18 | 清理进程使用日数据保留天数 | 进程利用率数据 - 天粒度 | 30 | 30 | |
| 19 | 清理会话指标数据保留天数 | 会话指标数据 | 1 | 1 | |
| 20 | 清理计算机指标数据保留天数 | 计算机指标数据 | 3 | 3 | |
| 21 | 清理计算机指标日汇总数据保留天数 | 计算机指标摘要数据 | 365 | 31 | |
| 22 | 清理应用程序错误保留天数 | 应用程序错误数据 | 1 | 1 | |
| 23 | 清理应用程序故障保留天数 | 应用程序故障数据 | 1 | 1 | |
注意:
修改 Monitor Service 数据库上的值需要重新启动服务才能使新值生效。建议您仅在 Citrix 支持部门的指导下对 Monitor Service 数据库进行更改。
清理进程使用原始数据保留天数、清理资源使用原始数据保留天数和清理会话指标数据保留天数这几项设置的默认值限制为 1,而清理进程使用分钟数据保留天数的默认值限制为 3。用于设置这些值的 PowerShell 命令已被禁用,因为进程使用数据往往会快速增长。 此外,基于许可证的保留设置如下:
- 高级许可站点 - 所有设置的清理保留期限制为 1000 天(Citrix 建议 365 天)。
- 高级许可站点 - 所有设置的清理保留期限制为 31 天。
- 所有其他站点 - 所有设置的清理保留期限制为 7 天。
例外情况:
- 清理应用程序实例保留天数 只能在高级许可站点中设置。
- 应用程序错误保留天数和应用程序故障保留天数在高级许可站点中限制为 31 天。
长期保留数据将对表格的存储大小产生以下影响:
-
每小时数据。 如果允许每小时数据在数据库中保留长达两年,一个拥有 1000 个交付组的站点可能导致数据库按如下方式增长:
1000 个交付组 x 24 小时/天 x 365 天/年 x 2 年 = 17,520,000 行数据。聚合表中如此大量的数据对性能的影响是巨大的。鉴于仪表板数据是从此表中提取的,对数据库服务器的要求可能很高。过多的数据量可能会对性能产生显著影响。
-
会话和事件数据。 每次会话启动和建立连接/重新连接时收集的数据。对于大型站点(10 万用户),这些数据增长迅速。例如,这些表两年内将收集超过 1 TB 的数据,需要高端企业级数据库。