关注微信公众号《云原生CTO》更多云原生干货等你来探索
专注于 云原生技术
分享
提供优质 云原生开发
视频技术培训
面试技巧
,及技术疑难问题 解答
云原生技术分享不仅仅局限于Go
、Rust
、Python
、Istio
、containerd
、CoreDNS
、Envoy
、etcd
、Fluentd
、Harbor
、Helm
、Jaeger
、Kubernetes
、Open Policy Agent
、Prometheus
、Rook
、TiKV
、TUF
、Vitess
、Argo
、Buildpacks
、CloudEvents
、CNI
、Contour
、Cortex
、CRI-O
、Falco
、Flux
、gRPC
、KubeEdge
、Linkerd
、NATS
、Notary
、OpenTracing
、Operator Framework
、SPIFFE
、SPIRE
和 Thanos
等
深入了解最重要的 Prometheus 指标
Prometheus
计数器指标需要一些时间来适应。官方文档很好地解释了这个理论,但直到我创建了一些图表,我才明白这个指标有多么强大。
本文将理论与图表相结合,以更好地理解 Prometheus
的计数器指标。我们将看到 PromQL
的功能 rate,
increase
, irate
, 和 resets
工作,最重要的是,我们将查看一些由生产数据的计数器指标生成的图表。
正如您可能从名称中猜到的那样,计数器可以计算事物。它以最简单的方式这样做,因为它的值只能增加而不能减少¹。
线上k8s
二次开发全栈技术课火热报名中,扫码进入课程,深入玩转k8s
二次开发,手把手带你做一名云原生技术专家
虽然无法减少正在运行的计数器的值,但可以重置计数器。应用程序重新启动时会发生重置。
这种行为使计数器适合跟踪只能举一些上升的事物。一些例子包括:
或者在应用程序开发中:
job
执行总量永远不要对可以上升或下降的数字使用计数器。例如,您不应该使用计数器来跟踪数据库的大小,因为大小可以扩展或缩小。
在本节中,我们将了解计数器可以提供的独特见解。我们将使用一个计算作业执行次数的示例指标。
class Job {
private val counter = Metrics.counter("job_execution")
@Scheduled(fixedDelay = 30000)
fun execute() {
counter.increment()
}
}
这段代码通过名称定义了一个计数器 job_execution.
应用程序度量库 Micrometer
将此度量导出为 job_execution_total
. 这 execute()
方法每 30
秒运行一次,每次运行时,它都会将我们的计数器加一。
在大多数情况下,您从原始计数器值中获得的见解没有价值。如果我们绘制原始计数器值,我们会看到一条不断上升的线。
绘制原始计数器值会产生一条只会上升的线。
这条线会一直上升,直到我们重新启动应用程序。当应用程序重新启动时,计数器重置为零
当应用程序重新启动时,计数器将重置为零
幸运的是,PromQL
(Prometheus
查询语言)提供了一些函数来从我们的计数器中获取更有洞察力的数据。
prometheus
rate
函数计算计数器在定义的时间窗口内每秒增加的速率。以下 PromQL
表达式计算最后一分钟的每秒作业执行率²。
rate(job_execution_total[1m])
我们的工作以固定间隔运行,因此将上述表达式绘制在图形中会产生一条直线。
绘制一分钟窗口内的作业执行率
从图中,我们可以看到每秒大约执行 0.036
个job
。将此数字乘以 60
得到 2.16
。这比人们预期的要高,因为我们的工作每 30
秒运行一次,这将是每分钟两次。
Prometheus
抓取指标的方式导致预期值和测量值之间存在细微差异。根据时间的不同,结果值可能更高或更低。重要的是要记住 Prometheus
指标不是一门精确的科学。
PromQL
的 rate
自动调整计数器重置和其他问题。因此,无论何时应用程序重新启动,我们都不会像处理原始计数器值那样看到任何奇怪的下降。
单调性中断(例如由于目标重新启动引起的计数器重置)会自动调整。此外,计算会外推到时间范围的末端,允许遗漏刮擦或刮擦周期与范围时间段的不完美对齐。—
prometheus
文档
最后要注意的一件事 rate
功能是我们应该只将它与计数器一起使用。使用意义不大 rate
与任何其他 Prometheus
指标类型。
promethues
increase
函数计算指定时间范围内的计数器增加量²。以下 PromQL
表达式计算过去 5
分钟内的job
执行次数。
increase(job_execution_total[5m])
由于我们的job
以30
秒的固定间隔运行,因此我们的图表应显示大约 10
的值
绘制过去 5 分钟内的job
执行次数
promethues
推断 increase
覆盖整个指定的时间窗口。因此,尽管计数器仅按整数增量¹增加,但仍有可能获得非整数结果。
相似 rate
,我们应该只使用 increase
与计数器。使用意义不大 increase
与任何其他Prometheus
指标类型。
这个指标非常类似于 rate
. 就像 rate
, irate
计算计数器在定义的时间窗口内每秒增加的速率。不同之处在于 irate
只看最后两个数据点。这使得 irate
非常适合绘制易变和/或快速移动的计数器²。
以下 PromQL
表达式返回查找两个最新数据点两分钟前的每秒job
执行率。
irate(job_execution_total[2m])
我们应该只使用 Irate
与计数器。
promethues
resets
函数为您提供指定时间窗口内的计数器重置次数²。以下 PromQL
表达式计算过去 5
分钟内job
执行计数器重置的次数。
resets(job_execution_total[5m])
我们应该只使用 resets
与计数器。
到目前为止,我们看到的图表对于理解计数器的工作原理很有用,但它们很无聊。
为了更深入地了解这些图表在生产环境中的样子,我从工作中的 Grafana
仪表板中截取了几张屏幕截图。
由于不想泄露公司机密,我已对所有数据进行了匿名处理……
下图使用 increase
计算每分钟处理的消息数。在 24
小时的窗口上绘制此图时,可以清楚地看到夜间的流量要低得多。
使用增加来绘制我们每分钟处理的消息数量
这里我们有相同的指标,但这个指标使用 rate
测量每秒处理的消息数。
使用 rate
绘制我们每秒处理的消息数
正如人们所料,这两个图看起来相同,只是比例不同。您应该使用哪一种取决于您测量的对象和偏好。
在这个例子中,我更喜欢 rate
变体。我认为看到我们每秒处理6.5
条消息比看到我们每分钟处理 390
条消息更容易理解。
Prometheus
计数器是一个简单的指标,但可以通过使用不同的 PromQL
函数来创建有价值的见解,这些函数旨在与计数器一起使用。你应该使用哪个 PromQL
函数取决于被测量的事物和你正在寻找的洞察力。
参考[1][2][3]
参考: https://prometheus.io/docs/concepts/metric_types/
[2]参考: https://levelup.gitconnected.com/prometheus-counter-metrics-d6c393d86076
[3]参考: https://prometheus.io/docs/prometheus/latest/querying/functions/