【Prometheus】Metric类型的理解及运用

Metric类型

1.Counter
作用: 累加的计数器

样本样例:

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

eg1: 计算5分钟内http请求量增长率

rate(http_requests_total[5m])

eg2: 查询请求量前10的http地址

topk(10, http_requests_total)

2.Gauge
作用: 实时反应当前状态的仪表盘
eg1: 计算php容器内存消耗在2小时内差异

delta(container_memory_usage_bytes{container='php'}[2h])

eg2: 计算上述样本的线性回归模型

deriv(container_memory_usage_bytes{container='php'}[2h])

经典样本计算:
样本样例：

container_memory_working_set_bytes{container="POD",container_name="POD",image="k8s.gcr.io/pause:3.1",instance="k8s-node2",job="kubernetes-cadvisor",kubernetes_io_hostname="k8s-node2",name="k8s_POD_kube-proxy-6ppd2_kube-system_9f12d89b-2ae6-11ea-b5dc-fa163eb7be75_14",namespace="kube-system",pod="kube-proxy-6ppd2",pod_name="kube-proxy-6ppd2"}

eg1:查询实时Pod内存使用量

sum(container_memory_working_set_bytes{image!=''}) by (pod_name)

sum的意思把某一时刻下所符合的列表值累加，by的意思是通过pod_name分组
整体的意思是：实时绘制各个pod的内存使用状况

那为什么要用sum呢？
其实k8s中部署Pod后，不管你的pod内有多少容器，都会给你额外匹配pause容器，这个容器的作用相当于Pod内的基础环境，构建Pod内容器的公共设施(命名空间，网络，IPC等)，可类比虚拟机。
所以统计Pod内存使用量就需要把所有pod下所有容器值相加

反之，不用sum的话就会查询到所有容器的内存使用量了

举一反三:
eg1.那么如何计算各节点下的容器使用量总值？
首先是通过节点分组:by (instance)
然后就是组下的各容器内存值累加

sum(container_memory_working_set_bytes{image!=''}) by (instance)

eg2.根据1小时前的情况，预测接下来2小时的各节点内存使用量状况

sum(predict_linear(container_memory_working_set_bytes{image!=''}[1h],2*3600)) by (instance)

3.Histogram & Summary
作用: 统计、分析数据分布情况
例如了解请求耗时分布情况

3.1 Histogram样例

# HELP coredns_forward_request_duration_seconds Histogram of the time each request took.
# TYPE coredns_forward_request_duration_seconds histogram
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.00025"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.0005"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.001"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.002"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.004"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.008"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.016"} 0.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.032"} 259.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.064"} 327.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.128"} 344.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.256"} 351.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="0.512"} 355.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="1.024"} 356.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="2.048"} 357.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="4.096"} 357.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="8.192"} 357.0
coredns_forward_request_duration_seconds_bucket{to="114.114.114.114:53",le="+Inf"} 357.0
coredns_forward_request_duration_seconds_sum{to="114.114.114.114:53"} 15.852329659999997
coredns_forward_request_duration_seconds_count{to="114.114.114.114:53"} 357.0

该指标表示K8s内dns转发请求消耗时间
总操作数为357次
总持续时间为15s
其中耗时在0.128内(le=0.128)的操作次数为344次
在耗时(128,256] 区间的操作次数为351-344=11次

3.2 Summary样例

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0.0"} 3.2722e-05
go_gc_duration_seconds{quantile="0.25"} 8.0476e-05
go_gc_duration_seconds{quantile="0.5"} 9.6085e-05
go_gc_duration_seconds{quantile="0.75"} 0.00012454
go_gc_duration_seconds{quantile="1.0"} 0.003750961
go_gc_duration_seconds_sum 1.228575062
go_gc_duration_seconds_count 6437.0

该指标表示go的gc垃圾回收持续时间
总操作数为6437次
总持续时间为1.228575062s
其中中位数(quantile=0.5)的持续时间为9.6085e-05s

3.3 差异
3.3.1 Histogram直接反应了在不同区间内样本的个数，区间通过标签len进行定义;
3.3.2 Histogram可以通过histogram_quantile()函数计算出其值的分位数。但是在服务器端进行计算，而summary则是在客户端计算完成。

【Prometheus】Metric类型的理解及运用相关推荐

【IPC】关于码流类型的理解
[IPC]关于码流类型的理解 1.背景 2.疑虑 3.总结 3.资源 1.背景对于IPC网络摄像机,可以设置的码流类型有主码流.子码流,可能还会有第三码流. 这些码流类型又有多种分辨率. 那么设置这 ...
Python中timedelta类型的理解
Python中timedelta类型的理解逻辑: timedelta = datetime1-datetime2 理解:一个时间等于两个时刻做差代码 import datetimeif __nam ...
Linux 终端概念和类型的理解
目录 Linux 终端概念和类型的理解查询正在使用的终端命令可以使用 `tty` 查看当前所在的终端查看当前连接计算机的终端设备查看当前正在连接的终端设备和正在使用的程序终端的概念 Linu ...
Prometheus guage类型rate(变化率)计算
目录引言问题场景尝试解决 deriv函数解析最终解决总结与思考引言 Promethues是k8s以及云原生下的标准监控告警系统,提供了很多内置的函数,功能已经十分强大,但是,依然有一些需求 ...
【Solidity】3.类型 - 深入理解Solidity
索引 [Solidity]1.一个Solidity源文件的布局 [Solidity]2.合约的结构体 [Solidity]3.类型 [Solidity]4.单位和全局可变量 [Solidity]5.表 ...
Python 鸭子类型的理解
鸭子类型最简洁的解释与理解用一句概括进一步解释用一句概括是"鸭子"自己就会鸭子那样的"叫声". 进一步解释 python不关注类型本身,而是关注行为:你 ...
枚举类型的理解和应用
相信学习java的人,在平时开发时是很少用到枚举.说实在的,本人对枚举类型一向都是云里雾里,直到最近在看android源码时,才微探到其中的妙处. 接下来就以一个例子结合枚举和手势知识点的应用开发来讲 ...
IEEE-754单精度浮点类型有效数字理解（画图不易，望点赞支持）
32位浮点类型有效数字单精度浮点类型有效数字为7位,是指数字存储过大导致尾数位存储溢出而失去精度,成功保留下来的真实数字.例如:存储16777217(2^24+1)时,程序中实际存储的是其实是167 ...
mysql 索引类型 bitmap_理解数据库中的常见索引类型
在数据库中,索引能加快数据库的查询速度.下面就来理解一些常见的索引类型: B-Tree Bitmap Clustered Non-unique unique 索引有很多种类型,可以为不同的场景提供更好 ...

【Prometheus】Metric类型的理解及运用

Metric类型

【Prometheus】Metric类型的理解及运用相关推荐

最新文章

热门文章