监控

网络监控
方法1:通过cat /proc/net/dev采集两次,求两次结果的差值
这里获得结果是以bytes为单位的,两次的差值即为流量信息。

Linux的流量指的是网卡流量,包括输入流量和输出流量。
Receive----输入字节数
Transmit—输出字节数
1G=1024M=1024*1024K=1024*1024*1024bytes

流量的一般单位是Gbps Mbps等
1Gbps=1Gb/s
1GBps=8Gb/s

带宽利用率=流率/带宽,这里流率包括输入流率和输出流率之和。

如何查看系统的带宽呢,通过使用ethtool命令,注意该命令用root用户执行

方法2,通过sar命令sar -n DEV 1:
注意观察rxKB/s txKB/s 两列,分别描述输入流量和输出流量,这里单位是KB

方法3,通过nload命令  nload -m
Curr描述当前各网卡的流率信息
nload 默认分为上下两块:
1.上半部分是:Incoming也就是进入网卡的流量,
2.下半部分是:Outgoing,也就是从这块网卡出去的流量,
每部分都有当前流量(Curr),
平均流量(Avg),
最小流量(Min),
最大流量(Max),
总和流量(Ttl)这几个部分,看起来还是蛮直观的
nload默认的是eth0网卡,如果你想监测eth1网卡的流量使用nload eth1
nload -m 可以同时查看多个网卡的流量情况。
方法4,通过nmon命令  按n进行监控

CPU方面:
r:展示了正在执行和等待cpu资源的任务个数。当这个值超过了cpu个数,就会出现cpu瓶颈。
us:用户CPU时间。
sy:系统CPU时间。
id:空闲CPU时间。
wa:等等I/O CPU时间。
us+sy+id+wa=100%
分析思路:
如果 r 经常大于4,且id经常小于40,表面CPU的负荷很重。

磁盘IO监控
读写IO(Read/Write IO)操作
  磁盘是用来给我们存取数据用的,因此当说到IO操作的时候,就会存在两种相对应的操作,存数据时候对应的是写IO操作,取数据的时候对应的是是读IO操作
顺序IO模式(Queue Mode)/并发IO模式(Burst Mode)
  磁盘控制器可能会一次对磁盘组发出一连串的IO命令,如果磁盘组一次只能执行一个IO命令时称为顺序IO;当磁盘组能同时执行多个IO命令时,称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上,单块磁盘只能一次处理一个IO命令。

iostat
iostat -d -k 1 10

1)参数 -d 表示,显示设备(磁盘)使用状态;-k某些使用block为单位的列强制使用Kilobytes为单位;1 10表示,数据显示每隔1秒刷新一次,共显示10次
2)含义:
tps:该设备每秒的传输次数(Indicate the number of transfers per second that were issued to the device.)。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。kB_read/s:每秒从设备(drive expressed)读取的数据量;kB_wrtn/s:每秒向设备(drive expressed)写入的数据量;kB_read:读取的总数据量;kB_wrtn:写入的总数量数据量;这些单位都为Kilobytes。
上面的例子中,我们可以看到磁盘sda以及它的各个分区的统计数据,当时统计的磁盘总TPS是39.29,下面是各个分区的TPS。(因为是瞬间值,所以总TPS并不严格等于各个分区TPS的总和)
Iostat -d -k -x 1

