监控数据的获取

proc文件系统，想必大家都有所耳闻了，是个博大精深的东东，对于监控来说，几乎所有的监控数据，来源都是这个文件系统，对系统来讲，最重要的监控数据CPU、MEMORY、TRAFFIC等数据，在proc下都可以找到原版内容：

CPU部分
/proc/stat

# cat /proc/stat 

cpu 338758358 17608 62785863 1552185970 42674246 335813 0
cpu0 154122800 7685 41026079 282062239 21481645 335553 0
cpu1 49070293 3954 7468733 434153362 8339637 84 0
cpu2 57780017 3708 7206014 427779389 6573674 90 0
cpu3 77785246 2260 7085034 408190979 6279289 85 0
intr 6211038753 710161351 9 0 2 2 0 0 0 ……
ctxt 7959101395
btime 1257942445
processes 72552965
procs_running 1
procs_blocked 1
这个文件，相比大家比较熟悉了，这里反映的，就是整个cpu的运作状况，第一行，是cpu总的运行状况，第二行到第五行不固定，如果你有8个cpu，那就是8行了，我们有4个cpu，那就是4行，反映的是每个cpu的运行状况。
后面跟的数字，分别代表不同的意义，单位是时间片，就是内核分配给进程的最小的cpu时间，进程持有时间片，而进入cpu来进行运算。这里数字的意义，就是累加到现在，cpu总共执行了多少个时间片，具体从左往右的顺序如下：
user：进程用户空间执行的时间片的个数
nice：被nice调整过的进程在用户控件执行的时间片的个数
system：进程在内核空间执行的时间片的个数
idle：空闲的时间片个数
iowait：进程等待外设io的时间片个数
irq：中断占用的时间片
softirq：软终端占用的时间片
这就是著名的cpu七大项，其实对我们比较重要的，也就四项：user，system，iowait，idle，其余的三项基本上是0，在2.6.11以后又加了一个steal，2.6.24以后加了guest，具体我也没看，以后补充
intr：中断次数，第一个值，是到现在为止，中断的累加值，以后的每个值分别为不同种类中断的次数。中断的类型，在/proc/interrupts中。中断的原因有很多，可能是外部的io，例如键盘、网卡、硬盘等，也可能是进程自己产生的，也可能是内核产生的。
ctxt：上下文切换次数，就是在cpu中运行的线程和运行队列里的线程切换的次数。也是累加值。当切换过多的时候，会引起很多不必要的性能损耗。
btime：系统启动到现在的时间，单位为秒
processes：系统启动后，产生的进程数，包括fork()产生的，和clone()产生的。
procs_running：在cpu中运行的进程数
procs_blocked：被阻塞的，等待i/o完成的进程数

cpu是否被充分利用，并不是只简简单单看几个cpu使用时间就够了，其实这个远远不够，什么情况下，cpu才算是被充分利用了呢？对于一个运算量比较大的系统来讲，应该有以下几个条件：
1、cpu的idle要接近0，idle就是空闲的意思，空闲很多的cpu，不能算是充分利用，所以，cpu被充分利用的机器，idle的百分比占用应该大概是5%上下
2、cpu的user/system要接近7/3，cpu的绝大部分时间用来进行用户空间的计算，一部分时间用来进行内核空间的调度，内核的调度是必须的，但是真正对我们意义大的，应该还是用户空间的计算。
3、每个核的负载不能超过3，如果有4个核，那你的负载最好不要大于10，有一定的负载是必须的，因为每个线程都会有等待外设的时候，比如等待网络，等待硬盘io等，这段时间内，别的线程可以进入cpu进行运算，但是如果这个数太大的话，那不光要等外设，恐怕也需要等cpu了。
4、上下文切换不能过多，每个进程要在cpu里进行运算一段时间，满足它的运算需求，如果上下文切换过多，说明运行队列里的线程不断相互切换，这时候，会发现cpu的system部分特别多，只切换过程，就占用了大量的cpu运算时间，这是一种比较大的损耗。所以，如果中断很多，上下文切换很少，那说明进程基本上驻留在cpu里，对硬件设备发起请求；如果中断很少，上下文切换很多，那估计中断都是用来进行上下文切换的，进程到cpu里屁股还没坐热呢，啥都没干，就又被赶出去了。

当然，这只是一种理想的状况，前提就是进程是偏向于计算的，对io的要求不是很高。当内存出了问题，发生oom的时候，那会发生很多swap和memory之间的交互，到时候，大量的cpu时间，恐怕就是在等待swap和内存的交换了，iowait会非常高，这种情况，虽然idle也是0，但是显然没能做什么运算。

内存部分

/proc/buddyinfo

# cat /proc/buddyinfo 

