如果仪表可以充当计数器，为什么 Prometheus 中既有计数器又有仪表？
Why there are both counters and gauges in Prometheus if gauges can act as counters?
在Counter和Gauge之间做出决定时，Prometheus documentation states that
To pick between counter and gauge, there is a simple rule of thumb: if
the value can go down, it is a gauge. Counters can only go up (and
reset, such as when a process restarts).
它们似乎涵盖了重叠的用例：您可以使用只会增加的 Gauge。那么，为什么还要首先创建 Counter 指标类型呢？为什么不对两者都使用仪表？
从概念上来说，gauge 和 counter 有不同的用途
- 仪表通常代表一种状态，通常用于检测饱和度。
- 计数器的绝对值并没有真正的意义，真正的目的是使用
irate/rate()、increase() ...[=39 等函数计算演化（通常是利用率） =]
这些进化操作需要对增加量进行可靠的计算，而这是您无法使用量规实现的，因为您需要检测值的重置。
从技术上讲，计数器有两个重要的属性：
- 它总是从 0 开始
- 它总是增加（即在代码中增加）
如果应用程序在两次 Prometheus 抓取之间重新启动，则第二次抓取的值可能小于前一次抓取的值，并且可以恢复增加（有点因为你总是会失去最后一次抓取和重置）。
计算从 t1 到 t2 之间的计数器增加的简单算法是：
- 如果
counter(t2) >= counter(t1)那么increase=counter(t2)-counter(t1)
- 如果
counter(2) < counter(t1)那么increase=counter(t2)
总而言之，从技术的角度来看，您可以使用仪表而不是计数器，前提是您在启动时将其重置为 0 并且仅递增它，但任何违反合同的行为都会导致错误的值。
附带说明一下，我还希望计数器实现使用无符号整数表示，而 gauge 则使用浮点表示。这对代码有一些小的影响，例如自动溢出到 0 的能力以及更好地支持当前 cpus 上的原子操作。
对于计数器，您关心的是它增加的速度，而对于仪表，您关心的是实际值。虽然有些指标（理论上）只会上升，但这并不能使它们反击。
在这方面的一个敏锐观察是：
The feeling behind Gauge is that:
Gauge is appropriate Iff SUM operation on the measurements does not make sense for any time interval
例如，如果哈勃 space telescope 正在观察它在天体扫描中观察到的 brightness of every star - 温度总和 - 将不会产生任何有价值的信息。
与 bank-balance 类似。您每天的银行余额总和并不是一个有意义的财富指标。因此，为此使用仪表 - 仪表中提供了区间内的平均值。
rate() fn 问题只是 rate() fn 的技术问题，而不是仪表和计数器的问题。
罪魁祸首是rate()在检测复位时over-smart。 simple-rate() 不能在仪表中完成似乎没有数学原因。
在Counter和Gauge之间做出决定时，Prometheus documentation states that
To pick between counter and gauge, there is a simple rule of thumb: if the value can go down, it is a gauge. Counters can only go up (and reset, such as when a process restarts).
它们似乎涵盖了重叠的用例：您可以使用只会增加的 Gauge。那么，为什么还要首先创建 Counter 指标类型呢？为什么不对两者都使用仪表？
从概念上来说，gauge 和 counter 有不同的用途
- 仪表通常代表一种状态，通常用于检测饱和度。
- 计数器的绝对值并没有真正的意义，真正的目的是使用
irate/rate()、increase()...[=39 等函数计算演化（通常是利用率） =]
这些进化操作需要对增加量进行可靠的计算，而这是您无法使用量规实现的，因为您需要检测值的重置。
从技术上讲，计数器有两个重要的属性：
- 它总是从 0 开始
- 它总是增加（即在代码中增加）
如果应用程序在两次 Prometheus 抓取之间重新启动，则第二次抓取的值可能小于前一次抓取的值，并且可以恢复增加（有点因为你总是会失去最后一次抓取和重置）。
计算从 t1 到 t2 之间的计数器增加的简单算法是：
- 如果
counter(t2) >= counter(t1)那么increase=counter(t2)-counter(t1) - 如果
counter(2) < counter(t1)那么increase=counter(t2)
总而言之，从技术的角度来看，您可以使用仪表而不是计数器，前提是您在启动时将其重置为 0 并且仅递增它，但任何违反合同的行为都会导致错误的值。
附带说明一下，我还希望计数器实现使用无符号整数表示，而 gauge 则使用浮点表示。这对代码有一些小的影响，例如自动溢出到 0 的能力以及更好地支持当前 cpus 上的原子操作。
对于计数器，您关心的是它增加的速度，而对于仪表，您关心的是实际值。虽然有些指标（理论上）只会上升，但这并不能使它们反击。
在这方面的一个敏锐观察是：
The feeling behind Gauge is that:
Gauge is appropriate
Iff SUM operationon themeasurementsdoes not make sense for any time interval
例如，如果哈勃 space telescope 正在观察它在天体扫描中观察到的 brightness of every star - 温度总和 - 将不会产生任何有价值的信息。
与 bank-balance 类似。您每天的银行余额总和并不是一个有意义的财富指标。因此，为此使用仪表 - 仪表中提供了区间内的平均值。
rate() fn 问题只是 rate() fn 的技术问题，而不是仪表和计数器的问题。
罪魁祸首是rate()在检测复位时over-smart。 simple-rate() 不能在仪表中完成似乎没有数学原因。