我知道有每小时的数据可用，但要求是这样的，我需要了解其背后的逻辑并在前端实现我的逻辑。当前前端正在接收原始数据。
例如- 请求/费率（每小时11:00）-28
如果我每分钟都有相同的请求/费率，如何获得相同的值？每分钟也有多个值。 如何从原始数据创建每小时的逻辑？
答案 0 :(得分：0)
“监视历史记录”（GUI）和“仪表”（API和功能）相关但不同。
“米”功能是服务器内部的功能，它收集原始（通常是分钟）数据，每小时，每天和每月对“汇总”数据进行汇总，并使旧数据过期。 所有数据都存储在Meters数据库的“普通” XML文件中，而且还使用语义索引以唯一方式索引。
Meters数据通过直接查询到Meters数据库或通过一组公共REST入口点公开-其实现在安装树中的纯xquery源中，您可以查看。
“ Monitorinig历史记录” GUI －是一个客户端应用程序，它使用公共休息端点，然后在客户端进行进一步处理以呈现各种视图。没有记录确切的处理算法，但是javascript代码也位于“纯文本”中以供检查。与调用REST端点相比，客户端javascript在进行其他数据处理的地方并不总是很明显-也不是您看到的内容与后端请求的确切映射。
如果您的目标是复制“原始”数据，我建议直接进入Meters数据库，这是“真相的来源”-尽可能。 要求的特定问题更加微妙。并非总是可以完全将“汇总”行为从“仪表”数据库中的原始数据还原为“每小时”，“每月”等。它在很大程度上是“直截了当”的，但在内部情况下，内部数据的保存更为精确或然后将具有更多变量的变量发布到数据库，并将此内部数据集用于聚合/“汇总”-意味着数学并非总是完全相同。 此外，为了产生更一致的数据结果，还应用了内部“规则”将四舍五入到最接近的分钟/小时/ 5分钟等，以产生更一致的数据结果，但副作用是可能会丢失数据。例如，如果服务器负载沉重，则可能会出现数据采样的准确时间“舍入”到下一个周期的情况，并且可能会误表示该周期的平均值。连续服务器运行的第一个和最后一个部分小时可能没有可重现的每小时汇总-即，如果您自己计算部分时段，您可能不会得到相同的答案，因为时间戳已调整为落在偶数时段上。服务器内部的数据不会进行“四舍五入”，其目的是使客户端应用程序代码更易于编写以产生合理的结果。尝试跨集群中的服务器进行聚合时（如GUI一样），还有其他一些技巧。应用于群集的指标（例如“ IO速率”）并不总是很明显-是群集范围内的SUM还是Avarage？就像在多核系统上解释“负载平均”。
根据我对问题的理解，建议您直接使用Metering数据库中的数据作为“源”数据。如果从原始数据开始，则删除所有“部分数据”（属于下一个更高汇总的开始和结束范围之外的数据），即，如果您在5:53启动服务器，则删除所有原始数据，直到6:00然后包括从6:00到7:00的所有原始数据-您应该找到与7:00写入的每小时数据几乎完全匹配的条件-前提是您在公式中使用了所有原始属性（最小值，max，sum，avg，sumsq）。在舍入精度范围内，这些应匹配。
使用“更高级别”的API可能会产生您意想不到的答案。它们不是错误，但是有许多参数组合具有不同的可能含义-api不会因为您提供的参数模棱两可或不一致而出错。您可以将该策略与其他指标服务提供商（例如AWS CloudWatch）进行比较-并非所有可能的参数组合都能产生可理解的结果。但是原始数据（不受干扰）不会因此受到影响。
此外，REST API大量使用索引来提高效率。索引的精度与XML数据的精度不同，因此您可能会获得与精度相关的不准确性，具体取决于确切的值-索引使用32位值。取决于服务器版本，XML数据可能使用32或64位值，但索引仍会截断为32。
如果您想要准确性，恕我直言，请避免JSON输出-由于JSON固有的数字精度问题。在“监视历史记录”中对此进行了补偿，但是这样做很繁琐。
如果要最大程度地提高查询性能，请使用REST端点（XML或JSON）-它针对各种请求类型的查询性能进行了优化。尽管它并没有给我们带来任何“魔术”，但直接从电表数据中自己获得相同的性能和精度并不容易。再次，查看端点的代码，所有代码均以纯xquery进行检查，但这不是原始数据的“真相源”，其目的是为了有效地*时间序列集合查询*并不是为了最大精度。对于几乎所有的用途，这都是您想要的。