【AICon】AI 基础设施、LLM运维、大模型训练与推理,一场会议,全方位涵盖! >>> 了解详情
写点什么

详细解读 Prometheus 四种指标类型

  • 2020-05-16
  • 本文字数:3951 字

    阅读完需:约 13 分钟

详细解读Prometheus四种指标类型

Prometheus 的客户端库中提供了四种核心的指标类型。但这些类型只是在客户端库(客户端可以根据不同的数据类型调用不同的 API 接口)和在线协议中,实际在 Prometheus server 中并不对指标类型进行区分,而是简单地把这些指标统一视为无类型的时间序列。不过,将来我们会努力改变这一现状的。

Counter(计数器)

Counter 类型代表一种样本数据单调递增的指标,即只增不减,除非监控系统发生了重置。例如,你可以使用 counter 类型的指标来表示服务的请求数、已完成的任务数、错误发生的次数等。counter 主要有两个方法:


//将counter值加1.Inc()// 将指定值加到counter值上,如果指定值<0 会panic.Add(float64)
复制代码


Counter 类型数据可以让用户方便的了解事件产生的速率的变化,在 PromQL 内置的相关操作函数可以提供相应的分析,比如以 HTTP 应用请求量来进行说明:


//通过rate()函数获取HTTP请求量的增长率rate(http_requests_total[5m])//查询当前系统中,访问量前10的HTTP地址topk(10, http_requests_total)
复制代码


不要将 counter 类型应用于样本数据非单调递增的指标,例如:当前运行的进程数量(应该用 Guage 类型)。


不同语言关于 Counter 的客户端库使用文档:


Guage(仪表盘)

Guage 类型代表一种样本数据可以任意变化的指标,即可增可减。guage 通常用于像温度或者内存使用率这种指标数据,也可以表示能随时增加或减少的“总数”,例如:当前并发请求的数量。


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


dalta(cpu_temp_celsius{host="zeus"}[2h])
复制代码


你还可以通过 PromQL 内置函数 predict_linear() 基于简单线性回归的方式,对样本数据的变化趋势做出预测。例如,基于 2 小时的样本数据,来预测主机可用磁盘空间在 4 个小时之后的剩余情况:


predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0
复制代码


不同语言关于 Guage 的客户端库使用文档:


Histogram(直方图)

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


为了区分是平均的慢还是长尾的慢,最简单的方式就是按照请求延迟的范围进行分组。例如,统计延迟在 0~10ms 之间的请求数有多少而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在,通过 Histogram 和 Summary 类型的监控指标,我们可以快速了解监控样本的分布情况。


Histogram 在一段时间范围内对数据进行采样(通常是请求持续时间或响应大小等),并将其计入可配置的存储桶(bucket)中,后续可通过指定区间筛选样本,也可以统计样本总数,最后一般将数据展示为直方图。


Histogram 类型的样本会提供三种指标(假设指标名称为 <basename>):


  • 样本的值分布在 bucket 中的数量,命名为 _bucket{le="<上边界>"}。解释得更通俗易懂一点,这个值表示指标值小于等于上边界的所有样本数量。


 // 在总共2次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0 // 在总共2次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0 // 在总共2次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0 // 在总共2次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0
复制代码


  • 所有样本值的大小总和,命名为<basename>_sum。


 // 实际含义:发生的2次 http 请求总的响应时间为 13.107670803000001 秒 io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001
复制代码


  • 样本总数,命名为<basename>_count。值和 <basename>_bucket{le="+Inf"}相同。


 // 实际含义:当前一共发生了 2 次 http 请求 io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0
复制代码


可以通过 histogram_quantile() 函数来计算 Histogram 类型样本的分位数。分位数可能不太好理解,我举个例子,假设你要计算样本的 9 分位数(quantile=0.9),即表示 90% 的样本的值。Histogram 还可以用来计算应用性能指标值(Apdex score)。


不同语言关于 Histogram 的客户端库使用文档:


Summary(摘要)

与 Histogram 类型类似,用于表示一段时间内的数据采样结果(通常是请求持续时间或响应大小等),但它直接存储了分位数(通过客户端计算,然后展示出来),而不是通过区间来计算。


