我们的系统一旦上线跑起来我们自然希望它一直相安无事，不要宕机，不要无响应，不要慢腾腾的。但是这不是打开机器电源然后放任不管就可以得到的（如果你就是这种情景，说明你人品太好了）。所以我们要监视系统的运行状况，发现问题及时处理。
要做到系统的监控，大的方向有几种方法：
1)派人盯着
2)自己写个脚本进行监视
3)使用已有的监控软件
关于第1种方法请不要笑话。在业务的关键时点可能需要安排人员守在旁边，万一发生问题可以及时处理，数据库服务公司还为此开展一项专门的业务，叫"DBA值守"。不过DBA一般也不会蛮干，也会使用第2种和第3种方法。
第2种方法适用面较窄，且有重复发明轮子的嫌疑。
所以下面我们来讨论第3种方法（相信有人已经烦了要扔鸡蛋了。好吧，我承认写下前两种方法纯粹为了娱乐）。
先概括一下需求吧。系统的监控，无非是下面几个任务。
1）监视服务的中断
监视服务的中断或者提前发现异常（如磁盘空闲容量过低）
2）报警
发现问题后，通过邮件等形式通知相关人员及时处理。
3）记录性能数据
记录CPU，MEM,IO,Network以及数据库相关的统计信息，便于发现和调查性能问题。
4）趋势分析
图形化显示现在的和历史的性能数据
目前能用于系统监控的开源软件很多，并且它们的侧重点往往不同，需要根据需求做选择。下面介绍几个常用的，并且以个人视角做个简单评价。
性能数据有些明显的特征
1）时间相关
2）只有插入和查询操作
3) 旧的历史数据可以被废弃
针对这些特征，很多监控软件使用专门时系数据工具RRDTool存储数据，比如Cacti，Ganglia，SmokePing。另一些这使用通用的关系数据库，比如nagios,zabbix。更有使用Hbase的OpenTSDB。为了更好的理解现有的很多监控软件，有必要先介绍一下RRDTool。
RRDtool不是一个监控软件，而是一个能对时系数据进行高性能记录检索和图形展现的开源库。不少监控软件都使用了RRDtool，所以有必要了解一下RRDtool。
RRDtool之所以叫RRD(Round Robin Database) Tool，是因其存储数据的方式而得名。可以讲其想象成一个固定大小的环形存储空间，每插入一条记录，当前位置指针向前移动一下，指针移动一圈后覆盖之前的数据。这种结构使得RRD的大小不会扩张，因此也就不需要维护，特别适合性能数据采集的场景。
RRDtool的功能有两个，一是作为时系数据的存储引擎，二是将存储的时系数据按不同要求绘制成png图片。看看下面的例子。
0)安装RRDtool
# yum install rrdtool
1)创建一个RRD
2)插入数据
3)查询数据
4)绘图
speed.png:
上面只是演示RRDtool有什么样的功能，所有用到的各种参数不解释，有兴趣的话可以参考:
http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html
RRDtool或RDB可以解决性能数据的存储问题，但这些性能数据从哪收集呢？数据采集的方法很自由，常用的方法大概可以归纳为以下几种：
1）代理(agent)
一个专门收集性能数据的东西，一般是运行于被监控机器上的某个Deamon。代理采集数据然后传给监控服务器，那么代理又是如何得到数据的呢？无非是调用OS API，执行某个命令或者脚本。因为一般可以定制代理调用的脚本，所以代理采集数据的能力也是可以自由定制的。
2）远程协议
用于管理的共通协议SNMP,IMPI。或者常用的服务协议，http,ftp,ftp等。或是可以远程执行命令的协议telnet和ssh。只要设置好相应的参数就可以透过网络实施远程监视了。
3）定制脚本
有些管理系统上可以配置用于监控的定制脚本。有了定制脚本就可以自由扩展监控对象了。
下面介绍监控相关的共通协议SNMP和IMPI。
SNMP全称是Simple Network Management Protocol，SNMP的目标是管理互联网Internet上众多厂家生产的软硬件平台。被管理的系统上运行一个叫做代理者（agent）的软件元件，通过SNMP向管理系统报告。代理者和管理系统之间通信的方式有两种，一种是管理系统向代理者询问一个具体的参数值(比如：你产生了多少ICMP不可达差错)，另一种是代理者向管理系统主动报告有某些重要事情发生(比如：一个网口掉线了)。
关于代理者和管理系统之间的交互，SNMP定义了5种报文
1)get-request:从代理处提取一个或多个参数值
2)get-next-request：从代理处提取一个或多个参数的下一个参数值
3)set-request：设置代理的一个或多个参数值
4)get-response：返回的一个或多个参数值。它是1）~3）的响应。
5)trap：代理主动发出报文，通知管理系统某些事情发生。
在SNMP体系中由代理提供，由管理系统查询和设置的信息集合称之为MIB(管理信息库)。MIB中的信息通过OID(对象标示符识别)，比如：1.3.6.1.2.1.1.1.0。关于OID的定义可参照相关RFC。比如:
http://www.ietf.org/rfc/rfc1907.txt
标准中也有给厂商预留的OID(1.3.6.1.4.1)，这样厂商可以在此OID下面进行扩展。
很多网络设备都内置SNMP代理，这样外面的监控服务器可以通过SNMP协议获取信息。对于普通的服务器，可以通过安装一个snmp代理软件提供snmp信息。比如：
安装和运行snmp代理
[root@zabbix ~]# yum install net-snmp
[root@zabbix ~]# /etc/init.d/snmpd start
通过SNMP查看系统描述
[root@zabbix ~]# snmpget -v2c -c public localhost 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux zabbix 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64
或者
[root@zabbix ~]# snmpget -v2c -c public localhost iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0
[root@zabbix ~]# snmpget -v2c -c public localhost sysDescr.0
参考：
http://avery-leo.iteye.com/blog/379076
http://www.cnblogs.com/aspx-net/p/3554044.html
IPMI（Intelligent Platform Management Interface）即智能平台管理接口是使硬件管理具备“智能化”的新一代通用接口标准。用户可以利用 IPMI 监视服务器的物理特征，如温度、电压、电扇工作状态、电源供应以及机箱入侵等。Ipmi 最大的优势在于它是独立于 CPU BIOS 和 OS 的，所以用户无论在开机还是关机的状态下，只要接通电源就可以实现对服务器的监控。
要使用IPMI，服务器硬件本身必须提供对ipmi的支持。大多数厂商的服务器都支持IPMI，但并不是所有服务器都支持，所以应该先通过产品手册或在BIOS中确定服务器是否支持ipmi。如果你用的PC机或者虚拟机那肯定没戏了。
通过ipmitool，可以本地或远程经由impi获取机器信息或控制机器。比如:
# ipmitool -I lan -H 服务器地址 -U root -P 密码 power status
# ipmitool -I lan -H 服务器地址 -U root -P 密码 power reset (硬重启)
http://qa.blog.163.com/blog/static/1901470022013690328217/
有了前面的介绍，就很容把一些常用开源监控软件规个类了。
1）MRTG
SNMP数据采集+包含PNG图片的html输出工具。数据存储使用自己的log格式，也可以采用rrdtool。MRTG不是完整的监控系统，当成工具让perl或其他脚本来调用还可以。
http://oss.oetiker.ch/mrtg/
2)Cacti
rrdtool的Web前端，通过SNMP数据采集，也可以定制采集数据的脚本。支持模板定义，图形功能很强，但不能报警，常被拿来和nagios配合使用。
http://www.cacti.net/
3）nagios
数据采集支持主动代理，被动代理，各种网络协议(snmp，HTTP、FTP、SSH等)，支持分布式部署，告警功能强大，特色功能是支持对主机的冗余监控，是功能很全面的一款监控软件，但nagios易用性比较差，图形展示能力很弱。
http://nagios.sourceforge.net/docs/nagioscore/4/en/about.html#whatis
Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
Monitoring of host resources (processor load, disk usage, etc.)
Simple plugin design that allows users to easily develop their own service checks
Parallelized service checks
Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable
Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)
Ability to define event handlers to be run during service or host events for proactive problem resolution
Automatic log file rotation
Support for implementing redundant monitoring hosts
Optional web interface for viewing current network status, notification and problem history, log file, etc.
4）zabbix
zabbix和nagios一样是功能全面的监控软件。但是比nagios更加好用，图形能力更强，所以面临nagios和zabbix二选一的时候建议zabbix。
zabbix的数据采集支持Zabbix agent,ICMP,SNMP,IPMI,http,ssh,定制脚本等
发现问题自动告警
数据展示盒配置设置全部统一的WEB GUI管理
支持分布式部署
支持模板和自动发现功能可以轻松的在大规模环境下部署
http://www.zabbix.com/
5）其他
其他也有几款，比如以性能和大规模监控为卖点的Ganglia和OpenTSDB，但是个人认为通常大多数的场景，zabbix完全够用了。
(除此以外还有专门做网络嗅探的ntop，可以采集Netflow或sFlow等网络流量信息并绘图，不能监视应用服务和告警，需要的话也可以搭个试试。）