Node 0, zone DMA 4 4 3 3 3 3 2 0 1 1 2
Node 0, zone Normal 140 90 34 5201 2816 556 29 0 0 0 0
Node 0, zone HighMem 0 2542 1859 253 961 3568 560 19 1 0 0

内存管理的信息，主要用来分析内存碎片的

内存分为三个区域，DMA，Normal，HighMem，如果分页大小为4K，那我们可以分区域来看：

DMA：

有4块1页大小的空间、4块2页大小的空间，3块4页大小的空间，3块8页大小的空间。。。。。。

Normal：

有140块1页大小的空间、90块2页大小的空间。。。。。。

以此类推，越是往后的空间，就越是连续，数目越多，就代表这个大小的连续空间越多，当大的连续空间很少的时候，也就说明，内存碎片已经非常多了。

/proc/meminfo

# cat /proc/meminfo

MemTotal: 4147776 kB
MemFree: 1186840 kB
Buffers: 308812 kB
Cached: 2074696 kB
SwapCached: 103392 kB
Active: 1266316 kB
Inactive: 1597560 kB
HighTotal: 3275100 kB
HighFree: 745984 kB
LowTotal: 872676 kB
LowFree: 440856 kB
SwapTotal: 2096472 kB
SwapFree: 1902584 kB
Dirty: 82136 kB
Writeback: 0 kB
Mapped: 397812 kB
Slab: 77040 kB
CommitLimit: 4170360 kB
Committed_AS: 2965004 kB
PageTables: 4196 kB
VmallocTotal: 106488 kB
VmallocUsed: 3008 kB
VmallocChunk: 103064 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
存放的是内存使用的信息，基本上linux对内存的分配，就全在这里了。
MemTotal：所有可用内存，不等于物理内存大小，因为有一部分kernel使用的，直接被划去了
MemFree：当前空闲的内存，提到这里，就不得不提到linux的两个进程，kswapd，和pdflush，随后我会详细讲
Buffers：读写的缓存，就是内核在调用read()或者write()时候的缓存，也就是文件句柄的缓存，如果读写的文件在cache中，那buffer也会对被cache的文件做缓存的
Cached：对文件的缓存
SwapCached：被swap的内存页，又被交换回内存中的那部分，但是实际上，在swap分区上的这部分信息还未被删除
Active：被频繁使用的内存，除非特殊需求，不会被回收
Inactive：相对于Active而存在的，如果内存紧张，就会被回收
HighTotal/HighFree/LowTotal/LowFree：High和Low主要是针对内核来讲的，内核一般会使用Low Memory，High Memory主要是给用户用的，当Low Memory没有的时候，就挂了
SwapTotal/SwapFree：不多说了
Dirty：针对Cache来讲的，在内存里修改了，未被写回磁盘的
Writeback：已经写回磁盘的
Mapped：主要是针对被映射到内存里的库文件讲的
Slab：内核的数据函数缓存
CommitLimit：这个和内核参数vm.overcommit_ratio有关
Committed_AS：这个是进程总共申请的内存大小，如果一个进程申请了400M内存，那这里就会有它的400M，虽然它只用了100M，而留着300M空闲
VmallocTotal/VmallocUsed/VmallocChunk：属于vmalloc的空间选项
kswapd和pdfulsh，是linux下运行的两个进程，都是用来回收内存的，linux的内存回收有两种算法，PFRA和LMR：

PFRA的进程就是kswapd，内核有两个值：pages_high和pages_low，当可用内存的值低于pages_low的时候，kswapd就开始回收内存，清理cache，把能放到swap里的丢到swap，直到空闲内存大于pages_high为止。LMR的进程是pdflush，内核有个参数，vm.dirty_background_ratio，当内存中脏页，也就是dirty占到这个百分比的时候，pdflush会启动，将脏页写回到磁盘。

频繁读写的机器，buffer肯定会比较高，而且bi和bo也会比较高（vmstat中的bi和bo，代表buffer的out和in）。而对于数据库这种纯粹跑io的机器，那cache可能会比较重要。当linux内存紧缺的时候，它会先压缩cache，然后压缩buffer，Inactive的部分也会被写到swap中。其实，用到swap并不代表就说明这个机器到了瓶颈，因为有些用不到的内存页，放到swap里是正常的，只有在swap和内存频繁交互的时候，也就是si和so非常高的时候（vmstat中的si何so，代表swap和内存的交互），才说明内存出了问题。

网络部分

/proc/net/dev

# cat /proc/net/dev

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo:941316791 7326363 0 0 0 0 0 0 941316791 7326363 0 0 0 0 0 0
eth0:336037134 2034238824 0 647 0 0 0 5 3782240752 2181116563 0 0 0 0 0 0
eth1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
这个文件我想大家都很熟悉了
比较重要的网络参数都在这里了，包括流量，包数目，错误，丢弃，fifo，fram，压缩，广播等