Summary 类型的样本也会提供三种指标(假设指标名称为 ):


  • 样本值的分位数分布情况,命名为 <basename>{quantile="<φ>"}。


 // 含义:这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983 // 含义:这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666s io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666
复制代码


  • 所有样本值的大小总和,命名为 <basename>_sum。


 // 含义:这12次 http 请求的总响应时间为 51.029495508s io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508
复制代码


  • 样本总数,命名为 <basename>_count。


 // 含义:当前一共发生了 12 次 http 请求 io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0
复制代码


现在可以总结一下 Histogram 与 Summary 的异同:


  • 它们都包含了 <basename>_sum 和 <basename>_count 指标

  • Histogram 需要通过 <basename>_bucket 来计算分位数,而 Summary 则直接存储了分位数的值。


关于 Summary 与 Histogram 的详细用法,请参考:


https://prometheus.io/docs/practices/histograms/


不同语言关于 Summary 的客户端库使用文档:



原文链接:

https://prometheus.io/docs/concepts/metric_types/


2020-05-16 17:167959

评论

发布
暂无评论
发现更多内容

Flink 2.0 状态管理存算分离架构演进

Apache Flink

Premiere Pro 2022下载 (PR2022中文破解) v22.2.0 语音转字幕专用版

Rose

Premiere Pro 2022 pr2022怎么添加字幕

官宣“2024西部(成都)国际人工智能展会”招展工作全面启动

AIOTE智博会

人工智能展会 人工智能展

PolarDB-X最佳实践系列(四):如何设计一张订单表

阿里云数据库开源

数据库 阿里云 最佳实践 polarDB PolarDB-X

从零到一:我的软件测试开发工程师之路

测试人

软件测试

​让游戏云原生化别再「左右为难」

阿里巴巴云原生

阿里云 阿里云云原生 OpenKruiseGama

TiDB 快速入门:从零到一 部署初探

TiDB 社区干货传送门

安装 & 部署

“分布式透明化”在杭州银行核心系统上线之思考

TiDB 社区干货传送门

实践案例

ECMAScript 悄悄更新了两个对象分组 API,你注意到了么?

OpenTiny社区

开源 前端 低代码 组件库 OpenTiny

京东广告算法架构体系-高性能计算最佳实践

京东零售技术

算法 性能优化 技术架构 GPU算力

OpenCloudOS 迁移工具征集中,18 万奖金等你来拿!|开放原子开源大赛

OpenCloudOS

Linux 迁移

Higress × OpenKruiseGame 游戏网关最佳实践

阿里巴巴云原生

阿里云 云原生 游戏 OpenKruiseGama Higress

精选案例|首创证券 NoETL 敏捷数据分析创新实践

Aloudata

数仓 ETL

大模型“四小龙”,能否跨越深渊?

脑极体

AI

墨水屏电子纸标签/电子纸价签领域如何选择无线通信方案?

Geek_ab1536

搜索推荐DeepFM算法详解:算法原理、代码实现、比赛实战

汀丶人工智能

自然语言处理 排序算法 搜索推荐 召回算法 DeepFM

分享7个常用的 JavaScript 库

伤感汤姆布利柏

选择TiDB的10个理由

TiDB 社区干货传送门

数据库架构选型

使用 Coze 搭建 TiDB 助手

TiDB 社区干货传送门

实践案例

测试 TIDB in k8s 一次问题记录(pd failed to respond)

TiDB 社区干货传送门

7.x 实践

分布式数据库国产替代,杭州银行在挑战什么

TiDB 社区干货传送门

实践案例

程序只占用服务器里一个核心使用,是什么问题

德迅云安全杨德俊

让错误码规范起来吧

京东科技开发者

ETL能实现什么流程控制方式?

RestCloud

ETL 数据集成 数据集成工具

数字人的定义与分类!

青否数字人

支付宝AES如何加密

盐焗代码虾

加密解密 支付宝 AES

详细解读Prometheus四种指标类型_文化 & 方法_Rancher_InfoQ精选文章