数据粒度和保留

数据值的聚合

Monitor Service收集各种数据，包括用户会话使用情况、用户登录性能详细信息、会话负载平衡详细信息以及连接和机器故障信息。根据数据的类别，数据的汇总方式不同。理解使用OData方法api表示的数据值的聚合对于解释数据至关重要。例如:

• 连接会话和机器故障在一段时间内发生。因此，它们在一段时间内被暴露为最大值。
• 登录持续时间是对时间长度的度量，因此显示为一段时间内的平均值。
• 登录次数和连接失败次数是一段时间内发生的次数，因此显示为一段时间内的总和。

并发数据评估

您的会话必须重叠才能被认为是并发的。但是，当时间间隔为1分钟时，该分钟内的所有会话(无论它们是否重叠)都被认为是并发的。间隔的大小非常小，以至于计算精度所涉及的性能开销与所增加的价值不相称。如果会议在同一小时内举行，但不是在同一分钟内举行，则不视为重叠。

汇总表与原始数据的相关性

数据模型以两种不同的方式表示指标:

• 汇总表以每分钟、每小时和每天的时间粒度表示度量标准的聚合视图。
• 原始数据表示会话、连接、应用程序和其他对象中跟踪的单个事件或当前状态。

当尝试跨API调用或数据模型本身关联数据时，理解以下概念和限制是很重要的:

• 部分间隔没有汇总数据。设计度量摘要是为了满足长期历史趋势的需要。这些指标被聚合到完整时间间隔的汇总表中。在数据收集的开始和结束处都没有部分间隔的汇总数据(最旧的可用数据)。当查看一天(Interval=1440)的聚合时，这意味着第一个和最近的不完整日期没有数据。尽管可能存在这些部分间隔的原始数据，但它永远不会汇总。从特定汇总表中提取最小和最大SummaryDate，以确定特定数据粒度的最早和最晚聚合间隔。SummaryDate列表示间隔的开始。粒度列表示聚合数据的间隔长度。
• 与时间相关。如上一节所述，度量指标被聚合到完整时间间隔的汇总表中。它们可以用于历史趋势，但是原始事件可能比为趋势分析而总结的事件更符合当前状态。任何基于时间的汇总数据与原始数据的比较都必须考虑到，对于可能出现的部分间隔或时间段的开始和结束，都没有汇总数据。
• 错过的和潜在的事件。如果事件被遗漏或隐藏在聚合周期中，聚合到汇总表中的指标可能会稍微不准确。尽管Monitor Service试图保持准确的当前状态，但它不会及时返回到汇总表中重新计算错过或潜在事件的聚合。
• 连接高可用性。在连接HA期间，当前连接的汇总数据计数存在差距，但会话实例仍在原始数据中运行。
• 数据保留周期。汇总表中的数据保留在不同于原始事件数据调度的梳理调度上。数据可能会丢失，因为它已经从摘要或原始表中剔除。保留期限也可能因汇总数据粒度的不同而不同。低粒度数据(分钟)比高粒度数据(天)的整理速度更快。如果由于梳理而丢失了某个粒度的数据，可能会在更高粒度中找到它。由于API调用只返回所请求的特定粒度，因此没有接收到某个粒度的数据并不意味着同一时间段内更高粒度的数据不存在。
• 时区。度量是用UTC时间戳存储的。汇总表按小时时区边界聚合。对于不属于小时边界的时区，在汇总数据的位置上可能存在一些差异。

粒度和留存率

Monitor检索的聚合数据的粒度是请求的时间跨度(T)的函数。规则如下:

• 0 < T <= 30天使用每小时粒度
• T > 31天使用按天粒度

请求的数据不是来自聚合数据，而是来自原始会话和连接信息。这些数据往往增长迅速，因此有自己的梳理设置。梳理确保只有相关的数据被长期保存。这确保了更好的性能，同时保持了报告所需的粒度。

警告:

不能修改Monitor Service数据库上的值。

长时间保留数据对表大小有以下影响:

• 每小时的数据。如果每小时的数据允许在数据库中保留两年，那么一个有1000个交付组的站点可能会导致数据库按照如下方式增长:

  1000个交付组× 24小时/天× 365天/年× 2年= 1752万行数据。聚合表中如此大量的数据对性能的影响是显著的。假设仪表板数据是从这个表中提取的，那么对数据库服务器的需求可能很大。过多的数据量会对性能产生巨大影响。

• 会话和事件数据。这是每次会话启动和连接/重新连接时收集的数据。对于大型站点(10万用户)，这些数据增长很快。例如，两年的这些表将收集超过1tb的数据，需要一个高端的企业级数据库。