Prometheus 四种metric类型

虚幻大学 xuhss 195℃ 0评论

? 优质资源分享 ?

学习路线指引(点击解锁) 知识定位 人群定位
? Python实战微信订餐小程序 ? 进阶级 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。
?Python量化交易实战? 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

Prometheus的4种metrics(指标)类型:

  • Counter
  • Gauge
  • Histogram
  • Summary

四种指标类型的数据对象都是数字,如果要监控文本类的信息只能通过指标名称或者 label 来呈现,在 zabbix 一类的监控中指标类型本身支持 Log 和文本,当然在这里我们不是要讨论 Prometheus 的局限性,而是要看一看 Prometheus 是如何把数字玩出花活的。 Counter 与 Gauge 比较好理解,我们简单的过一下 然后主要关注 Histogram 和 Summary

Counter 与 Gauge


Counter

单调递增的计数器。

例如 Prometheus自身 中 metrics 的 http 请求总数

512d7777d2693f5c93608e2942708f4e - Prometheus 四种metric类型

Gauge

仪表,也可以认为是一种计数器,不过支持加和减。

例如 node 中的负载数据

6210e175cdce53e071bc510a12dc40a7 - Prometheus 四种metric类型

Histogram 与 Summary


Histogram

直方图常用于请求持续时间或者响应大小采样,然后将结果记录到存储桶(bucket),每个桶为累加数据。

通过三个metrics名称来完整暴露一组Histogram

  • 桶累积计数器,\_bucket{le=""}
  • 所有观察值的总和,\_sum
  • 已观察到的事件计数,\_count与上述相同\_bucket{le="+Inf"}

例如K8s中pod启动耗时:

kubelet_pod_start_duration_seconds_bucket
kubelet_pod_start_duration_seconds_count #进行过pod start的数量
kubelet_pod_start_duration_seconds_sum  # 总耗时

具体到某个节点中

15c333f512e374b9c970135d888328a4 - Prometheus 四种metric类型

le:小于等于。例如le=”5“,即pod启动耗时<=5s的有87次

+inf:无穷。当启动耗时为无穷时,也就是节点下pod启动过的数量,与kubelet_pod_start_duration_seconds_count相等

通过grafana 中 Bar gauge呈现桶的分布如下:

36e3cff7e94371e8763fe4ecde884f2e - Prometheus 四种metric类型

有了直方图数据后我们可以做相应的比例计算:

计算pod启动耗时大于1s,小于2.5s的次数

#kubelet\_pod\_start\_duration\_seconds\_bucket{ instance="node4.**.com",le="2.5"} - ignoring(le) kubelet\_pod\_start\_duration\_seconds\_bucket{ instance="node4.**.com",le="1"}
9

计算pod启动耗时大于2.5s的比例

#kubelet\_pod\_start\_duration\_seconds\_bucket{ instance="node4.**.com",le="2.5"} / ignoring(le) kubelet\_pod\_start\_duration\_seconds\_bucket{ instance="node4.**.com",le="+Inf"} 
0.875

使用 PromQL 函数histogram_quantile计算百分位

#histogram\_quantile(0.80,kubelet\_pod\_start\_duration\_seconds\_bucket{ instance="node4.**.com"} )
1.3000000000000018

即80%的pod启动次数中,耗时<=1.3s,histogram_quantile函数计算百分位得到是一个近似值。

通过histogram_quantile函数聚合

计算Prometheus http所有请求中80百分位的值

histogram_quantile(0.8, sum(rate(prometheus\_http\_request\_duration\_seconds\_bucket[5m])) by (le))

6e7c2c25ad29105e917fd743fb810a02 - Prometheus 四种metric类型

即80%的请求响应时间<=0.08s

通过histogram计算网站性能指标 - Apdex指数

Apdex 指数 =( 满意数量 + 0.5 * 可容忍数量 ) / 总样本数,假设请求满意时间为0.3s,则可容忍时间为1.2s(4倍)

(
  sum(rate(http\_request\_duration\_seconds\_bucket{le="0.3"}[5m])) by (job)
+
  sum(rate(http\_request\_duration\_seconds\_bucket{le="1.2"}[5m])) by (job)
) / 2 / sum(rate(http\_request\_duration\_seconds\_count[5m])) by (job)
Summary

Summary与Histogram相似,也是通过三个metrics名称来完整暴露一组Summary,不过Summary是直接在客户端帮我们计算出了百分位数(Histogram 则使用上面提到的histogram_quantile函数计算)

  • φ 分位数(0 ≤ φ ≤ 1),{quantile="<φ>"}
  • 所有观察值的总和,\_sum
  • 已观察到的事件计数,\_count

例如cgroup操作延迟:

kubelet_cgroup_manager_latency_microseconds
kubelet_cgroup_manager_latency_microseconds_sum
kubelet_cgroup_manager_latency_microseconds_count

a1c11861ec2a278de9fc9057dc8ca94e - Prometheus 四种metric类型

Summary和Histogram都可以使用rate函数计算平均数

计算cgroup update操作的平均延迟:

rate(kubelet\_cgroup\_manager\_latency\_microseconds\_sum{ instance="node4.**.com",operation\_type="update"}[10m]) / rate(kubelet\_cgroup\_manager\_latency\_microseconds\_count{ instance="node4.**.com",operation\_type="update"}[10m])

最后我们对比一下Summary与Histogram

Histogram Summary
配置要求 选择符合预期观测值范围(le)的存储桶 选择所需的分位数φ和窗口范围,其他φ无法再被计算
客户端性能影响 低,仅需增加计数器 高,在客户端计算分位数
服务端性能影响 高,服务端需计算分位数 服务端成本低
时间序列的数量(除了_sum_count序列) 每添加一个存储桶增加一个时间序列 每添加一个分位数φ 值增加一个时间序列
分位数误差 受限于相关桶的宽度 误差在 φ 值的限制
φ分位数和窗口范围 取决于histogram_quantile函数中φ 由客户端预先添加
聚合 histogram_quantile函数聚合 不聚合

通过博客阅读:iqsing.github.io

参考:

HISTOGRAMS AND SUMMARIES

Prometheus metric_types

转载请注明:xuhss » Prometheus 四种metric类型

喜欢 (0)

您必须 登录 才能发表评论!