一、监测的意义
不论是网站运维还是系统管理，服务器本身的运行状况都是我们需要掌控的基础资料。在《打造FaceBook》一书中，王淮介绍FaceBook的工程师文化中有一句“Move Fast and Monitor Closely”。这个"Closely"有两层意义，其一是“即时”的，要从系统开发初期，就有意识地设计好配套的监测，并逐步改善；其二是“深入”，监控不能仅仅停留在监测主机负载、网卡流量的表面层次，而要尽可能地细化，以贴近系统的业务特性。
在系统运行和发展的过程中，监测的重要性得到更进一步的提高。运维人员总是倾向于为了保证稳定性而不轻易对系统做任何改动，所以，运维人员对稳定运行中的系统一举一动都必须要有监测数据的支持。所有的大规模集群运作，包括近年来流行的自动化管理、弹性控制等理念，都要求我们首先对自己的系统的细节有足够的了解。
1.通过命令了解系统的性能概况
1.1 ifconfig命令
结果包含服务器的网卡数目、IP地址、MAC地址、MTU的大小、网卡收发包的情况(丢包和错误包),这些一般是服务器排除故障时需要检查的数据。
1.2 w命令
结果中包含服务器的运行时间、当前用户及其运行程序，以及1分钟、5分钟、10分钟的平均负载。
或许有人会很疑惑，什么是平均负载？
平均负载是反映服务器当前运行状态最直观和简洁的数据。
单核时代，平均负载有如下的经验准则:
(1)如果平均负载大于0.70，趁着事情没有向糟糕的方向发展，赶紧开始找原因（关注原则）;
(2)如果负载高于1.00，立刻扔掉其他非重要紧急的事项，先把这个问题修复(针对运维人员,毕竟维护服务器24x7x365稳定运行是运维人员的职责，没有什么是比这个更重要的，因为一旦服务器出问题，公司的业务也会受到很大的影响)（立刻修复原则）;
(3)如果负载超过5.00，机器随时可能挂掉，尽可能别出现这种情况，如果出现了，要想尽一切办法解决，不过更好的解决方案是，前期做了充足的监控准备，防止此类事件出现,用一句成语来形容，防微杜渐。
多核时代，新增两条准则:
(1)多核系统上，负载不要高过设备的核心数;
(2)核心如何在CPU分布，这并不重要。两个四核心，四个双核心，八个单核心，效果是一样的。对于计算平均负载来说，它们都是八核心。
当然了，以上的准则，只是在一定条件的情况下总结出的，每个运维人员所面对的服务器情况不一样，需要从实际出发。
比如当核心数多到好几十时，Linux轮询各核心来统计单核负载的耗时长到足以让某些任务状态变化，这时候平均负载会普遍比实际情况低。针对这种情况，Linux内核社区以及有些补丁尽量调整算法。
1.3 df
df -h
df -Ti
分别查找挂载盘的目录、总容量和使用量、Inode的总量和使用量，以及磁盘文件系统的类型。
1.4 ps
ps的用法太多了
比如我经常用的 ps -ef|grep tomcat 查看tomcat的进程
或者是ps -A查看所有进程等等
1.5 vmstat
通常会使用free命令查看机器的内存使用情况，如
或者free -m(以"兆"的形式显示内存的容量)
vmstat 1 可以用来观察swap的I/O情况，如图:
1.6 netstat
netstat 是查看网络相关数据的常用命令，可以用来查看服务器所有的网络层连接状况。
netstat -plnt 命令
1.7 iostat
iostat -x 命令
其中磁盘设备的数据含义如下:
rrqm/s:合并后每秒发送到设备的读入请求数。
wrqm/s:合并后每秒发送到设备的写入请求数。
r/s:每秒发送到设备的读入请求数。
w/s:每秒发送到设备的写入请求数。
rsec/s:每秒从设备读入的扇区数。
wsec/s:每秒从设备写入的扇区数。
rkB/s:每秒从设备读入的数据量，单位为KB。
wkB/s:每秒向设备写入的数据量，单位为KB。
avgrq-sz:发送到设备的请求的平均大小，单位是扇区。
avgqu-sz：发送到设备的请求的平均队列长度。
await:I/O请求平均执行时间，包括发送请求和执行时间，单位是毫秒。
svctm:发送到设备的I/O请求的平均执行时间。单位是毫秒。
$util:在I/O请求发送到设备期间，占用CPU时间的百分比。
一般来说，我们关心每秒的读入请求数、队列长度、请求执行时间和I/O时间占CPU的百分比。
对于磁盘I/O，我们必须要明确一件事情，那就是:
I/O性能的优化是不可能无限提高的。所有机械磁盘的IOPS都在最根本上受限于其机械转动的原理。