Prometheus云原生监控：运维与开发实战
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

4.2.3　区间向量选择器

区间向量选择器返回一组时间序列，每个时间序列包含一段时间范围内的样本数据。和瞬时向量选择器不同的是，它从当前时间向前选择了一定时间范围的样本。区间向量选择器主要在选择器末尾的方括号[]中，通过时间范围选择器进行定义，以指定每个返回的区间向量样本值中提取多长的时间范围。例如，下面的例子可以表示最近5分钟内的所有HTTP请求的样本数据，其中[5m]将瞬时向量选择器转变为区间向量选择器。

http_request_total{}[5m]

时间范围通过整数来表示，可以使用以下单位之一：秒（s）、分钟（m）、小时（h）、天（d）、周（w）、年（y）。需要强调的是，必须用整数来表示时间，比如38 m是正确的，但是2 h 15 m和1.5 h都是错误的。这里的y是忽略闰年的，永远是60×60×24×365秒。

关于区间向量选择器还需要补充的就是，它返回的是一定范围内所有的样本数据，虽然刮擦时间是相同的，但是多个时间序列的时间戳往往并不会对齐，如下所示。

http_requests_total{code="200",job="helloWorld",method="get"}=[
  1@1518096812.678
  1@1518096817.678
  1@1518096822.678
  1@1518096827.678
  1@1518096832.678
  1@1518096837.678
]
http_requests_total{code="200",job=" helloWorld ",method="get"}=[
  4@1518096813.233
  4@1518096818.233
  4@1518096823.233
  4@1518096828.233
  4@1518096833.233
  4@1518096838.233
]

这是因为距离向量会保留样本的原始时间戳，不同target的刮擦被分布以均匀的负载，所以虽然我们可以控制刮擦和规则评估的频率，比如5秒/次（第一组12、17、22、27、32、37；第二组13、18、23、28、33、38），但是我们无法控制它们完全对齐时间戳（1@1518096812.678和4@1518096813.233），因为假如有成百上千的target，每次5秒的刮擦都会导致这些target在不同的位置被处理，所以时间序列一定会存在略微不同的时间点（只是略微不同）。因此会有人说，Prometheus虽然在趋势上是准确的，但是并不是绝对精准的。但是，这在实际生产中并不是非常重要，因为Prometheus等指标监控本身的定位就不像Log监控那样精准，而是趋势准确。

最后，我们结合本节介绍的知识，来看几个关于CPU的PromQL实战案例，夯实一下理论。

案例一：计算2分钟内系统进程的CPU使用率。

rate(node_cpu[2m])

案例二：计算系统CPU的总体使用率，通过排除系统闲置的CPU使用率即可获得。

1 - avg without(cpu) (rate(node_cpu{mode="idle"}[2m]))

案例三：node_cpu_seconds_total可以获取当前CPU的所有信息，使用avg聚合查询到数据后，再使用by来区分实例，这样就能做到分实例查询各自的数据。

avg(irate(node_cpu_seconds_total{job="node_srv"}[5m])) by (instance)

实战拓展

1）区间向量选择器往往和速率函数rate一起使用。比如子查询，以1次/分钟的速率采集关于http_requests_total指标在过去30分钟内的数据，然后返回这30分钟内距离当前时间最近的5分钟内的采集结果，如下所示。

rate(http_requests_total[5m])[30m:1m]

注意，使用不必要的子查询或者不停地嵌套子查询并不是好的PromQL风格。

2）一个区间向量表达式不能直接展示在Graph中，但是可以展示在Console视图中。

上一章目录下一章