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