接上一篇的《关于可用性》，再谈一下监控与报警机制。
监控机制
定义了网站可用性指标，如何获取网站的可用值? 监控工具该粉墨登场了。
多数网站都会倾向于利用开源软件自行搭建监控平台。笔者一向认为，即使网站有一台服务器，也应该搭建监控工具，这是保障网站能持续改进的基石。常见的开源监控工具有Nagios（www.nagios.org）、monit（www.tildeslash.com/monit）等。Nagios也可能是当前国内最被广泛采用的监控软件了，根据官方描述，Nagios 是开源的主机、网络、服务监控程序，从这个描述能看出，Nagios 的设计目标是很庞大的。依赖其强大的扩展性，通过分布式监控模式，管理上千台甚至更多的服务器也不在话下。而对于大型集群环境，Ganglia (http://ganglia.info/) 是个不错的选择。
另外商业化运作的比较好的开源监控工具或框架还有 Zenoss (http://www.zenoss.com/)、Zabbix (http://www.zabbix.com/)、Hyperic (http://www.hyperic.com/)、 OpenNMS(http://opennms.org/) 等。这几个的定位都是”企业级”监控平台。当然，功能的确不比 Nagios 差，也有的弥补了 Nagios 的一些不足之处(比如 Zenoss 增强了对 Windows 服务器的监控能力)。但出于种种原因，在国内的流行程度并不广泛。
(图2: Nagios 分布监控示意图
图片来源: http://nagios.sourceforge.net/docs/3_0/images/distributed.png)
如果要满足日趋灵活的 Web 监控需要就不得不提 Nagios 灵活的插件机制，最简单只需要几行 Shell 代码就能实现基本的插件功能。多数情况下，脚本捕获系统日志中的特定事件，通过 NSCA Client 发送给中心监控服务器即可。灵活性是衡量监控软件的一个重要标准，从这一点说，多数传统的商业网管软件怕是都不如 Nagios 这样胜任现在日趋复杂的网站环境。
提到网管监控，必然要谈到 SNMP。跨平台或者针对专有设备的监控离不开SNMP，但有的时候 SNMP 的安全性也的确会带来严重问题。这就需要运维团队中的安全专家对监控系统机制的安全性做整体评估，或是提升运维团队的安全意识以避免在监控过程中引入更多的安全问题。
有些公司的运维团队喜欢自己写监控工具而不是利用已有的第三方开源工具。这种重复发明轮子的做法笔者认为是不可取的。这样做最明显的一个缺点是软件本身的维护成本可能会更高，而且团队人员变动的时候后续代码维护也是个潜在的问题。至于商业工具的选择，这里不作评价。
报警机制
光有监控而报警机制跟不上，不能及时把紧急情况下的信息传递给运维技术人员，那么监控形同虚设。现在报警信息发送途径主要有邮件、IM、SMS 三种(过去书籍中提到的传呼方式已是明日黄花)。
这几个途径中，邮件告警可能是最简单的，实现起来容易，一行命令即可做到，但因为邮件本身的异步属性和邮件服务器的延时问题，很难让运维人员及时得知信息。所以，如果比较严重的告警信息必须考虑其它实时性比较高的方法。至于发送到 IM，如果 IM 是支持 Jabber 的，实现起来并不难，可靠性也会有一定保障，而如果 IM 比较封闭，那么可行性就不大了，除非 IM 公司对你开放 API ，否则任何取巧的技巧来发送消息的方法其可信赖性都不强、SMS 是大家都比较倾向的一种方式，只是有很多人不知道具体如何实现，说白了也就是一层窗户纸。如果有电信服务提供商(SP)能够提供基于 Web 的调用接口给你，那么直接利用 Wget 或是 cURL 工具模拟浏览器处理表单信息即可，几行命令即可搞定。如果不具备这样的条件，不妨考虑一下短信 Modem，现在市场上这样的短信 Modem 很多，价格不贵，大多都提供二次开发的功能，简单的写点脚本即可实现目的。至于网上有人推荐的免费短信服务，因为实时性比较差，笔者是不推荐的。天下没有免费的午餐，这样的服务往往信息发送优先级很低，而且，短信到达率很难保障。
值得一提的是，报警服务器本身也需要监控的。建议定期发送测试邮件、测试短信来验证告警功能处于正常状态。尤其是在节假日来临前更要反复确保该功能是正常可用的。
未完待续，下一篇谈一下《容量规划》。
靠，写完了提交丢失了。。。
服务器少的话就别买短信猫了，直接139.com的邮件到达提醒，免费的
服务器多的话短信条数记得多买点，每天下午下班前一条test短信测试正常，免得服务都瘫痪了运维人员还乐得清闲
某些软件的报警还有响铃
一直在用Nagios+cacti
其他的几个也看过不过都没有用过~
来发个消息。看Fenng的帖子好久了，这个系列对我们来说都相当实用，谢谢Fenng。
cacti的展现和配置要比nagios好
opennms的资产模块和事件处理记录个人觉得也很有意义
个人还是喜欢nagios的，很好很强大
我们公司就有些人喜欢自己发明轮子，这是人家的成绩，不过有些功能实现的方法实在很雷人
“每天下午下班前一条test短信测试正常，免得服务都瘫痪了运维人员还乐得清闲”
偶是每天早上 8:15 发一天test信息，不仅可以测试状态是否正常，还可以兼顾到叫早的效果，哈哈!
我们公司现在采用的是电话报警方式,插到tribox的数据库,由tribox的脚本拨打电话,Nagios灵活的插件机制让我们把UPS电源\主机\主机中的服务\网络设备统统纳入管理.Nagios真的很不错.
我觉得监控分为两类：
1. 基本的系统状态信息监控
2. 业务数据监控
对于业务数据监控我们还是喜欢自己操刀，这样比较方便，关键写起来也不难！
钱宏武老师正在创业一个项目，是用IM机器人和短信来做监控的。还不错。
hi, feng, 你好.
我经常看你的blog, 很厉害, 关于运维管理我感觉分几层, 特别对于bulk的linux环境.
1. syslog 原理, 专用的SYSLOG设备, 如loglogic appliance
2. snmp 原理, 网管系统, 如nagios, …
3. 操作审计, 如palladium appliance
4. 数据库审计, 如palladium database appliance
我很想同你聊聊…
msn [email protected]
skype zhcharlie
对我有用，谢谢！
俺把你的帖子收了，另外监控这一块如果能抓几副支付宝在用的图就更有说服力了
http://blog.chinaunix.net/u/1110/showart_1672904.html
@jacky
同行 :)
在支付宝的截图不能拿出来的。图嘛，基本上都类似啦
hi fenng:
最近拜读你的《网站运维之道》系列文章，收获甚大。现在我有一事请教，还望不吝赐教。
我有一网站，现在一台服务器A。为避免单点增加了B，我想保持我的服务的高度可用性，在A出现问题时能够立马切换到B。但是切换DNS不可能即时生效，不知在这方面有没有什么好的解决方案。
其实这两台机器之间你可以用一个虚拟的 IP 对外服务的啊
参考 LVS 的实现模式。
那这么做的前提是Load Balancer100%可用啊，万一LB挂了，不久全挂了？
LB也要避免单点啊，这样还是没有完全解决问题。看来切换DNS记录要尽量避免，想办法更改机器的ip地址才可能是解决之道，但是一般去IDC租主机，不能很方便的更改ip地址，问题还是在…
什么都提 100% 只会让你钻牛角尖
你先去看看 Load Balance 解决什么问题再来提 可用的问题吧