0
点赞
收藏
分享

微信扫一扫

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)


PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus

指标类型

从存储上来讲所有的监控指标都是相同的,但是在不同的场景下这些指标又有一些细微的差异。

例如,在 Node Exporter 返回的样本中指标 ​​node_load1​​ 反应的是当前系统的负载状态,随着时间的变化这个指标返回的样本数据是在不断变化的。而指标 ​​node_cpu_seconds_total​​ 所获取到的样本数据却不同,它是一个持续增大的值,因为其反应的是 CPU 的累计使用时间,从理论上讲只要系统不关机,这个值是会一直变大。

为了能够帮助用户理解和区分这些不同监控指标之间的差异,Prometheus 定义了 4 种不同的指标类型:​Counter(计数器)​​、​​Gauge(仪表盘)​​​、​​Histogram(直方图)​​​、​​Summary(摘要)​​。

在 node-exporter(后面会详细讲解)返回的样本数据中,其注释中也包含了该样本的类型。例如:

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="cpu0",mode="idle"} 362812.7890625

Counter  只增不减的计数器

​Counter​​ (只增不减的计数器) 类型的指标其工作方式和计数器一样,只增不减,所以它对于存储诸如服务的 HTTP 请求数量或使用的 CPU 时间之类的信息非常有用

常见的监控指标,如 ​​http_requests_total​​​、​​node_cpu_seconds_total​​​ 都是 ​​Counter​​ 类型的监控指标。

Counter是一个简单但有强大的工具,例如我们可以在应用程序中记录某些事件发生的次数,通过以时序的形式存储这些数据,我们可以轻松的了解该事件产生速率的变化。 PromQL内置的聚合操作和函数可以让用户对这些数据进行进一步的分析:

例如,通过rate()函数获取HTTP请求量的增长率:

rate(http_requests_total[5m])

查询当前系统中,访问量前10的HTTP地址:

topk(10, http_requests_total)

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_02

可能你会觉得一直增加的数据没什么用处,了解服务从开始有多少请求有什么价值吗?但是需要记住,每个指标都存储了时间戳的所有你的 HTTP 请求数现在可能是 1000 万,但是 Prometheus 也会记录之前某个时间点的值,我们可以去查询过去一个小时内的请求数,当然更多的时候我们想要看到的是请求数增加或减少的速度有多快,因此通常情况对于 ​Counter​​ 指标我们都是去查看变化率而不是本身的数字。​​PromQL​​​ 内置的聚合操作和函数可以让用户对这些数据进行进一步的分析,例如,通过 ​​rate()​​ 函数获取 HTTP 请求的增长率:

rate(http_requests_total[5m])

获取的是当前五分钟的样本数据,样本数据是一个区间,也就是一个时间范围。

counter在绘制图形的时候,会使用rate函数去计算一下变化率,增长率。

Gauge  可增可减的仪表盘

与 ​​Counter​​​ 不同,​​Gauge​​(可增可减的仪表盘)类型的指标侧重于反应系统的当前状态,因此这类指标的样本数据可增可减,不像counter是一直增长的。

常见指标如 ​​node_memory_MemFree_bytes​​​(当前主机空闲的内存大小)、​​node_memory_MemAvailable_bytes​​​(可用内存大小)都是 ​​Gauge​​ 类型的监控指标。

由于 Gauge 指标仍然带有时间戳存储,所有我们可以看到随时间变化的值,通常可以直接把它们绘制出来,这样就可以看到值本身而不是变化率了,通过 ​​Gauge​​ 指标,用户可以直接查看系统的当前状态。

在绘制图行查看状态的时候,直接使用指标值就可以绘制出来,因为本身就表示当前的状态。 

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_03

这些简单的指标类型都只是为每个样本获取一个数字,但 Prometheus 的强大之处在于如何让你跟踪它们,比如我们绘制了两张图,一个是 HTTP 请求的变化率,另一个是分配的 gauge 类型的实际内存,直接从图上就可以看出这两个之间有一种关联性,当请求出现峰值的时候,内存的使用也会出现峰值,但是我们仔细观察也会发现在峰值过后,内存使用量并没有恢复到峰值前的水平,整体上它在逐渐增加,这表明很可能应用程序中存在内存泄露的问题,通过这些简单的指标就可以帮助我们找到这些可能存在的问题。

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_04

对于 ​​Gauge​​​ 类型的监控指标,通过 ​​PromQL​​​ 内置函数 ​​delta()​​ 可以获取样本在一段时间范围内的变化情况。例如,计算 CPU 温度在两个小时内的差异:

delta(cpu_temp_celsius{host="zeus"}[2h])

还可以直接使用 ​​predict_linear()​​​ 对数据的变化趋势进行预测。例如,预测系统磁盘空间在 4 个小时之后的剩余情况:这个函数是用来做预测的,​predict_linear()​ 这个函数对于磁盘空间来说的话是非常有用的,因为磁盘在实际使用的过程当中一下子就增长起来了,这是一个缓慢的过程,所以可以根据这个函数来判断4个小时之后磁盘剩余的情况,根据这个情况就可以提前去将磁盘空间清理或者扩容。

predict_linear(node_filesystem_free_bytes[1h], 4 * 3600)

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_05

 

 

 

 Histogram 直方图 和 Summary 摘要 使用Histogram和Summary分析数据分布情况

