我使用 prometheus 来监控一个 api 服务。目前，我使用 Counter 来计算收到的请求数，并使用 Gauge 来计算响应时间（以毫秒为单位）。
我尝试使用 count_over_time(response_time_ms[1m]) 之类的东西来计算某个时间范围内的请求数。但是，我得到的结果是每个点的值都是 10。
为什么这不起作用？
【问题讨论】：
标签： grafana prometheus metrics gauge
count_over_time(response_time_ms[1m]) 将告诉您样本的数量，而不是您的Gauge 在（我假设的）Java 进程中更新的次数。根据您看到的 10 的值，我假设您的抓取间隔为 6 秒。
为了解释为什么这不能像您期望的那样工作，Gauge 只是一个包装double 值的Java 对象。每次设置它的值时，该值都会改变，但仅此而已。不知道该值更改了多少次，或者向 Prometheus 发送了发生这种情况的任何通知。 Prometheus 只是每 6 秒轮询一次并收集当时存在的任何值（从上次收集以来该值更改了 15 次）。这就是为什么仪表旨在测量上升和下降的单个值（例如内存利用率：现在是 645 MB，在 6 秒内为 648 MB，在 12 秒内为 543 MB）：您知道值不断变化，但最好的你可以做的就是不时地取样。
对于请求延迟之类的东西，您应该使用Histogram：它基本上是观察次数（即请求数）的计数器；所有观察结果总和的计数器（即所有请求放在一起花了多长时间）；和每个桶的单独计数器（即有多少请求花费了不到 1 毫秒；有多少请求花费了不到 10 毫秒；等等）。由此，您可以获得任意倍数的抓取间隔的准确平均值（即总时间的变化除以请求数量的变化）以及任何百分位数的估计值（包括中位数）。所述百分位数的精确程度取决于您选择的存储桶大小（以及它们与实际测量值的实际匹配程度）。
或者，如果您只关心请求的数量，那么在每个请求上递增的计数器就足够了。要调整计数器重置（例如作业重新启动），您应该使用 increase() 而不是上面建议的简单区别：
increase(number_of_requests_total[1m])
【讨论】：
如果您想从现在开始计算某个特定时间（在本例中为最后 1m）内的请求数，只需使用
number_of_requests_counter - number_of_requests_counter offset 1m
如果你想每秒有类似的请求，比使用
rate(number_of_requests_counter[1m])
我可以告诉您为什么它不能与您的 Gauge 一起使用，但首先请指定您为该指标分配的内容。我的意思是，你是在评估一些平均值、最后响应时间还是其他一些东西？
对于响应时间，您应该使用摘要或直方图（更多信息here）
【讨论】：