0

我的背景更多来自 Twitter 方面,所有统计数据都是按分钟记录的,因此您每分钟可能有 120 个请求。在 Twitter 内部,有人提出了除以 60 的好主意,所以大多数图表(除了一些团队意识到除以 60 根本不是真正的 rps,因为在一分钟内,它会波动)。因此,许多图表每秒报告 2 个请求,而不是每分钟 120 个请求。在谷歌中,似乎他们在做同样的事情,除了数学没有显示出来。在 twitter 中,我们可以乘以 60,答案总是在那一分钟内发生了多少请求的整数。

然而,在 Google 中,我们看到 0.02 个请求/秒,如果我们乘以 60,则为每分钟 1.2 个请求。如果它们是微小的粒度,那么他们肯定算错了,或者他们的数学有问题。

这是来自 cloudrun 指标,因为我们单击实例本身

在此处输入图像描述

我在这里想念什么?更好的是,我们可以按每分钟的请求报告吗?每秒请求实际上是那一分钟的平均请求/秒,当我们讨论如何获得 0.5 个请求/秒时,人们可能会感到困惑。

我假设这不是“在”分钟边界每秒的请求,因为这将很难计算但也将是一个整数......即。0 个请求或 1 个请求,而不是 0.2 个请求,老实说这毫无用处。

每个云运行实例都会创建这个图表,所以我假设每个人都一样,但是如果我点击“在指标资源管理器中查看”,它就会给出这张关于“谷歌如何配置它”的图片......

在此处输入图像描述

4

1 回答 1

0

正如Cloud Run 文档的 Metrics中提供的那样,Request Count 指标每 60 秒采样一次,它从计数中排除未到达您的容器实例的请求,给出的示例是未经授权的请求或在最大数量后发送的请求达到了实例,这显然不是你的情况,但同样需要考虑。

假设请求计数的计算是错误的,我在谷歌的 IssueTracker 系统上对监控和云运行组件进行了一些挖掘,以检查是否有任何与此相关的错误打开但找不到,我建议你在他们的系统中创建一个错误,以便 Google 可以解决它,并在修复后通知您。

于 2020-03-09T14:40:46.510 回答