除了 ​​Counter​​​ 和 ​​Gauge​​​ 类型的监控指标以外,Prometheus 还定义了 ​​Histogram​​​ 和 ​​Summary​​​ 的指标类型。​Histogram​​ 和 ​​Summary​​ 主用用于统计和分析样本的分布情况。

在大多数情况下人们都倾向于使用某些量化指标的平均值,例如 CPU 的平均使用率、页面的平均响应时间,这种方式也有很明显的问题,以系统 API 调用的平均响应时间为例:如果大多数 API 请求都维持在 100ms 的响应时间范围内,而个别请求的响应时间需要 5s,那么就会导致某些 WEB 页面的响应时间落到中位数上,而这种现象被称为长尾问题

为了区分是平均的慢还是长尾的慢,最简单的方式就是按照请求延迟的范围进行分组。例如,统计延迟在 ​​0~10ms​​​ 之间的请求数有多少而 ​​10~20ms​​ 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。

Histogram​​ 和 ​​Summary​​​ 都是为了能够解决这样的问题存在的,通过 ​​Histogram​​​ 和​​Summary​​ 类型的监控指标,我们可以快速了解监控样本的分布情况

Summary

摘要用于记录某些东西的平均大小,可能是计算所需的时间或处理的文件大小,摘要显示两个相关的信息:​count(事件发生的次数)和 ​sum​(所有事件的总大小),如下图计算摘要指标可以返回次数为 3 和总和 15,也就意味着 3 次计算总共需要 15s 来处理,平均每次计算需要花费 5s。下一个样本的次数为 10,总和为 113,那么平均值为 11.3,因为两组指标都记录有时间戳,所以我们可以使用摘要来构建一个图表,显示平均值的变化率,比如图上的语句表示的是 5 分钟时间段内的平均速率。

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_06

例如,指标 ​​prometheus_tsdb_wal_fsync_duration_seconds​​​ 的指标类型为 ​Summary​​,它记录了 Prometheus Server 中 ​​wal_fsync​​​ 的处理时间,通过访问 Prometheus Server 的 ​​/metrics​​ 地址,可以获取到以下监控样本数据:

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_07

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_数据_08

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_prometheus_09

和单一的counter和gauge不同的是,summary里面有多个指标。(事件发生的总数和事件发生的总大小,以及事件的分布情况)

  • 事件总数和事件总大小:从上面的样本中可以得知当前 Prometheus Server 进行​​wal_fsync​​ 操作的总次数为 216 次,耗时 2.888716127000002s。
  • 分布情况:其中中位数(quantile=0.5 百分之50的操作耗时)的耗时为 0.012352463,9 分位数(quantile=0.9 百分之90的操作)的耗时为 0.014458005s,百分之99的操作耗时0.017316173。

Histogram

摘要非常有用,但是平均值会隐藏一些细节,上图中 10 与 113 的总和包含非常广的范围,如果我们想查看时间花在什么地方了,那么我们就需要直方图了

直方图以 bucket 桶的形式记录数据,所以我们可能有一个桶用于需要 1s 或更少的计算,另一个桶用于 5 秒或更少、10 秒或更少、20 秒或更少、60 秒或更少。该指标返回每个存储桶的计数,其中 3 个在 5 秒或更短的时间内完成,6 个在 10 秒或更短的时间内完成。

Prometheus 中的直方图是累积的,因此所有 10 次计算都属于 60 秒或更少的时间段,而在这 10 次中,有 9 次的处理时间为 20 秒或更少,这显示了数据的分布。所以可以看到我们的大部分计算都在 10 秒以下,只有一个超过 20 秒,这对于计算百分位数很有用。

PromQL Metrics 指标类型 Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)_响应时间_10

在 Prometheus Server 自身返回的样本数据中,我们也能找到类型为 Histogram 的监控指标​​prometheus_tsdb_compaction_chunk_range_seconds_bucket​​:可以看到这个值是一直增加的,因为是累计增加的,因为1600是包含前面400和100的。

# HELP prometheus_tsdb_compaction_chunk_range_seconds Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range_seconds histogram
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="100"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="400"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="1600"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="6400"} 71
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="25600"} 405
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="102400"} 25690
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="409600"} 71863
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="1.6384e+06"} 115928
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="6.5536e+06"} 2.5687892e+07
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="2.62144e+07"} 2.5687896e+07
prometheus_tsdb_compaction_chunk_range_seconds_bucket{le="+Inf"} 2.5687896e+07
prometheus_tsdb_compaction_chunk_range_seconds_sum 4.7728699529576e+13
prometheus_tsdb_compaction_chunk_range_seconds_count 2.5687896e+07

与 ​​Summary​​​ 类型的指标相似之处在于 ​Histogram​​ 类型的样本同样会反应当前指标的记录的总数(以 ​​_count​​​ 作为后缀)以及其值的总量(以 ​​_sum​​ 作为后缀)。

不同在于 ​Histogram​​ 指标直接反应了在不同区间内样本的个数,区间通过标签 ​​le​​ 进行定义。histogram有专门的函数去计算,后面介绍。

同时对于Histogram的指标,我们还可以通过histogram_quantile()函数计算出其值的分位数。不同在于Histogram通过histogram_quantile函数是在服务器端计算的分位数。 而Sumamry的分位数则是直接在客户端计算完成。因此对于分位数的计算而言,Summary在通过PromQL进行查询时有更好的性能表现,而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。在选择这两种方式时用户应该按照自己的实际场景进行选择

举报

相关推荐

0 条评论