如何使用 Spring Boot + Prometheus + Grafana 确定时间范围内的准确请求计数

Posted 2023-02-16

【中文标题】如何使用 Spring Boot + Prometheus + Grafana 确定时间范围内的准确请求计数

【英文标题】：How to determine accurate request count in a time range with Spring Boot + Prometheus + Grafana

【发布时间】：2021-11-30 07:54:51

【问题描述】：

我刚开始尝试将 micrometer、prometheus 和 Grafana 集成到我的微服务中。乍一看，它非常易于使用，并且您可以依赖许多现有的仪表板。但是我测试的越多，它就越令人困惑。也许我不明白这个技术栈背后的主要思想。

我想通过显示所选时间范围内每个端点的请求量（作为单个统计数据）来启动我的自定义 Grafana 仪表板，但我无法找到正确的查询（我不确定它存在）

我尝试了不同的：

http_server_requests_seconds_counturi="/users"

始终显示当前值。例如，如果我在 30 分钟前发送了 10 个请求，那么当我更改最近 5 分钟的时间范围时，此查询也将返回值 10（即使在过去 5 分钟内没有请求进入系统）

当我使用时

increase(http_server_requests_seconds_counturi="/users"[$__range])

查询不会返回准确的值，而是接近实际请求量的值。至少它适用于不包括新传入请求的时间范围。在这种情况下，查询返回 0。

所以我的问题是，有没有办法使用此技术堆栈来获取所选时间段内的新请求数量？

【问题讨论】：

如果您使用指标，则它不会准确。问题是你希望它有多准确。如果您需要准确的计数 - 您不应该使用指标，如果它是一个接近的估计，那么指标是正确的工具。通常我们会想要后者。

想了解更多细节吗？为什么我们通常希望与准确值相比更接近的估计值？由于我们需要存储大量数据才能获得不同时间范围的实际值？我仍然需要了解我可以从指标中得到什么

【参考方案1】：

为了在处理数百万个时间序列时提高性能，许多 Prometheus 函数显示近似值和/或插值值。例如increase()函数基本上是每秒rate()乘以间隔中的秒数。有了这样的公式和可能丢失的数据点，准确的结果是一个例外而不是正常的事情。

之所以如此，是因为 Prometheus 用准确性来换取性能和可靠性。如果您的服务器实际 CPU 使用率为 86.3% 而不是 86.4%，这并不重要，但您是否可以立即获得此信息却很重要。 Prometheus 甚至在他们的docs 中有这样的声明：

Prometheus 重视可靠性。即使在故障情况下，您也可以随时查看有关系统的可用统计信息。如果您需要 100% 的准确性，例如按请求计费，Prometheus 不是一个好的选择，因为收集的数据可能不够详细和完整。在这种情况下，您最好使用其他系统来收集和分析数据以进行计费，并使用 Prometheus 进行其余的监控。

话虽如此，如果您确实需要准确的值，请考虑使用其他东西。例如，您可以存储日志和计数行数（Grafana Loki、The Elastic Stack），或者可以使用您自己的解决方案从传统数据库中写入和检索这些信息。

【讨论】：

非常感谢。这个答案确实有助于理解指标和普罗米修斯背后的整个概念，并且或多或少地反映了我在测试中已经认识到的内容。作为一个技术团队，我们需要考虑需要哪些信息和图表来维护和支持我们的应用程序。