Prometheus中4种指标Metrics类型详解

喜欢ヅ旅行 2022-08-28 13:00 523阅读 0赞

在Prometheus的存储实现上所有的监控样本都是以time-series的形式保存在Prometheus内存的TSDB（时序数据库）中，而time-series所对应的监控指标(metric)也是通过labelset进行唯一命名的。

从存储上来讲所有的监控指标metric都是相同的，但是在不同的场景下这些metric又有一些细微的差异。 例如，在Node Exporter返回的样本中指标node\_load1反应的是当前系统的负载状态，随着时间的变化这个指标返回的样本数据是在不断变化的。而指标node\_cpu所获取到的样本数据却不同，它是一个持续增大的值，因为其反应的是CPU的累积使用时间，从理论上讲只要系统不关机，这个值是会无限变大的。

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

1、Counter：只增不减的计数器

Counter类型的指标其工作方式和计数器一样，只增不减（除非系统发生重置）。常见的监控指标，如http\_requests\_total，node\_cpu都是Counter类型的监控指标。 一般在定义Counter类型指标的名称时推荐使用\_total作为后缀。

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

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

rate(http_requests_total[5m])

2、Gauge：可增可减的仪表盘

与Counter不同，Gauge类型的指标侧重于反应系统的当前状态。因此这类指标的样本数据可增可减。常见指标如：node\_memory\_MemFree（主机当前空闲的内容大小）、node\_memory\_MemAvailable（可用内存大小）都是Gauge类型的监控指标。

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

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

3、**Histogram：**

自带buckets区间分布统计，如图请求耗时（毫秒）区间：100,500,1000,3000，+Inf正无穷 ，不指定则默认0.01,0.025,0.05,0.075,....7.5,10,+Inf

histogram是柱状图，在Prometheus系统中的查询语言中，有三种作用：  
对每个采样点进行统计（并不是一段时间的统计），打到各个桶(bucket)中  
对每个采样点值累计和(sum)  
对采样点的次数累计和(count)  
度量指标名称: \[basename\]的柱状图, 上面三类的作用度量指标名称

\[basename\]\_bucket\{le=“上边界”\}, 这个值为小于等于上边界的所有采样点数量  
\[basename\]\_sum  
\[basename\]\_count  
histogram例子  
 ![Histogram 采集整理数据过程实例][Histogram]

如上表，设置bucket=\[1,5,10\]，当实际采样数据如是采样点所示, Observe表示采样点落在该bucket中的数量，即落在\[-,1\]的样点数为2，即落在\[1,5\]的样点数为3，即落在\[5,10\]的样点数为1，write是得到的最终结果（histogram的最终结果bucket计数是向下包含的）：  
\[basename\]\_bucket\{le=“1”\} = 2  
\[basename\]\_bucket\{le=“5”\} =3  
\[basename\]\_bucket\{le=“10”\} =6  
\[basename\]\_bucket\{le="+Inf"\} = 6  
\[basename\]\_count =6  
\[basename\]\_sum =18.8378745

histogram并不会保存数据采样点值，每个bucket只有个记录样本数的counter（float64），即histogram存储的是区间的样本数统计值，因此客户端性能开销相比 Counter 和 Gauge 而言没有明显改变，适合高并发的数据收集。

histogram\_quantile()函数在服务端获取summary分为数  
Histogram 常使用 histogram\_quantile 执行数据分析， histogram\_quantile 函数通过分段线性近似模型逼近采样数据分布的 UpperBound（如下图），误差是比较大的，其中红色曲线为实际的采样分布（正态分布），而实心圆点是 Histogram 的 bucket的分为数分别被计算为0.01 0.25 0.50 0.75 0.95，这是是依据bucket和sum来计算的。当求解 0.9 quantile 的采样值时会用 (0.75, 0.95) 两个相邻的的 bucket 来线性近似。  
 ![histogram\_quantile 逼近正态分布][histogram_quantile]

但是如果自己知道数据的分布情况，设置适合的bucket也会得到相对精确的分为数。

4、**Summary:**

客户端收集中位数，九分位数的数据指标，不指定则不统计分位数（timmer也属于summary，默认单位sencond,并统计max值）

因为histogram在客户端就是简单的分桶和分桶计数，在prometheus服务端基于这么有限的数据做百分位估算，所以的确不是很准确，summary就是解决百分位准确的问题而来的。summary直接存储了 quantile 数据，而不是根据统计区间计算出来的。  
Prometheus的分为数称为quantile，其实叫percentile更准确。百分位数是指小于某个特定数值的采样点达到一定的百分比；

summary是采样点分位图统计。 它也有三种作用：  
在客户端对于一段时间内（默认是10分钟）的每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于60分不及格的同学比例，统计低于80分的同学比例，统计低于95分的同学比例）  
统计班上所有同学的总成绩(sum)  
统计班上同学的考试总人数(count)  
带有度量指标的\[basename\]的summary 在抓取时间序列数据展示。

观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为\[basename\]\{分位数="\[φ\]"\}  
\[basename\]\_sum， 是指所有观察值的总和  
\[basename\]\_count, 是指已观察到的事件计数值  
summary对quantile的计算是依赖第三方库perk实现的：

### summary例子 ###

设置quantile=\{0.5: 0.05, 0.9: 0.01, 0.99: 0.001\}

# 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

从上面的样本中可以得知当前Prometheus Server进行wal\_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s，90%的数据都小于等于0.014458005s。

设置每个quantile后面还有一个数，0.5-quantile后面是0.05，0.9-quantile后面是0.01，而0.99后面是0.001。这些是我们设置的能容忍的误差。0.5-quantile: 0.05意思是允许最后的误差不超过0.05。假设某个0.5-quantile的值为120，由于设置的误差为0.05，所以120代表的真实quantile是(0.45, 0.55)范围内的某个值。注意quantile误差值很小，但实际得到的分为数可能误差很大。

5、查看分位数时summary和histogram的选择：

清楚几点限制：

Summary 结构有频繁的全局锁操作，对高并发程序性能存在一定影响。histogram仅仅是给每个桶做一个原子变量的计数就可以了，而summary要每次执行算法计算出最新的X分位value是多少，算法需要并发保护。会占用客户端的cpu和内存。  
不能对Summary产生的quantile值进行aggregation运算（例如sum, avg等）。例如有两个实例同时运行，都对外提供服务，分别统计各自的响应时间。最后分别计算出的0.5-quantile的值为60和80，这时如果简单的求平均(60+80)/2，认为是总体的0.5-quantile值，那么就错了。  
summary的百分位是提前在客户端里指定的，在服务端观测指标数据时不能获取未指定的分为数。而histogram则可以通过promql随便指定，虽然计算的不如summary准确，但带来了灵活性。  
histogram不能得到精确的分为数，设置的bucket不合理的话，误差会非常大。会消耗服务端的计算资源。  
两条经验：  
如果需要聚合（aggregate），选择histograms。  
如果比较清楚要观测的指标的范围和分布情况，选择histograms。如果需要精确的分为数选择summary。

理论参考：[参考理论][Link 1]

多维度参数：[指标相关详解][Link 2]

此篇分享理论，下篇分享项目实战使用四种指标，敬请期待。

[Histogram]: /images/20220828/8435b27a2ec449338a5f392bb3be10f4.png
[histogram_quantile]: /images/20220828/4b97acf304bf4d79841075049d6c5490.png
[Link 1]: https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/quickstart
[Link 2]: https://blog.csdn.net/zjcsuct/article/details/107172014