1)使用-x参数我们可以获得更多统计信息
2)rrqm/s:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge);
3)wrqm/s:每秒这个设备相关的写入请求有多少被Merge了;rsec/s:每秒读取的扇区数;wsec/:每秒写入的扇区数。
4)rKB/s:The number of read requests that were issued to the device per second;
5)wKB/s:The number of write requests that were issued to the device per second;avgrq-sz 平均请求扇区的大小avgqu-sz 是平均请求队列的长度。毫无疑问,队列长度越短越好。   
6)await:每一个IO请求的处理的平均时间(单位是微秒毫秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了。这个时间包括了队列时间和服务时间,也就是说,一般情况下,await大于svctm,它们的差值越小,则说明队列时间越短,反之差值越大,队列时间越长,说明系统出了问题。
7)svctm    表示平均每次设备I/O操作的服务时间(以毫秒为单位)。如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好,如果await的值远高于svctm的值,则表示I/O队列等待太长,系统上运行的应用程序将变慢。%util: 在统计时间内所有处理IO时间,除以总共统计时间。例如,如果统计间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util = 0.8/1 = 80%,所以该参数暗示了设备的繁忙程度。
8)一般地,如果该参数是100%表示设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。
9)输出结果中,bi bo 可以表示磁盘当前性能:
10)•bi  块设备每秒接收的块数量,这里的块设备是指系统上所有的磁盘和其他块设备,默认块大小是 1024 byte 。
11)•bo 块设备每秒发送的块数量,例如我们读取文件,bo 就要大于0。bi 和 bo 一般都要接近 0,不然就是 IO 过于频繁,需要调整。
iostat -d -k 1 10         #查看TPS和吞吐量信息(磁盘读写速度单位为KB)
iostat -d -m 2           #查看TPS和吞吐量信息(磁盘读写速度单位为MB)
iostat -d -x -k 1 10       #查看设备使用率(%util)、响应时间(await)
iostat -c 1 10           #查看CPU状态

iotop
iotop 监控 Linux 内核输出的 I/O 使用信息,并且显示一个系统中进程或线程的当前 I/O 使用情况。
它显示每个进程/线程读写 I/O 带宽。它同样显示当等待换入和等待 I/O 的线程/进程花费的时间的百分比。
Total DISK READ 和 Total DISK WRITE 的值一方面表示了进程和内核线程之间的总的读写带宽,另一方面也表示内核块设备子系统的。
Actual DISK READ 和 Actual DISK WRITE 的值表示在内核块设备子系统和下面硬件(HDD、SSD 等等)对应的实际磁盘 I/O 带宽
IO:它显示每个进程的 I/O 利用率,包含磁盘和交换。
SWAPIN: 它只显示每个进程的交换使用率。


vmstat 2 5
如果发现等待的进程r和处在非中断睡眠状态的进程数b非常多,并且发送到块设备的块数si和从块设备接收到的块数so非常大,那就说明磁盘io比较多

iostat -dx 显示磁盘扩展信息
  root@fileapp:~# iostat -dx
  r/s 和 w/s 分别是每秒的读操作和写操作,而rKB/s 和wKB/s 列以每秒千字节为单位显示了读和写的数据量
  如果这两对数据值都很高的话说明磁盘io操作是很频繁。
sar -d -p 1 2
对于磁盘 IO 性能,一般有如下评判标准:
正常情况下 svctm 应该是小于 await 值的,而 svctm 的大小和磁盘性能有关,CPU 、内存的负荷也会对 svctm 值造成影响,过多的请求也会间接的导致 svctm 值的增加。
await 值的大小一般取决与 svctm 的值和 I/O 队列长度以 及I/O 请求模式,如果 svctm 的值与 await 很接近,表示几乎没有 I/O 等待,磁盘性能很好,如果 await 的值远高于 svctm 的值,则表示 I/O 队列等待太长,系统上运行的应用程序将变慢,此时可以通过更换更快的硬盘来解决问题。
%util 项的值也是衡量磁盘 I/O 的一个重要指标,如果 %util 接近 100% ,表示磁盘产生的 I/O 请求太多,I/O 系统已经满负荷的在工作,该磁盘可能存在瓶颈。长期下去,势必影响系统的性能,可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。
默认情况下,sar从最近的0点0分开始显示数据;如果想继续查看一天前的报告;可以查看保存在/var/log/sa/下的sar日志:
sar -d -p -f  /var/log/sa/sa11  | more

vmstat、sar、iostat检测是否是CPU瓶颈
free、vmstat检测是否是内存瓶颈
iostat检测是否是磁盘I/O瓶颈
netstat检测是否是网络带宽瓶颈
swap
si--由磁盘调入内存,也就是内存进入内存交换区的数量。
so--由内存调入磁盘,也就是内存交换区进入内存的数量。
si、so的值长期不为0,表示系统内存不足。需增加系统内存

原文地址:https://www.cnblogs.com/jingdenghuakai/p/13187926.html