metric driven (5) – draw metrics

掌握metric基本技术生成metric原始数据后,接下来考虑的问题是:如何绘图和绘制哪些基本的图。

实际上现在一些metric方案,已经不需要考虑这个问题了,例如Metricbeat的方案,导出数据到elastic search后,所有的图形可以一次性执行一个命令(./metricbeat setup –dashboards)来绘制完,不仅包含主机层面的图,也包含常见的流行服务(redis/apache/nginx)的图像:

再如使用circonus,每个收集到的数据都可以预览,也可以直接使用“quick graph”功能立即绘制存储。

但是假设使用的metric展示系统不能自动绘制,或者自动绘制的不满足需求,这仍然需要考虑绘制的问题,首先要自问的是,不管是什么应用,我们都需要绘制哪些图?

一 系统层面

(1)CPU

CPU指标可以划分为整机CPU和具体应用(进程)的CPU,当整机CPU过高时,可以通过先定位进程后定位线程的方式来定位问题。同时CPU的指标数值有很多,例如下面的一些指标,所以很多metric系统提供的所有数据的采集,而对于cpu利用率的计算需要自己去计算。

[root@vm001~]# top
top – 23:52:07 up 22:11, 1 user, load average: 0.01, 0.00, 0.00
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.7%us, 0.6%sy, 0.0%ni, 97.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

(2)Load

系统load更能真实反映整个系统的情况,根据统计的时间范围,可以划分为下面示例中的三种:最近1、5、10分钟。一般系统load过高时,CPU不定很高,可能是磁盘存在瓶颈等问题,所以还需要具体问题具体分析。

[root@vm001~]# sar -q

10:40:01 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
10:50:01 PM 4 332 0.04 0.02 0.01

(3)Disk

Disk主要关注两个方面:1 磁盘的剩余容量  2 磁盘的影响速度,包括以下一些常用指标:

  • “io_time” – time spent doing I/Os (ms). You can treat this metric as a device load percentage (Value of 1 sec time spent matches 100% of load).
  • “weighted_io_time” – measure of both I/O completion time and the backlog that may be accumulating.
  • “pending_operations” – shows queue size of pending I/O operations.

(4)Network

Network常见的指标包括建立的tcp连接数目、每秒传输(input/output)的字节数、传输错误发生次数等。

(5)Memory

memory主要包括以下指标,需要注意的是linux系统中,可用的内存不仅指free, 因为linux内存管理的原则是,一旦使用,尽量占用,直到其他应用需要才释放。

[root@vm001 ~]# free -m
total used free shared buffers cached
Mem: 3925 1648 2276 2 248 312
-/+ buffers/cache: 1087 2837
Swap: 3983 0 3983

其中系统层面,还可以将jvm这层纳入到这层里面,例如使用绘制出jmx观察到的所有的jvm的一些关键信息。

二 应用层面

(1) TPS:了解当前的TPS,并判断是否超过系统最大可承载的TPS.

(2)ResponseTime: 获取response time的数据分布,然后排除较长时间的原因,决策是否合并,假设有需要,做合适优化。

(3)Success Ratio :找出所有失败的case,并逐一排查原因,消灭bug或者不合理的地方。

(4)Total Count:有个总体的认识,知道每种api的调用次数和用量分布。

三 用户层面

(1)谁用的最多?

(2)用的最多的业务是什么?

(3)业务的趋势是什么?

除了上面提到的一些基本图表外,我们还可以绘制更多“有趣”图表做更多的事情:

(1) load balance是否均衡

X为主机名,Y为请求总数,不同颜色表示不同类型的请求。

(2) 是否可以安全的淘汰一个接口或者功能:

淘汰一个api或者功能时,很多现实是预期之外的,例如应用多个版本的存在、运维的原因都可能导致仍然有“用量”,所以最安全的方式是实际统计使用情况来决定淘汰的时机。例如下图是某个api的调用次数。可见用量逐渐趋向于0,从8月21号,可以删除这个接口或者功能了。

(3) 预警“入侵”

可以通过变化率来判断是否有入侵存在,正常的峰值及变化率会稳定在一定的范围,但是如果变化率极高,这可能是入侵,应予以预警。如下图,在5月30号,出现极其高的访问量,实际上入侵的发生导致。

(4)预警硬件故障。

一些硬件的可以,也可以通过metric监控到,例如常见的磁盘问题,磁盘一般在彻底损坏之前,都是先出现‘慢’的特征,所以在彻底坏之前,通过磁盘的disk time来判断趋势和变化,也能在彻底损坏前,更换磁盘,例如下面的图中,15号后磁盘的disk time陡增。

 

除了以上一些用法,还有其他一些,例如对某个场景是否发生和发生频率感兴趣,所以记录metric来统计发生的概率,诸如此类,有了数据后,可以做很多有趣的事情。

 

参考文献:

1 https://collectd.org/wiki/index.php/Plugin:Disk

2 https://collectd.org/wiki/index.php/Plugin:Memory

发布者

傅, 健

程序员,Java、C++、开源爱好者. About me

发表评论

电子邮件地址不会被公开。 必填项已用*标注