在Counter 和Gauge 之间做出选择时，Prometheus documentation states that
要在计数器和仪表之间进行选择，有一个简单的经验法则：如果 价值可以下降，这是一个衡量标准。计数器只能上升（并且 重置，例如在进程重新启动时）。
它们似乎涵盖了重叠的用例：您可以使用只会增加的量规。那么，为什么还要首先创建 Counter 度量类型呢？为什么不简单地同时使用 Gauges？
【问题讨论】：
标签： monitoring prometheus metrics
从概念上看，量规和计数器有不同的用途
irate/rate()、increase() 等函数的演化（通常是利用率）...这些演化操作需要对增量进行可靠计算，而使用量规无法实现，因为您需要检测值的重置。
从技术上讲，计数器有两个重要的属性：
如果应用程序在两次 Prometheus 刮擦之间重新启动，第二次刮擦的值可能小于前一次刮擦，并且可以恢复增加（某种程度上是因为您总是会丢失最后一次刮擦和重置之间的增加)。
计算从 t1 到 t2 刮擦之间计数器增加的简单算法是：
counter(t2) >= counter(t1) 那么increase=counter(t2)-counter(t1)
counter(2) < counter(t1)则increase=counter(t2)
作为结论，从技术角度来看，只要您在启动时将其重置为 0 并仅增加它，但任何违反合同都会导致错误值的情况下，您可以使用计量器而不是计数器。
作为旁注，我还希望计数器实现使用无符号整数表示，而量规宁愿使用浮点表示。这对代码有一些小的影响，例如自动溢出到 0 的能力以及更好地支持当前 cpu 上的原子操作。
【讨论】：
Counter 或Gauge 取决于我们将如何使用度量标准，这样我们就可以假设某些属性是属性。类似于我们在编程时如何使用私有方法：从技术上讲，它不一定是私有的，但我们这样做是为了帮助其他人思考代码。当我们想要聚合它的值时，我们是否也可以说我们应该使用Counter？我们不会添加 CPU 使用率，即 Gauge，但我们可能想要添加总请求数。
# TYPE http_requests_total counter。这有助于发现暴露的指标或可用于完整性检查的指标。
对于计数器，您关心它的增长速度，而对于仪表，您关心实际值。虽然可能存在（理论上）只会上升的仪表，但这并不会使它们成为计数器。
【讨论】：
对此的敏锐观察是：
Gauge 背后的感觉是：
在
measurements上的合适Iff SUM operation的计量器对任何时间间隔都没有意义
例如，如果哈勃太空望远镜正在观察brightness of every star，它所观察到的天体扫描——温度总和——将不会产生任何有价值的信息。
bank-balance 也是如此。你每天银行余额的总和并不是一个有意义的财富指标。因此，请为此使用仪表 - 仪表中提供平均间隔时间。
rate() fn 问题只是关于 rate() fn 的技术问题，而不是关于仪表和计数器的问题。
罪魁祸首是rate() 在检测重置方面过于聪明。 simple-rate() 不能按规格完成似乎没有数学上的原因。
【讨论】：