监控通常分为机器监控和服务监控，机器监控是基础监控，目的是为了获得系统当前的运行状态，服务监控则是主要目的，也是最应该关心的监控，机器监控也是为了更好的服务监控而存在，简单来说，服务监控和系统上部署的具体服务有关，但监控模式可以统一。
监控是为了获得相关的目标数据，获得数据是为了异常情况下作出分析，分析的目的是为了解决线上case以及性能调优。这基本上就是监控存在的意义了。一台线上服务器的机器监控，基本上可以分成四大类：cpu监控、磁盘容量监控、IO监控和网卡监控。不同业务将会导致服务器不同的瓶颈，应该视具体业务而言。本文主要讨论Linux下常见的获得cpu状态的命令行：vmstat。
在使用指令之前，应该明白监控的具体内容以及含义。cpu监控分为两种：cpu使用率和IPC/CPI，两者的应用场景也不相同，通常使用的是cpu使用率监控，基本上操作系统都会提供，而IPC/CPI监控则需要性能专家的协助，操作系统上基本没有相关的指令。
非计算密集型只需要监控cpu的使用率，而cpu的使用率需要关注用户态cpu使用率和系统态cpu使用率，前者表示系统上运行业务获得cpu的执行时间占总cpu时间的百分比，后者表示系统获得cpu时间的百分比。对用户而言，用户态cpu百分比为100%是最理想的状况，但这通常不可能，当出现程序调度、线程上下文切换以及IO交互的时候，系统态cpu使用率会较多的增长。应当明确的是，应用消耗很多CPU并不意味着性能或者扩展性达到了最高或瓶颈。如果长时间出现系统态cpu使用率居高不下，那么就需要关注，有可能是程序写的不优雅，有可能是磁盘即将损坏导致IO消耗时间过长，这时候就需要cpu监控从而分析得出结果。
对计算密集型应用来首，只监控cpu使用率是不够的，还需要监控IPC（每时钟指令数）或CPI（每指令时钟周期）。为什么需要知道这一项数据？IPC或CPI都可以反映了没有指令被执行的时候占用cpu时钟周期的百分比，简而言之就是CPU等待指令从内存中装入寄存器消耗时间的百分比，即停滞（stall）。停滞——当cpu执行指令而所用到的操作数不在寄存器或缓存中并且当前钟周期还未失效时，cpu就需要停滞等待数据从内存中装入寄存器，停滞一旦发生，通常会浪费几百个cpu时钟周期。要想提高计算密集型应用的性能，就需要获得IPC/CPI监控数据，减少停滞减少cpu等待内存数据时间或改善高速缓存。
[work@localhost ~]$ vmstat --help
usage: vmstat [-V] [-n] [delay [count]]
-V prints version.
-n causes the headers not to be reprinted regularly.
-a print inactive/active page stats.
-d prints disk statistics
-D prints disk table
-p prints disk partition statistics
-s prints vm table
-m prints slabinfo
-t add timestamp to output
-S unit size
delay is the delay between updates in seconds.
unit size k:1000 K:1024 m:1000000 M:1048576 (default is K)
count is the number of updates.
[work@localhost ~]$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 56400 43444 324868 0 0 20 14 28 45 0 0 99 1 0 0 0 0 56400 43452 324864 0 0 0 48 36 58 0 0 98 2 0 0 0 0 56400 43452 324868 0 0 0 0 22 34 0 0 100 0 0 0 0 0 56400 43452 324868 0 0 0 0 34 48 0 1 99 0 0 1 0 0 56400 43452 324868 0 0 0 0 22 31 0 1 99 0 0 0 0 0 56400 43452 324868 0 0 0 0 31 48 0 0 100 0 0 0 0 0 56400 43452 324868 0 0 0 0 129 163 3 1 96 0 0 0 0 0 56400 43452 324868 0 0 0 0 35 56 0 2 98 0 0 0 0 0 56400 43452 324868 0 0 0 0 22 32 0 0 100 0 0 0 0 0 56400 43452 324868 0 0 0 0 58 61 0 0 100 0 0 0 0 0 56400 43452 324868 0 0 0 0 24 38 0 1 99 0 0
vmstat 1：表示每隔一秒钟采集、展示一次数据，要想停下来Ctrl+d即可，如果想指定采集次数，则使用“vmstat 1 10"，表示每隔一秒钟采集一次数据，总共采集10次。
r：表示除了cpu资源外已经准备好的进程队列，即等待可用cpu的进程数，获取该值用于判断系统负荷情况，如果长时间该值超过处理器硬件线程个数一倍，则需要关注，系统可能面临高负载状况，如果长时间是处理器硬件线程数的三、四倍，则需要立即关注并采取行动，此时系统已经能感觉到明显的性能下降，要么增加cpu，要么分析当前系统进程状况。
附注：硬件线程个数的概念，举个例子，双核四线程的cpu，表示有2个物理cpu，但是每个cpu有两个逻辑上的线程，对操作系统而言，它认为有4个cpu。
b：表示阻塞的进程队列，阻塞的时候进程还在内存（和挂起不一样，注意区别），但是需要额外的资源（例如IO）等。
us：表示用户态cpu使用率，即应用获得cpu执行时间占用cpu总时间的百分比，占比高并不表示系统瓶颈。
sy：表示系统态cpu使用率，常指系统调度占用cpu总时间的百分比。
id：表示系统空闲时间百分比。
获得这三项数据的目的是为了分析、减少sy的百分比，实际上要判断导致应用异常需要综合很多监控数据，具体靠经验。
si：每秒从磁盘读入虚存（swap）的大小，如果该值较大，则表示系统内存资源紧张，需要频繁的进行内存交换。
so：每秒从内存写入到虚存的大小，和si一致，但是要注意两个值是配合使用，当两个值都较大的时候才真正表示内存资源紧张。
bi：块设备（磁盘）每秒接收的块数量，对应IO中的写操作，太大表示IO操作频繁。
bo：块设备每秒输出的块数量，对应IO中的读操作，太大表示IO操作频繁。
in：每秒cpu中断次数。
cs：每秒上下文切换次数，例如调用系统函数、线程上下文切换、进程切换都会导致该值增大，上下文切换会浪费cpu时钟，配合in值，因此如果该值长时间太大，就需要考虑应用中的线程数是否开启太多等。
附注：
本文如有错漏，烦请不吝指正，谢谢！
原文地址：http://blog.csdn.net/reliveit/article/details/44974651
